Tim Prince wrote: > Nirav Shah wrote: > >> I am working on study of data sharing characteristic of Blackscholes >> application of Parsec benchmark. I need to come up with better data >> sharing foot print of execution. > >> No expression is evaluated in loop nor any particular intermediate >> result is used more than once. Given this, can I get benefit in terms >> of lesser clock cycle to execute the computation if done in a single >> statement as compared to done over multiple statements with local >> variables? >> The test cases supplied in the parsec download don't exercise the numerical model. The longest one runs about 2 seconds on my laptop with the insane options in the Makefile; somewhat faster with any normal set of options, including options suitable for profiling. The time is spent on processing option strings and C++ new[] and delete (in spite of the source file being named .c and throwing warnings even at minimum warning level). Did you not check into that? As to the idea you and your predecessor have that making the source code and build procedure more obscure and less functional will improve performance, I doubt that will attract much sympathy. My suggestions about fixing the polynomial evaluation would have been remarkably on target, if you fixed some of the other issues. One of those being that the numerical section is set up so as to spend a lot of time in casts between float and double, should it ever be executed. Does everyone get disgusted when they see the publicity section saying that this benchmark has the advantage of no HPC content, then finding out that one must download all the BLAS and gsl source code etc. to get at a buggy collection of doubtful use? With all those illustrious names posted on the site, one would have expected a little quality.
