|
From: Julian S. <js...@ac...> - 2005-12-14 14:42:37
|
One of the Valgrind developers (Nick) has recently started putting together a collection of programs intended to measure Valgrind's performance (in perf/ if you have a recent svn checkout). This is a good thing. For the first time it allows us to systematically measure Valgrind's performance across a range of different program types and different CPUs. Even at this early stage it has uncovered some performance problems, the fixes for which will be in 3.2.0. We are looking for a good floating point test program for the suite. There are already two FP programs in it, but neither meets the following set of requirements. If you know of a program which does meet them, and especially if you have the time/expertise to help modify an existing program to meet them, we would be pleased to hear from you. Essential requirements: - must be available under an open-source license. Doesn't have to be GPL since is not being linked into Valgrind. - must be written in C, and work correctly on both 32- and 64-bit platforms, big- and little-endian - must be predominantly double-precision floating-point in workload - must have several innermost loops/hotspots. A program of at least moderate complexity is desired (1000-10000 lines of C). Our existing FP benchmarks are synthetic benchmarks and do not meet this requirement. Perhaps something like a simple raytracer, fluid dynamics code, or audio codec would be suitable. J |
|
From: Stefan K. <en...@ho...> - 2005-12-14 20:03:35
|
Hi Julian, wouldn't that be a good candidate: http://www.fftw.org/ Otherwise I could code you a little mandelbrot-generator. Stefan Julian Seward wrote: > One of the Valgrind developers (Nick) has recently started > putting together a collection of programs intended to measure > Valgrind's performance (in perf/ if you have a recent svn checkout). > > This is a good thing. For the first time it allows us to > systematically measure Valgrind's performance across a range > of different program types and different CPUs. Even at this > early stage it has uncovered some performance problems, the > fixes for which will be in 3.2.0. > > We are looking for a good floating point test program for the > suite. There are already two FP programs in it, but neither meets > the following set of requirements. If you know of a program > which does meet them, and especially if you have the time/expertise > to help modify an existing program to meet them, we would be pleased > to hear from you. > > Essential requirements: > > - must be available under an open-source license. Doesn't have > to be GPL since is not being linked into Valgrind. > > - must be written in C, and work correctly on both 32- and 64-bit > platforms, big- and little-endian > > - must be predominantly double-precision floating-point in workload > > - must have several innermost loops/hotspots. A program of at > least moderate complexity is desired (1000-10000 lines of C). > Our existing FP benchmarks are synthetic benchmarks and do not > meet this requirement. > > Perhaps something like a simple raytracer, fluid dynamics code, > or audio codec would be suitable. > > J > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > |
|
From: Thomas L. <tho...@jr...> - 2005-12-15 09:12:50
|
Hi Julian, I do not know what you call a "simple" raytracer, but I would say the "rayshade" is quite simple. Written in C (not a very recent C style), the core tracer routines have around 6000 lines of instructions. It has a history of configuration on linux / aix (does it proove the point on big- and little- endian?) and I read somewhere about a 64-bit build. It was part (is still part???) of some Linux distros. Like all ray-tracer, it involves quite a few double precision floating point operations. Moreover, you can design your test-case "as heavy as you wish" by using more complicated scenes to be rendered. The coding style tries to emulate an object-oriented encapsulation with structures and function pointers. I already ran valgrind on rayshade and it is clear that there is a very poor memory management: what is allocated is rarely freed. I do not know if you want an error-free code for you test cases. Rayshade development stopped around 1994 and some hacks will certainly be needed to have it build smoothly on all platforms. Especially, there is a Lex/Yacc grammar file that needs some updates in order to build under Linux. There is 1 popen() command, but it is not mandatory. Let me know if I can be of any help. I have a 32-bit Linux PC and have built rayshade from source (with modifications). http://graphics.stanford.edu/~cek/rayshade/ Thomas >> >>Essential requirements: >> >>- must be available under an open-source license. Doesn't have >> to be GPL since is not being linked into Valgrind. >> >>- must be written in C, and work correctly on both 32- and 64-bit >> platforms, big- and little-endian >> >>- must be predominantly double-precision floating-point in workload >> >>- must have several innermost loops/hotspots. A program of at >> least moderate complexity is desired (1000-10000 lines of C). >> Our existing FP benchmarks are synthetic benchmarks and do not >> meet this requirement. >> >>Perhaps something like a simple raytracer, fluid dynamics code, >>or audio codec would be suitable. >> >>J >> >> >>------------------------------------------------------- >>This SF.net email is sponsored by: Splunk Inc. Do you grep through log files >>for problems? Stop! Download the new AJAX search engine that makes >>searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! >>http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click >>_______________________________________________ >>Valgrind-users mailing list >>Val...@li... >>https://lists.sourceforge.net/lists/listinfo/valgrind-users >> >> >> > > > >------------------------------------------------------- >This SF.net email is sponsored by: Splunk Inc. Do you grep through log files >for problems? Stop! Download the new AJAX search engine that makes >searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! >http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click >_______________________________________________ >Valgrind-users mailing list >Val...@li... >https://lists.sourceforge.net/lists/listinfo/valgrind-users > > > |
|
From: Nicholas N. <nj...@cs...> - 2005-12-15 20:20:27
|
On Thu, 15 Dec 2005, Thomas Lavergne wrote: > I do not know what you call a "simple" raytracer, but I would say the > "rayshade" is quite simple. Written in C (not a very recent C style), the > core tracer routines have around 6000 lines of instructions. It has a history > of configuration on linux / aix (does it proove the point on big- and little- > endian?) and I read somewhere about a 64-bit build. It was part (is still > part???) of some Linux distros. Like all ray-tracer, it involves quite a few > double precision floating point operations. Moreover, you can design your > test-case "as heavy as you wish" by using more complicated scenes to be > rendered. > The coding style tries to emulate an object-oriented encapsulation with > structures and function pointers. > I already ran valgrind on rayshade and it is clear that there is a very poor > memory management: what is allocated is rarely freed. I do not know if you > want an error-free code for you test cases. > Rayshade development stopped around 1994 and some hacks will certainly be > needed to have it build smoothly on all platforms. Especially, there is a > Lex/Yacc grammar file that needs some updates in order to build under Linux. > There is 1 popen() command, but it is not mandatory. > Let me know if I can be of any help. I have a 32-bit Linux PC and have built > rayshade from source (with modifications). The good things: - The size is good. - The quasi-OO style is good, since much Valgrind use is on C++ programs. - The popen() is not a problem. - The poor memory management doesn't sound like a problem. - The use of double precision is good. The bad things: - The dependence on Lex/Yacc is bad. Perhaps the generated .c file(s) could be used, hopefully they're not too big. - Portability is a concern; if it's not portable that would be a problem. Nick |
|
From: Julian S. <js...@ac...> - 2005-12-14 20:21:41
|
On Wednesday 14 December 2005 20:17, Stefan Kost wrote: > Hi Julian, > > wouldn't that be a good candidate: > http://www.fftw.org/ Maybe. The problem is we don't really have much time to investigate whether it could be turned into a suitable standalone, portable benchmark. Can you do that? > Otherwise I could code you a little mandelbrot-generator. Well, that would probably fail the ... > > - must have several innermost loops/hotspots. A program of at > > least moderate complexity is desired (1000-10000 lines of C). > > Our existing FP benchmarks are synthetic benchmarks and do not > > meet this requirement. ... requirement. J |
|
From: Nicholas N. <nj...@cs...> - 2005-12-14 20:26:23
|
On Wed, 14 Dec 2005, Julian Seward wrote: >> wouldn't that be a good candidate: >> http://www.fftw.org/ > > Maybe. The problem is we don't really have much time > to investigate whether it could be turned into a suitable > standalone, portable benchmark. Can you do that? > >> Otherwise I could code you a little mandelbrot-generator. > > Well, that would probably fail the ... > >>> - must have several innermost loops/hotspots. A program of at >>> least moderate complexity is desired (1000-10000 lines of C). >>> Our existing FP benchmarks are synthetic benchmarks and do not >>> meet this requirement. > > ... requirement. We already have an FFT benchmark, would the FFTW program also be dominated by a single loop? Nick |
|
From: Julian S. <js...@ac...> - 2005-12-14 20:31:44
|
On Wednesday 14 December 2005 20:26, Nicholas Nethercote wrote: > On Wed, 14 Dec 2005, Julian Seward wrote: > >> wouldn't that be a good candidate: > >> http://www.fftw.org/ > > We already have an FFT benchmark, would the FFTW program also be dominated > by a single loop? Quite possibly, yes (at a guess). J |