From: jonathan on 7 Sep 2009 13:31 On Sep 7, 4:03 pm, Olivier Scalbert <olivier.scalb...(a)algosyn.com> wrote: > My 64 bits machine is an "old" single core Athlon (512KB cache size). So > perhaps it is normal ! > > Olivier My error .. I saw the "64 processor" and thought, ooh, lovely, 64 cores. I have a machine like yours with similar timings: real 0m58.509s user 0m57.928s sys 0m0.588s so your results are reassuring. Jonathan
From: Olivier Scalbert on 7 Sep 2009 13:54 jonathan wrote: > > My error .. I saw the "64 processor" and thought, ooh, lovely, 64 > cores. > > I have a machine like yours with similar timings: > > real 0m58.509s > user 0m57.928s > sys 0m0.588s > > so your results are reassuring. > > Jonathan 64 cores ! Perhaps for Christmas in few years ... ;-) Olivier
From: Georg Bauhaus on 7 Sep 2009 14:07 Olivier Scalbert schrieb: > My 64 bits machine is an "old" single core Athlon (512KB cache size). So > perhaps it is normal ! FWIW, I get ~30 sec for the single core version and ~31 sec (� .5 sec) for the multicore version on a VMware virtual machine: it runs Debian 5.0 and has one VM core assigned to it, of an Intel(R) Core(TM)2 Duo CPU E6750 @ 2.66GHz In another Virtual Box that displays one CPU inside, but runs on an Intel Core Duo 1300 @ 1.66GHz, the results are 1m3s (� 3s) versus ~45 - ~55 sec. Both programs are 32 bit executables. I don't really know what causes the greater fluctuations within the runs on the older Core Duo, except for the (obvious?) reasons: It is a VirtualBox (2.1.4) and runs on a desktop computer...
From: Georg Bauhaus on 7 Sep 2009 20:22 Olivier Scalbert wrote: > Here are the results ! Thanks for the data. System.Pool_Size.Allocate is called a lot by Work_On_12 and Work_On_18. I don't know how to change that. Still it has led me to another idea---but that should not delay submitting Knucleotide any further: http://home.arcor.de/bauhaus/Ada/knucleotide.multi.gnat Should I? Are there any objections? *** That idea will require that some essential parts be rewritten, so please ignore it for the moment: 1/ enumerate the characters we are looking at in a type, 2/ pack them into 4 bits each (a representation) 3/ write new hash function... 4/ optionally, do (3) for fragments of length 12 and 18 only The idea is that the packing, by assumption, can decrease the number of times System.Pool_Size.Allocate is called (which seems to involve the threading library a lot, too).
From: Olivier Scalbert on 7 Oct 2009 07:44
Georg Bauhaus wrote: > This is about the K-Nucleotide program at the > Computer Language Benchmark Game, > http://shootout.alioth.debian.org/u32/benchmark.php?test=knucleotide&lang=gnat&id=1 > where some Ada programs have started to fail. > > In order to have one of them work again, I have patched > knucleotide.gnat, with some success. New version is here: > http://home.arcor.de/bauhaus/Ada/knucleotide.gnat > > Comments? Does it work on your machine? > > The two changes: > > 1 - [stack exhaustion] a loop reading input lines into an > ubounded string replaces the recursive String "&"ing > procedure. (Noting that the input text file is ~240MB ...) > > 2 - [heavy bounded strings] a lightweight bounded string ADT > replaces an instance of Generic_Bounded_Length, yielding > an improved running time of ~22s down from ~30s for > the 2,500,000 case. > > Still, on a relatively small virtual machine running 64bit > Debian, the program cannot handle the 25,000,000 case. > > Hi all, I have just go to K-Nucleotide program at the Computer Language Benchmark Game. Ada is running in 28.51 secs (and now C++ in 16.47 ...) Is it the last version ? Thanks, Olivier |