I have looked into manually threshholding parts of the signals for that sort of thing (NaN's etc.) Using special IPP functions for that purpose, but haven't gotten around to it yet. There are supposedly massive speed increases possible without significant precision penalty (NaN's are already NaN's after all) .  Vtune shows there are significant speed penalties going on in the FFT/IFFT for processing denormal data. [In the other SSE routines too for that matter]

If you have an app that makes valid results now, Maybe you could try a separate build with "Flush Denormal results to zero" on the optimiser .cpp files only.  It may not Validate, The precision penalty may be high for the brute force 'Flush to Zero', but even if not valid results, the time improvement data may be valuable. 

Iit would give an indication of how much speedup might be obtainable with more careful use of the more precise thresholding routines instead. [Also nothing stops us trying to make custom thresholding, or finetuning any existing data maintenance already in the code (there is a little there I think) ]

Jason

[Afterthought: Joe has mentioned to me in the past that there is only one place, I think in the baseline smoothing, that requires full reversability, so I am thinking that just maybe selective liberal use of heavy handed thresholding all the other places might be possible...]

I suppose that could imply there might not be much effect from underflows with that data.  It's a while ago since I ran vtune with TestWU-1, So when I build again I'll make sure to grab some fresh profile data and look for SSE  and x87 Input assists.

I'm glad you found the WU still validates. that maybe means we could be more aggressive later if needed.

Jason

Oh well, was worth a try ,
  that might be telling us something, maybe there is some denormal data somewhere, that needs to be that way ?  maybe in the becnchmarks some random data.  good to know this stuff

Jason

Yes, it built okay  though it has been a while since I rebuilt it.  I'd be wondering which boinc API version you built against first.

I think I know the commented out constructor you mean.  I felt uneasy about that too so so I restored it, but commented out the '0' parameter instead, allowing use of the default constructor.  Not sure if it made any difference.

Jason

Deleted result file first:

Ran with -bench first to check --- > no probs there

Running now [not -bench] a couple of minutes, no probs yet, watching it.

Are you using knabench or your own batch file maybe?  if your own then you mightn't have a valid Init_data.xml in the folder ?

Jason

[Hope it isn't a long one!... It's election day here in Oz and so I have to go and get some beer to be well lubricated for the trip to the polling booth ]

.. 10 mins so far no crash [slow machine or long workunit .. or both ]

Note ... After it finishes I will check it will start off from your checkpoint Indeed.

No, you need run it only 1-2 min, just see if it restores from checkpoint, noo need to complete task
And what it be if result.sah will not be deleted? Cause in normal run under BOINC result file stays...
I run app just by running exe-file from the same directory where data files contained. Minimal run environment for SETI is exe-file + these 3 files, init_data.xml will change some app defaults but not required (as my previous experiments show).

Oh for your checkpoint run I kept your state.sah & result.sah when starting (I has saved them in a folder.

Hmm I always had problems if there was no init_data.xml so I've always used one of the ones from the test packages.