Ada Shootout program for K-Nucleotide (patches)
in [ADA]
|
From: Georg Bauhaus on 4 Sep 2009 14:12 Georg Bauhaus schrieb: > The option I have been thinking of is, in the regexdna > case in particular, to allow some "future" work to > be done while the shared variable is collecting > results: There might be free CPU capacity because, say > on a 4-core, one task hasn't finished, leaving two out of > four cores idling until the next rush of tasks > starts working on the second part of the program, e.g.. Maybe there is another reasonably simple solution to the "optimal" task:cpu allocation problem. Add priorities reflecting: - required printing order (minor issue - printing not much work) - time needed per task (loads of computation) We could estimate the latter, more or less I think, by separating out single tasks that have been assigned a particular piece of work and then measure how long they run on average.
From: Georg Bauhaus on 4 Sep 2009 14:26 Martin schrieb: > . function Get_Key (E : Element_Access) return > Fragment is > . begin > 1,395,255,084 return E.all.Key; > > Is there some accessibility check going on in this? Could a 'pragma > Assert (E.all /= null);' help? I'll try this. Thanks. (-gnatp is on; does it suppress accessibility checks, too?) Hm. Null excluding subtypes...
From: Ludovic Brenta on 4 Sep 2009 14:51 On Sep 4, 7:56 pm, Martin <martin.do...(a)btopenworld.com> wrote: >> Olivier Scalbert wrote on comp.lang.ada: > >>>http://scalbert.dyndns.org/ada/knucleotide/callgrind_out_14048.txt > >> Let's see: > >> 43,644,857,598 PROGRAM TOTALS >> [...] > >> . >> ---------------------------------------------------------------------------- >> . -- >> . -- Calculate and write data - either a percentage >> for all fragments found or - when >> . -- Nucleotide_Fragment is given - the count for >> that fragment. >> . -- >> 262,499,981 procedure Write >> 8,251,549,172 => ???:system__secondary_stack__ss_mark (7x) >> . (Nucleotide_Length : in Frequencies; >> . Nucleotide_Fragment : in Fragment := >> Fragments.Null_Bounded_String) >> . is > I'm not familiar with this tool but if 'big numbers' for innocuous > looking code is to be checked then what about: Right. The numbers, big or small, are "ticks" of valgrind's internal virtual machine, or if you will, number of processor instructions executed. Olivier's annotated output hides the smallest numbers and only shows the larger ones. -- Ludovic Brenta.
From: Robert A Duff on 4 Sep 2009 17:51 Georg Bauhaus <rm.dash-bauhaus(a)futureapps.de> writes: > Martin schrieb: > >> . function Get_Key (E : Element_Access) return >> Fragment is >> . begin >> 1,395,255,084 return E.all.Key; >> >> Is there some accessibility check going on in this? Could a 'pragma >> Assert (E.all /= null);' help? No, pragma Assert will not help, efficiency-wise. There is no accessibility check, here. There's a null check, which can be suppressed, assuming you "know" it can't fail. > I'll try this. Thanks. (-gnatp is on; does it suppress > accessibility checks, too?) -gnatp controlls language-defined checks, including the above null check. Pragma Assert is not affected by -gnatp -- pragma Assert is off by default, and is turned on by -gnata. If pragma Assert is turned off, the compiler does not base any optimization decisions on it -- it's as if it were just erased from the program. > Hm. Null excluding subtypes... Yes, I believe adding "not null" will eliminate the above null check in recent versions of GNAT. The null check then moves to the call site. I didn't look at the whole code, but if you're lucky, the call site will also have "not null" -- the idea is to push the "not null"s as far as possible, until you get to "new" or "'Access", which obviously cannot return null. But if you're using -gnatp, all null checks will be eliminated anyway. - Bob
From: Georg Bauhaus on 5 Sep 2009 16:16
Georg Bauhaus wrote: > Ludovic Brenta schrieb: > >> So I gather that Olivier was profiling an old version of the program. >> Correct? > > Yes. It likely is the one that has the home made Bounded_String. > But this one does not have the plain String generic yet. > (And a few other improvements.) > > I haven't finished merging the new multitasking edition and > all of the new patches yet. A final draft should > be ready this evening. (Just drop the file name from the link > then to see a scratch paper style "manifest" if you like.) Here is the new multicore Knucleotide to be submitted to the Benchmark Game. It has all the latest changes. http://home.arcor.de/bauhaus/Ada/knucleotide.multicore.gnat http://home.arcor.de/bauhaus/Ada/line_io.ada (Submitted with the two files suitably merged.) Measurements, shouts, bug reports, improvements most welcome. - Georg |