I've done some math, experiments, and orange slicing and peeling this weekend :-), and I can't help but feel that in theory, the formula for runtime should be something like this:
T(alpha) = T0 + b*(2alpha-1)²
where alpha = seq/period - floor(seq/period)
(the "phase" as computed by Mikes webpage, in [0,1). )
Now, I don't have that many runtime figures in Excel or CSV or whatever neat format, so if you guys want to try this on your data that would be cool.
In the meantime, archae sent me his data via e-mail, thanks!!!
So I plotted runtime against (2*alpha-1)^2 and applied linear regression on this, the result looks nice. Anyway, given the "noise" in the runtime, it probably doesn't matter too much whether you use this formula or the one suggested previously, it might just be a little easier to handle.
The first graph shows runtime measurements for 4.26 , the second for 4.15. The straight line is a linear regression approximation courtesy of OpenOffice.
There definitely seems to be a familiar curve to plots of completion times to sequence number. Some have long wavelengths and others have short ones. I plotted all frequencies together just to see what I would get. This is about 3600 data points from my V8 MacPro
There definitely seems to be a familiar curve to plots of completion times to sequence number. Some have long wavelengths and others have short ones. I plotted all frequencies together just to see what I would get. This is about 3600 data points from my V8 MacPro
Bingo! It certainly looks like peak and trough run times are search frequency dependent, but is it the same app version right through?
Thanks, very useful :-)
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
Not the same app in all the data. That is data that I am missing. I have used at least 3 different apps. I have used the standard, 4.10, and now 4.22.
I'd say if you have 4 apps used, then the peak/trough are at worst only mildly search frequency dependent. Again very useful! :-)
Cheers, Mike.
Here are results from one of my Linux hosts: 2 app versions,
x-Axis is (2*phase-1)^2 to give a linear graph
y axis is runtime
color of dots represent frequency.
Unfortunately the variation of frequncy is only 80 Hz, but to me it appears that the variation in runtime for different frequency but same phase is no larger than that indicated by the rather small variations in credit assigned to the different workunits. After all the original credit scheme did take runtime into consideration (there were some fast low-frequency units with << 200 credits at the low end), just the cyclic nature was missed.
Here are results from one of my Linux hosts: 2 app versions ....
Very nice plot - particularly the use of the colour scale to indicate frequency. On the lower line where you have 4 ~700 dark violet points with a whole bunch of higher frequency (780-790) red points, you'd be hard pressed to say that frequency was making much of a difference, it would appear.
What's going on around 0.45 on the X-axis?
It's interesting that the two lines for the 2 app versions seem to be reasonably parallel. Is it possible to use coloured dots for one app version and say coloured squares or triangles for the other? It's not entirely clear which points belong to which app version around 0.45.
It's interesting that the two lines for the 2 app versions seem to be reasonably parallel.
Yup, the improvements in the later app version were concerning only the "non-cyclic" part, so you get a constant time (in sec) speedup rather than
Quote:
Quote:
Is it possible to use coloured dots for one app version and say coloured squares or triangles for the other? It's not entirely clear which points belong to which app version around 0.45.
I'll have to seperate the data for the different app versions manually, I don't have that in the data right now.
Quote:
What's going on around 0.45 on the X-axis?
That's quite interesting, because it also seems to be present in the data from archae86 (above).
I think this hints to a small systematic error in the cycle model that will become more significant when the frequencies increase.
Our cycle model together with the way that the workunits traverse the sky-grid (pole-to pole) would indicate that
a) runtime is a function of declination / "latitude" coordinate only
b) runtime is highest exactly on the poles and smallest at the equator.
Well, I did some test with my own skygrids and discussed this with Bernd also, and what I see is that
a) and b) are not strictly true but this averages out as long as the workunit contains sky-points covering a relatively large range of RA/"longitude" values.
At higher frequencies, the skygrid size increases (quadratically, as we know) to a point where 1200 skypoints are not enough to form a full cicle, so the "longitude" effect will no longer average out in a single WU.
RE: RE: RE: t = a(1 -
)
IMO, I'd say so...and you can take that to the bank.........or not...... ;-)
Hi guys, I've done some
)
Hi guys,
I've done some math, experiments, and orange slicing and peeling this weekend :-), and I can't help but feel that in theory, the formula for runtime should be something like this:
T(alpha) = T0 + b*(2alpha-1)²
where alpha = seq/period - floor(seq/period)
(the "phase" as computed by Mikes webpage, in [0,1). )
Now, I don't have that many runtime figures in Excel or CSV or whatever neat format, so if you guys want to try this on your data that would be cool.
CU
Bikeman
Hi! In the meantime,
)
Hi!
In the meantime, archae sent me his data via e-mail, thanks!!!
So I plotted runtime against (2*alpha-1)^2 and applied linear regression on this, the result looks nice. Anyway, given the "noise" in the runtime, it probably doesn't matter too much whether you use this formula or the one suggested previously, it might just be a little easier to handle.
The first graph shows runtime measurements for 4.26 , the second for 4.15. The straight line is a linear regression approximation courtesy of OpenOffice.
CU
Bikeman
There definitely seems to be
)
There definitely seems to be a familiar curve to plots of completion times to sequence number. Some have long wavelengths and others have short ones. I plotted all frequencies together just to see what I would get. This is about 3600 data points from my V8 MacPro
RE: There definitely seems
)
Bingo! It certainly looks like peak and trough run times are search frequency dependent, but is it the same app version right through?
Thanks, very useful :-)
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
Not the same app in all the
)
Not the same app in all the data. That is data that I am missing. I have used at least 3 different apps. I have used the standard, 4.10, and now 4.22.
RE: Not the same app in all
)
I'd say if you have 4 apps used, then the peak/trough are at worst only mildly search frequency dependent. Again very useful! :-)
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
RE: RE: Not the same app
)
Here are results from one of my Linux hosts: 2 app versions,
x-Axis is (2*phase-1)^2 to give a linear graph
y axis is runtime
color of dots represent frequency.
Unfortunately the variation of frequncy is only 80 Hz, but to me it appears that the variation in runtime for different frequency but same phase is no larger than that indicated by the rather small variations in credit assigned to the different workunits. After all the original credit scheme did take runtime into consideration (there were some fast low-frequency units with << 200 credits at the low end), just the cyclic nature was missed.
CU
BRM
RE: Here are results from
)
Very nice plot - particularly the use of the colour scale to indicate frequency. On the lower line where you have 4 ~700 dark violet points with a whole bunch of higher frequency (780-790) red points, you'd be hard pressed to say that frequency was making much of a difference, it would appear.
What's going on around 0.45 on the X-axis?
It's interesting that the two lines for the 2 app versions seem to be reasonably parallel. Is it possible to use coloured dots for one app version and say coloured squares or triangles for the other? It's not entirely clear which points belong to which app version around 0.45.
Thanks very much for producing this.
Cheers,
Gary.
RE: It's interesting that
)
Yup, the improvements in the later app version were concerning only the "non-cyclic" part, so you get a constant time (in sec) speedup rather than