stephenbrooks.orgForumMuon1Bug Reports4.4 Results counting low
Username: Password:
Search site:
Subscribe to thread via RSS
2004-05-13 02:50:39
This my first impressions for the first run.

The Mpts counting on my box dropped more than 60% down.  I know the calculation time lasts much longer now with much more parameters, but this will have an irregular impact to the overall stats.  So people keep on running 4.3 will earn much more.  The exact figure should be easy to calculate with a hyperthreading box running one instance 4.4 and the other 4.3

I left the solenoids to 15cm in the lattices directory and the client randomly choose that calculation as expected, but the results didn't continue at that level, where the results.dat should have seeded as with 4.3. None of the results got higher as a little over 9.8, though I had always a lot above 10 with my 10+ results.dat

For the solenoids method also negative number are now appearing, why are they negative anyway ???

The results don't compute in the utility Results2CSV.exe, however with the load of more than 256 parameters, my spreadsheets excel97 or OO1.1.1 don't support an import anyway.  I'll have to convert them into colums first for some statistical analysis, duh.

Else, the little critter runs smooth Big Grin
Stephen Brooks
2004-05-13 04:00:56
The negative scores are explained in versions.html a bit - essentially the scores are supposed to be identical for results greater than 0.1%, but below that I use other criteria to give more resolution.

When you say "60% down" do you mean the program works at 0.4x the speed or 0.6x the speed?  The decrease in speed was due to me changing the way the solenoid fields were clipped, so in v4.4 they overlap a lot and hence a particle will be inside several fields usually, leading to more calculation.  This has also changed their trajectories slightly so the scores are different, though I'm glad this has only changed it by a fraction of a percent.

If it has caused the client to slow down to 0.4x its original speed, I will put the clipping back in version 4.41, as it was before, but maybe only for the SolenoidsTo15cm optimisation.
2004-05-13 04:43:41
I've noticed a significant drop in speed as well - particularly on single process systems, but maybe that's just my eyes The behaviour does also appear to be more sporadic as far as speed goes.  I've witness sort of "Mpts bursts" mid simulation.

I guess I'll run the benchmark utility to really get a better idea though.  Would it be fair to test a SolenoidsTo15cm run with the same parameters, once w/ and once w/out clipping?
2004-05-13 04:50:01
No, I don't think that it in fact slowed down, I think just the Mpts output lasts much longer now and is not directly comparable.

Usually this new box did around 25000 Mpts/day, ok dumping yesterday was a bit late, however I was really surprised to see this mornings dump only 6000 something. 

I'll watch that better now and maybe others can keep an eye on this too.  I'll remove the solenoidsto15cm to show a proper relation .

However I love to see things changing Big Grin other than this boring just cracking periods Wink
2004-05-13 04:52:27
OT: What the heck is an "Edfuncted Member" ?????
2004-05-13 04:54:29
I think I used an "edfunced google" once!

Congrats on your new status Wink
2004-05-13 05:23:10
I have this :

procedure TDebugger.OnAsmFunc(s : string);
if Assigned(CPUForm) then begin
CPUForm.edFunc.Text := s;
InAssembler := true;

and this:

externfuncpointer edfunc[];/* Array of editing function pointers */

anything else just garbage, so and now what?  Have mercy with my Alka Seltzer... erh Oppenheimer.. what was it then?
Stephen Brooks
2004-05-13 06:25:28
9 out of 10 members prefer: Google Edfunced Seerch, the edfunced way to start your internet.
2004-05-13 08:32:54
Yuoor seerch - parteecle exceelooraytiir - deed nut metch uny ducooments.  Um gesh dee bork, bork!

What I did?  Frown
2004-05-13 08:50:18
Bushtarts Wink me puhr outlender, nix capito ur slang alveighs Razz
2004-05-13 10:12:19
I’ve been spending a little time running the clients side by side on an identical SolenoidsTo15cm test and have found that v4.4 starts out at ~.375x the speed (I’m referring to Mpts) of v4.34. As the simulation advances, the speed of v4.4 deteriorates.  Currently it (v4.4) is running at ~.275x the speed of the previous client and it is less than 60 Mpts into the simulation.

I’ll post more precise observations with numbers later...
2004-05-13 21:18:55
So won't the stats now be kinda unbalanced since those running v4.4 are 60% behind the others who are still running v4.34?

Maybe a separate stats table should be in place just like for v4.2 and solenoids only.
[OCAU] badger
2004-05-14 04:34:10
I have noticed this too.

I ran muonbench today on my barton 2500+ (idle all day except for muon) here is the log:

Uptime (secs),Mpts in file,Estimate kpts/sec

on v4.34 a few days ago I got this:

it is running at less than 25% of the speed (in mpt production)

I also noticed it on my 2000+ and a p4 3.0 HT.

running it on another machine (2.4Ghz p4 I think) today seemed to run at normal outputs.

something is definately rotten in the state of DPAD...
[OCAU] badger
2004-05-17 19:49:25
now if I read correctly, this lower output per clock cycle is due to more stuff being simulated for each particle per timestep, ie you need more processing per mpts.  While this may be good for the scientific aspect of the project, you will find that a lots of the stats junkies will hold off changing to v4.4 for as long as possible.
I myself have been passed by three guys in the total stats since I started v.4.4 (although I haven't yet uploaded the results - so it is a little moot...) although as a physicist I will stick with v4.4 (although I still have a machine I haven't converted yet...)

if the "new" mpts takes ~5x the computation as the v4.34 mpts, perhaps you need a new way of scoring.
2004-05-17 20:07:47
I do also aggree with you badger.
2004-05-18 00:54:41
Why not determine (kind of) exactly how much longer things take?  Then the new client can just multiply the mpts amount by this certain value before writing it to results.txt/.dat
I know there are some cheat-aspects in this (I'm not going into that just now), but I definately don't want another stats-reset.
Stephen Brooks
2004-05-18 03:31:55
I'm going to switch back to a comparable method of solenoid clipping in the upcoming v4.41. The reason I took it out was the first method was dependent on Z-coordinate (i.e. hard-coded for a solenoid channel going in a particular direction), so not very elegant.  All other particle tracking codes I've seen don't let the solneoid fields extend through into other magnets, so I'm not going to either.
2004-05-18 06:02:37
My point exactly about the stats ranking Stephen.  But gahhh!  If I knew that v4.41 would be faster and more comparable to v4.34 then I would have held off ungrading until then.  As it is I've already upgraded 80% of my muon farm, anyway I didn't really join for the stats and I'm also not one of the fastest producers.
Stephen Brooks
2004-05-18 06:45:28
To be honest, I'd forgotten about this modification to the solenoid clipping when I released v4.4. During my removal of "hard-coded" stuff, I just commented it out since doing so would if anything make the results scientifically a little better.  Seeing as it wasn't really a "bug", I didn't leave a marker (I put /**/ on bits of 'dangerous' code) there.  Anyway, I've just this morning tested the new geometrical clipping routine and it works fine.  The results should be closer to v4.34's, though not identical.
: contact : - - -
E-mail: sbstrudel characterstephenbrooks.orgTwitter: stephenjbrooksMastodon: strudel charactersjbstrudel

Site has had 17707873 accesses.