Chris Theis <Christian.Theis_at_CERN.CH> sent on November 27th, 2010:
|---------------------------------------------------------------------------------------------------------------------------------------------|
|"Hi Makis,
|
|
|
|> Are we sure that Fluka is only, or at least major, dependant on the
double precision performance of the (C,G)PU? |
|
|
|My personal answer is no, not at all. But I'm sure the FLUKA developers
|
|can provide more insight and probably numbers on this."
|
|---------------------------------------------------------------------------------------------------------------------------------------------|
Hi all,
No, the dominant physical processes for a neutron colliding with a
detector and for a proton colliding with the atmosphere are different,
so naturally what the speeds of these different simulations of these
scenarios depend on differ. Use a profiler such as RootCause from OC
Systems to identify bottlenecks hindering fast simulations:
WWW.OCSystems.com/rc_performance.html
RootCause supports more languages than those listed on the website. If
it does not already support FORTRAN, then you might be able to request
for FORTRAN to be added to the list of supported languages.
|---------------------------------------------------------------------------------------------------------------------------------------------|
|"> I faintly remember a presentation that was stateing that Geant4
performance was following more closely the SPECint numbers than the SPECfp|
|numbers. With the explanation that the disicions > that an MC code has
|
|to make are as expensive as the actual calculations. I wonder if this
is |
|correct also for Fluka."
|
|---------------------------------------------------------------------------------------------------------------------------------------------|
Makis did not seem to doubt the "explanation" re Geant4. Do not trust
Geant4 people. Papers and other media in which claims about Geant4
have been made contain untruths.
Code in pseudoC++ based on Geant4 tends to be slower than code in
pseudoFORTRAN77 based on GEANT3. C++ makes it easier for bad
programmers to produce slower executables than FORTRAN 77 does.
I have not checked, but I suspect that the g77 code of Fluka
has not followed the slowness introduced to Geant by Geant4 (at least
not so severely).
However, what does it matter what anyone thinks? A measurement is more
useful than a useless opinion: use a profiler such as RootCause to get
a better opinion.
|---------------------------------------------------------------------------------------------------------------------------------------------|
|"The performance tests merely benchmark calculations which are usually
|
|done by very small and isolated routines."
|
|---------------------------------------------------------------------------------------------------------------------------------------------|
Actually S.P.E.C. makes a lot of effort to not use such kernel
benchmarks. This is not to say that S.P.E.C. had never done so, but on
average the S.P.E.C. benchmarks are based on serious usage.
I have submitted a proposal for S.P.E.C. to distribute benchmarks
based on code connected to Geant4. I do not want it to be slow. I use
Ada (
WWW.AdaIC.org
) instead of C++, thank goodness.
|---------------------------------------------------------------------------------------------------------------------------------------------|
|" Thus, the respective result
|
|yields rather limited evidence for the performance of complex
programs."
|
|---------------------------------------------------------------------------------------------------------------------------------------------|
This cannot be completely avoided, even if every line of code of Fluka
or Geant or anything else is run many times in a benchmark.
|---------------------------------------------------------------------------------------------------------------------------------------------|
|"In practice this strongly depends on branching which is often a killer
|
|in terms of speed."
|---------------------------------------------------------------------------------------------------------------------------------------------|
Conditional moves have been supported by many instruction sets for
many years, and they alleviate this problem.
|---------------------------------------------------------------------------------------------------------------------------------------------|
" Also for GPGPUs most of the speed benefit gained is
|
|determined by how well your algorithm/problem lends itself to stream
|
|processing concepts rather than FP performance alone."
|
|---------------------------------------------------------------------------------------------------------------------------------------------|
Yes.
|---------------------------------------------------------------------------------------------------------------------------------------------|
|"If you happen to have a link to the presentation that you mentioned
then |
|I'd appreciate if you could send it to me.
|
|
|
|Cheers
|
|Chris"
|
|---------------------------------------------------------------------------------------------------------------------------------------------|
Please cite it on the email list. I am also interested in learning
more concerning it.
Regards,
Paul Colin
Received on Mon Nov 29 2010 - 23:27:40 CET
This archive was generated by hypermail 2.2.0 : Mon Nov 29 2010 - 23:27:40 CET