Report on new optimized Astropulse apps for Windows

[Leaps-from-Shadows]

On Cruiser-

v4.37 SSE3 EPF:  Slower than v4.35 SSE3 app, with a projected completion time of 31 hours or so (21.1% complete).  Slowest time for v4.35 SSE3 app was around 29 hours.

v5.00r69 SSE3:  Faster than all previous apps, with a projected completion time of 26 hours or so (63.2% complete).

I'll post more updates once the units complete.  The unit crunching with v4.37 is the last one for that app - all others have been branded for the v5.00 app.  I've got 10 of those including the one crunching (six for Main, four for Beta).  I'm currently using the v5.00r69 SSE3 app for both Main and Beta.

[Richard Haselgrove]

My testing note on that build, running on a Q6600, reads "Did shave an hour+ off the runtime, though - 18:32:47 down to 17:16:42.": which is why I chose it for the release (final build in the ongoing quest for v4 optimisation, before programming effort switched to v5.00 compatibility).

Since v4 is now effectively dead, I think the only sensible thing to do is to soldier on until the last one is crunched, accepting the 2 hr penalty with as much grace as you can muster (through gritted , no doubt).

But it's still a useful reminder of the unpredicable variability of the optimisations on AMD versus Intel, and and indication of the sort of tests we need to run (project timing permitting) in the run up to future releases.

[Raistmer]

@Leaps-from-Shadows 
could you post link on your host ?
I need timings from stderr to see what part of program become slower...

[Richard Haselgrove]

I think it must be RID 1065144181 on host 4521634 (Phenom) - as yet unfinished.

Cosmic_Archer has a similar report for RID 1060056077 on host 2889590 (Opteron) - also as yet unfinished.

[Raistmer]

Thanks Richard.
Unfinished tasks have no timings, so will await when they become finished

[Richard Haselgrove]

Thanks Richard.
Unfinished tasks have no timings, so will await when they become finished

Yeah, just did clickable links so you can check often - these tasks are on Main, so subject to 24-hour purge (assuming validation ).

[Leaps-from-Shadows]

Note:  I do have one work unit that started crunching with the v4.35 optimized app before I switched to the v4.37 optimized app.

It had approximately two hours on v4.35 app and approximately eight hours on v4.37 app (it was about 33% complete) before it ended with Found 30 single pulses and 30 repeating pulses, exiting message.  I don't know how useful it will be, but here's a link to it anyway:  Task details.

The work unit done with only the v4.37 optimized app will complete approximately 23 hours from this post (27.1% complete).

[Jason G]

Version 4.37 contains some radar blanking related overhead.  You'll notice also in the stderr.txt that SPLIT_COMPLEX is enabled in 4.37, but not in newer builds.  V5 showed it to be faster without that, and also has an improved filter that lab tests showed little/no improvement, but yielded a nice speedup over previous builds.

Given the lifespan of 4.37 is going to be a total of a couple of days, I wouldn't worry about that edition too much, especially considering it wasn't meant for release, only to pad the transition of code-base, which happened to be useful (it seems by accident) for hoisting checkpoints up a notch [Well less that, than squeezing out a few obscure bugs].

Jason

[Later: ooops ]
E8400         cpusecs   credits   cr/cpusec
MB akv8SSE41   2260   44.1   0.019513274
ap 4.37   42941.67   760.36   0.01770681
ap 5.00   36760.94   759.74   0.020667045

[Raistmer]

[Later: ooops ]
E8400         cpusecs   credits   cr/cpusec
MB akv8SSE41   2260   44.1   0.019513274
ap 4.37   42941.67   760.36   0.01770681
ap 5.00   36760.94   759.74   0.020667045

LoL Now AstroPulse will attract credit likers until the point of boykott for too big credits for hour
It's clear that state of optimization in MB build higher, but credit is lower.... Good reason to blame that credit system again

[Leaps-from-Shadows]

Woohoo!  Cruiser has finished its first v5.00 work unit at Beta!

Task details.

Credits (868.56) divided by CPU seconds (94123.61) = 0.009227865 credits per CPU second.

Other work units on Cruiser:
Shorty Multibeam - AK_v8_win_SSE3 app - Credits (16.84) divided by CPU seconds (2264.34) = 0.007037046 credits per CPU second.
Average Multibeam - AK_v8_win_SSE3 app - Credits (44.12) divided by CPU seconds (5268.02) = 0.008375063 credits per CPU second.

Once again confirming that AMD's Phenom efficiency is very low in comparison to Intel's Core 2 efficiency for SETI@home work units.

[Jason G]

Nice, That's the first Live WU I've seen that is granted & against stock wingman, because all my v5's so far have gone to pending.

@Raistmer: Sure for 32 bit users,  I'm pretty sure 64 bit multibeam is still a faster option, but it is in the right direction, and some machines 32 bit AP might indeed show equal or slightly better.  Some time will tell.

[Richard Haselgrove]

My v5s have been validating just fine at Beta, and here's a nice one at Main: 367818871. Be quick - turns into a pumpkin at midnight UTC!

Leaps - I don't want to burst your bubble, but Beta is currently overpaying credit - the tracking average was skewed by a disasterously slow v4.37 build. Main is paying as near as dammit 760 cobbles, making Cruiser's AP rate ~0.00807454. Still respectable, but not such an outright winner.

I won't be commenting on this at Main: the difference isn't all that significant, and it's nice to see someone saying something nice about AP credit for a change.

[Raistmer]

Hm...second result I see today and it contains 30 repetitive pulses... (Joe's addition of pulse counters is very handy )
It seems overflow is pretty common for AP. Some troubles with threshoulds or with blanking?
@ Richard - is it possible to say had this result non-zero indices.txt or not ?


[probably some "blanking counter" should be added to stderr too]

@All testers
Please keep eye on indices.txt in working directory (if it become non-zero length or not).
And if you keep result file, please, keep indices.txt too along with result and WU files.

[Jason G]

The high incidence of overflows seen might possibly be related to what I mentioned when I realised they were using psuedo-random number generators to generate the noise data.  Unfortunately most psuedo random number generators are based on shift register designs that exhibit an approximation to a maximum length sequence, a special kind of signal used to excite an impulse response from active systems due to the fact that the impulse response is a broadband pulse. .  We have to follow the project's lead in this matter, though I would have suggested using a fixed signal deformation function with known characteristics that could be subtracted as known artefacts from the results, much like the FFT splitter artefact in MB.  But I haven;t been practising my bone pointing enough, and Australia is just too far away to reach over and knock some heads together.

[Richard Haselgrove]

@ Richard - is it possible to say had this result non-zero indices.txt or not ?

Sorry, can't say - I didn't look. But I'll start spot-checking now. Also, I haven't been preserving data/result files since we went live, but I see that box has had two short ones already: I'll start preserving them again, in view of this discussion.

Jason, could you teach me to bone-point? I must be nearer.... Or better yet, can you teach Josef?