1. Ruby result: 101 seconds , 2. Java result:9.8 seconds, 3. Perl result:62 seconds

Here's a version that skips even numbers:

class Integer
  def is_prime?
    return false if self < 2
    return false if self % 2 == 0
    max_factor = Math.sqrt(self).to_i
    3.step(max_factor, 2) {|i| return false if self % i == 0 }
    return true
  end
end

And here's a benchmark comparison:

require 'benchmark'

Benchmark.bm(12) do |x|
  x.report("original:") { 2.upto(50000) {|i| is_prime(i) } }
  x.report("Florian's:") { 2.upto(50000) {|i| i.prime? } }
  x.report("Ken's:") { 2.upto(50000) {|i| i.is_prime? } }
end

                  user system total real
original: 171.767000 0.020000 171.787000 (174.627000)
Florian's: 2.804000 0.010000 2.814000 ( 2.814000)
Ken's: 1.041000 0.000000 1.041000 ( 1.042000)

What's more important, how fast a program _runs_, or how fast I can
_write_ it? With Ruby, I can almost always write something that is
"fast enough", and I can write it a whole lot quicker than in Java or
C. The above (semi-) optimized version only took 2 minutes to write.
(And as a side note... it was more fun to write it in Ruby :slight_smile: )

And when you need some extra umph... there's always YARV or ruby2c...
and when you really need it (rarely), manually optimized C.

Cheers,
Ken

irb(main):001:0> require "openssl"
=> true
irb(main):002:0> include OpenSSL
=> Object
irb(main):003:0> a=BN.new("103")
=> 103
irb(main):004:0> a.prime?(10)
=> true
irb(main):005:0> a.prime?(nil)
=> true
irb(main):006:0>

It implements the Miller-Rabin-Test.

See Page Not Found

Dee Zsombor schrieb:

···

How about using a better algorithm than Eratosthenes sieve invented
thousands of years ago. In late 2003 a new method was published that
computes the first n primes using binary quadratic forms. This will
give an O(n/log(log n)) algorithm, instead of O(n*sqrt(n)).

For theoretical description see:
http://www.ams.org/mcom/2004-73-246/S0025-5718-03-01501-1/S0025-5718-03-01501-1.pdf

And for a sample implementation in C
http://cr.yp.to/primegen.html

cheers,
zsombor
--
http://deezsombor.blogspot.com

It's perhaps worth mentioning that although Ruby is about 1/3rd of the size
of Perl, it has a far more complete standard library.

A base Ruby install includes, amongst other things: SSL, base64 encoding/
decoding, MD5/SHA1 hashing, XML/YAML parsing, HTTP client and server, and
remote method calls (DRb, SOAP, XMLRPC).

I think recent version of Perl have accumulated MIME::Base64, but the others
are still extensions you have to download and install.

···

On Wed, Jun 22, 2005 at 10:50:36PM +0900, Mark Thomas wrote:

Okay, here's the Perl version:

#!/usr/bin/perl -w
use Math::Big 'primes';
my $max = 50000;
my $start = time();
my $total = primes($max);
my $time = time() - $start;
print "There are $total primes below $max.\n";
print "Time taken was $time\n";

On my system I get 27 vs. 192 for the original Perl version (which is
not written very perlishly). Sure, this is cheating. CPAN is like
institutionalized cheating, and I love it. :slight_smile: In fact, one of the
reasons I started lurking in the Ruby group is that I think Ruby (with
Gems) is closer to developing a CPAN-like system than Python, and thus
I have decided to learn Ruby instead of Python.

Hey,

I'd like to have a daemon process that watches for new files in a
specific directory and then runs a command on them once they're there.
It seems like a problem someone would have solved before but I haven't
been able to dig up anything about it on the web yet (perhaps I'm not
phrasing it correctly). Just thought I'd bounce a question here before
I started coding it myself.

Any thoughts?

thanks,
Keith

Ryan Leavengood wrote:

In my informal tests, Florian's version is already about 70 times faster
than the original one. It is also about 3.5 times faster than the naive
Java version.

Big frickin' deal! Come on, guys, you are all smarter than that.

Recode the Java version using the same algorithm and *then* compare. It's not like Java won't benefit just as much from the algorithmic improvements.

···

--
Glenn Parker | glenn.parker-AT-comcast.net | <http://www.tetrafoil.com/&gt;

* Ken Kunz <kennethkunz@gmail.com> [2005-06-22 07:20:36 +0900]:

                  user system total real
original: 171.767000 0.020000 171.787000 (174.627000)
Florian's: 2.804000 0.010000 2.814000 ( 2.814000)
Ken's: 1.041000 0.000000 1.041000 ( 1.042000)

That's better than I expected. I'm not sure why Florian thought
it would be slower.

···

--
Jim Freeze

As far as I understood from Miller-Rabin-Test is for determining if a
number is prime with a _given_ _probability_. It is a very efficient
algortithm for that.
The Atkins sieve (binary quadratic forms) is about generating all
primes less than given number. And that is an entirely different
problem, even if you woud do MR in a loop you would not get the same
results as Atkin sieve.

As far as I understood from Miller-Rabin-Test is for determining if a
number is prime with a _given_ _probability_. It is a very efficient
algortithm for that.
The Atkins sieve (binary quadratic forms) is about generating all
primes less than given number. And that is an entirely different
problem, even if you woud do MR in a loop you would not get the same
results as Atkin sieve.

···

--
http://deezsombor.blogspot.com

Keith Fahlgren wrote:

Hey,

I'd like to have a daemon process that watches for new files in a specific directory and then runs a command on them once they're there. It seems like a problem someone would have solved before but I haven't been able to dig up anything about it on the web yet (perhaps I'm not phrasing it correctly). Just thought I'd bounce a question here before I started coding it myself.

Any thoughts?

There's Ara Howard's "dirwatch". For Win32, there's win32-changejournal.

I don't know if dirwatch works on Win32.

Regards,

Dan

Take a look at "Daedalus", its part of the FreeBSD Sysutils
(http://www.freebsd.org/es/ports/sysutils.html\). For some help in how
to configure, use it, see
http://manuals.textdrive.com/read/chapter/61#page147\.

Basically, it runs in the background and will execute any system
commands you want (which in your case might be another Ruby script
which can detect if a file has been added to the dir). It will
respond by executing another script of your choosing.

Matt

···

On 7/20/05, Keith Fahlgren <keith@oreilly.com> wrote:

Hey,

I'd like to have a daemon process that watches for new files in a
specific directory and then runs a command on them once they're there.
It seems like a problem someone would have solved before but I haven't
been able to dig up anything about it on the web yet (perhaps I'm not
phrasing it correctly). Just thought I'd bounce a question here before
I started coding it myself.

Any thoughts?

thanks,
Keith

Keith Fahlgren wrote:

Hey,

I'd like to have a daemon process that watches for new files in a specific directory and then runs a command on them once they're there. It seems like a problem someone would have solved before but I haven't been able to dig up anything about it on the web yet (perhaps I'm not phrasing it correctly). Just thought I'd bounce a question here before I started coding it myself.

A very simple one is here:

http://www.ntecs.de/viewcvs/viewcvs/Utils/file_change_notify.rb?rev=232&view=auto

Regards,

   Michael

Simple implementation I did:
http://phrogz.net/RubyLibs/rdoc/classes/Dir/DirectoryWatcher.html

···

On Jul 20, 2005, at 1:39 PM, Keith Fahlgren wrote:

I'd like to have a daemon process that watches for new files in a
specific directory and then runs a command on them once they're there.

I'd like to have a daemon process that watches for new files in a
specific directory and then runs a command on them once they're there.

If you are on Linux, it would be trivial to wrap something around /dev/inotify

From /usr/src/linux/Documentation/filesystems/inotify.txt
or..
http://www.ibiblio.org/peanut/Kernel-2.6.12/filesystems/inotify.txt

                                     inotify
              a powerful yet simple file change notification system

···

On Thu, 21 Jul 2005, Keith Fahlgren wrote:

Document started 15 Mar 2005 by Robert Love <rml@novell.com>

(i) User Interface

Inotify is controlled by a device node, /dev/inotify. If you do not use udev,
this device may need to be created manually. First step, open it

         int dev_fd = open ("/dev/inotify", O_RDONLY);

Change events are managed by "watches". A watch is an (object,mask) pair where
the object is a file or directory and the mask is a bitmask of one or more
inotify events that the application wishes to receive. See <linux/inotify.h>
for valid events. A watch is referenced by a watch descriptor, or wd.

Watches are added via a file descriptor.

Watches on a directory will return events on any files inside of the directory.

Adding a watch is simple,

         /* 'wd' represents the watch on fd with mask */
         struct inotify_request req = { fd, mask };
         int wd = ioctl (dev_fd, INOTIFY_WATCH, &req);

You can add a large number of files via something like

         for each file to watch {
                 struct inotify_request req;
                 int file_fd;

                 file_fd = open (file, O_RDONLY);
                 if (fd < 0) {
                         perror ("open");
                         break;
                 }

                 req.fd = file_fd;
                 req.mask = mask;

                 wd = ioctl (dev_fd, INOTIFY_WATCH, &req);

                 close (fd);
         }

John Carter Phone : (64)(3) 358 6639
Tait Electronics Fax : (64)(3) 359 4632
PO Box 1645 Christchurch Email : john.carter@tait.co.nz
New Zealand

Carter's Clarification of Murphy's Law.

"Things only ever go right so that they may go more spectacularly wrong later."

From this principle, all of life and physics may be deduced.

Even if we are all not smarter than that, Florian was, for he wrote:

Now do the same in the other two languages...

Yes, tweaking Ruby to be algorithmically faster than the others results
in an unfair comparison.

However, as Florian already pointed out, the Ruby version of the
algorithm was different from the Java and Perl ones from the start. (Or
so he wrote...I don't know enough of the others to know for sure.)

Glenn Parker said:

Big frickin' deal! Come on, guys, you are all smarter than that.

Recode the Java version using the same algorithm and *then* compare.
It's not like Java won't benefit just as much from the algorithmic
improvements.

Yes, that is why I said the naive version. I'm sure the optimized Java
version would be faster than the Ruby one.

But I really think we are getting off track here. For one thing, Java was
really slow in the old days and people made the same comparisons between
it and C that we are making between it and Ruby. But people still used
Java because it was easier to use and more powerful than C. Plus after
years and years of R&D and tons of money, Sun (and other companies) made
some pretty fast implementations (plus computers are really, really fast
these days.)

If some company threw a couple million dollars at the problem I'm sure
Ruby could be made quite a bit faster. But as has been said many times
before, for most problems Ruby is more than fast enough. Plus we do have
some good work being done with YARV, which is essentially a one man
project!

If you prefer Java to Ruby for its performance and whatever other factors,
that is cool. But I fail to see the point in constantly making performance
comparisons, especially from people who seem to want to program in Ruby.

If the performance of Ruby is that much of an issue, I'd suggest putting
your money where your mouth is and helping with YARV or trying to make
your own Ruby VM. It isn't exactly child's play.

Ryan

Jim Freeze wrote:

That's better than I expected. I'm not sure why Florian thought
it would be slower.

If you compute a sieve to find out, if a very high number is prime...

···

--
Florian Frank

In article <42B88EEC.1040005@comcast.net>,

Ryan Leavengood wrote:

In my informal tests, Florian's version is already about 70 times faster
than the original one. It is also about 3.5 times faster than the naive
Java version.

Big frickin' deal! Come on, guys, you are all smarter than that.

Recode the Java version using the same algorithm and *then* compare.
It's not like Java won't benefit just as much from the algorithmic
improvements.

Indeed it will. However, I think the point was that with just a little
bit of thought the Ruby version can outperform a 'first cut' Java
implementation. If the OP considered the original Java version 'fast
enough' and considered the original Ruby version to be unacceptably slow,
well a little rethinking of the algorithm and the Ruby version ends up
being faster than the Java version which was 'fast enough'. If he really
needs the Java version to be faster, well, now he can go back and recode it.

Phil

···

Glenn Parker <glenn.parker@comcast.net> wrote:

nope - though it could be made to pretty easily. basically i wrote it because
of the lack of a changejournal type functionality for *nix filesystems in
general. plus dirwatch is really designed to setup a processing system which
runs external programs on files as they arrive in directories vs. running a
ruby block or some such.

cheers.

-a

···

On Thu, 21 Jul 2005, Daniel Berger wrote:

Keith Fahlgren wrote:

Hey,

I'd like to have a daemon process that watches for new files in a specific directory and then runs a command on them once they're there. It seems like a problem someone would have solved before but I haven't been able to dig up anything about it on the web yet (perhaps I'm not phrasing it correctly). Just thought I'd bounce a question here before I started coding it myself.

Any thoughts?

There's Ara Howard's "dirwatch". For Win32, there's win32-changejournal.

I don't know if dirwatch works on Win32.

--

email :: ara [dot] t [dot] howard [at] noaa [dot] gov
phone :: 303.497.6469
My religion is very simple. My religion is kindness.
--Tenzin Gyatso

===============================================================================

Oops...and you can GET that file from:
http://phrogz.net/RubyLibs/DirectoryWatcher.rb

···

On Jul 20, 2005, at 3:37 PM, Gavin Kistner wrote:

On Jul 20, 2005, at 1:39 PM, Keith Fahlgren wrote:

I'd like to have a daemon process that watches for new files in a
specific directory and then runs a command on them once they're there.

Simple implementation I did:
Class: Dir::DirectoryWatcher

Ryan Leavengood wrote:

If you prefer Java to Ruby for its performance and whatever other factors,
that is cool.

I definitely would not be here if I preferred Java.

But I fail to see the point in constantly making performance
comparisons, especially from people who seem to want to program in Ruby.

Well, I think it's valid to make the comparisons every once in a while, since it highlights a weakness that Ruby implementations will have a hard time overcoming on their own. When you lag behind Perl by a factor of two on *everything*, then you have a real problem.

If the performance of Ruby is that much of an issue, I'd suggest putting
your money where your mouth is and helping with YARV or trying to make
your own Ruby VM. It isn't exactly child's play.

Would throwing money at the problem help YARV? I'm serious.

···

--
Glenn Parker | glenn.parker-AT-comcast.net | <http://www.tetrafoil.com/&gt;