Message boards :
Number crunching :
Gflop estimates?
Message board moderation
Previous · 1 · 2 · 3 · Next
Author | Message |
---|---|
EdwardPF Send message Joined: 26 Jul 99 Posts: 389 Credit: 236,772,605 RAC: 374 |
The table is derived by looking at my work unit task results and my wing mans work unit task results. I took my wing mans flopcounter and divided it by my flopcounter. I reported the AR, the his/mine and his application name. I am using SOG r3557. Ed F |
Raistmer Send message Joined: 16 Jun 01 Posts: 6325 Credit: 106,370,077 RAC: 121 |
I see, thanks. So, for VHAR FLOPs missed en masse. OK. But before diving into any fix I need to understand for what goals (besides just printing) it's used in modern BOINC ecosystem. SETI apps news We're not gonna fight them. We're gonna transcend them. |
Richard Haselgrove Send message Joined: 4 Jul 99 Posts: 14650 Credit: 200,643,578 RAC: 874 |
But where FLOPs are used currently (besides nice line in stderr output) ? Sorry, got interrupted by my old university phoning to ask, ever so politely, for us alumni to give it money. But strangely, it's relevant here. In the BOINC world, there's no direct measure of how much scientific computation is done. Instead - and we've talked about this before [*] - projects award credit, and BOINC reverse-calculates computational effort (flops) as if all credit was awarded at cobblestone scale rates. As we know, SETI is currently awarding below-parity credit: so anyone using BOINC calculations will be under-reporting the value of the volunteer community back to the project sponsors and funders. A few years ago, Eric gave a talk to a NASA-hosted SETI (generic) seminar, and when we watched the recording back, we could hear him mention a figure for the total computational power available via the SETI@Home project. It didn't match any number I could derive from BOINC sources. So my assumption was that Eric stuffs the reported Flops count into a database somewhere, and can produce numbers for more accurate scientific feedback on our progress and contribution to scientific partners. Now, where was I? [*] Observation of CreditNew Impact |
Raistmer Send message Joined: 16 Jun 01 Posts: 6325 Credit: 106,370,077 RAC: 121 |
for that FLOPs should be reported not only in stderr. And regarding awarded credit calculation - do they used currently (I know before CreditScrew they used, but now?) SETI apps news We're not gonna fight them. We're gonna transcend them. |
Richard Haselgrove Send message Joined: 4 Jul 99 Posts: 14650 Credit: 200,643,578 RAC: 874 |
OK, seems checkpoint reports real progress as it's counted. My question (in starting all this off) was more to do with what the SoG application reports as progress. Doing the same operation on an AVX CPU app (on BLC VLAR, as it happens), I got <prog>0.84698133</prog> <fraction_done>0.897888</fraction_done> Now, that's much more reasonable. In this case, I don't think that BOINC is faking it - just the old familiar GiGo. |
Raistmer Send message Joined: 16 Jun 01 Posts: 6325 Credit: 106,370,077 RAC: 121 |
I don't see FLOPs in res file. How they reported back to project then? SETI apps news We're not gonna fight them. We're gonna transcend them. |
Richard Haselgrove Send message Joined: 4 Jul 99 Posts: 14650 Credit: 200,643,578 RAC: 874 |
for that FLOPs should be reported not only in stderr. Displayed on BOINC's home page a few seconds ago: Those PetaFLOPS are reverse-calculated from credit (or, to be precise, RAC). |
Raistmer Send message Joined: 16 Jun 01 Posts: 6325 Credit: 106,370,077 RAC: 121 |
Yep, as I wrote I found place where BOINC receives value - and actuially that value more correct than prog/checkpoint. This will be fixed in next build for test. Let's concentrate on FLOPs (cause possible fix if really needed will take much more time and code walking). SETI apps news We're not gonna fight them. We're gonna transcend them. |
Raistmer Send message Joined: 16 Jun 01 Posts: 6325 Credit: 106,370,077 RAC: 121 |
And again, yep, I understand this - just don't understand how "our" FLOP counter fits there. SETI apps news We're not gonna fight them. We're gonna transcend them. |
Richard Haselgrove Send message Joined: 4 Jul 99 Posts: 14650 Credit: 200,643,578 RAC: 874 |
Let's concentrate on FLOPs (cause possible fix if really needed will take much more time and code walking). I think we've probably missed the boat on this discussion, by several years. Eric devised the flopcounting technique for credit scoring, and implemented it here - I think that, for floating-point computational projects, it's recognised as the most realistic reward mechanism yet devised for BOINC. But it does rely on - as you say - very complicated internal monitoring in project science apps. Not every small project is equipped to add the 'counter' to their application code. So, instead, David devised CreditNew as a way of scoring all projects without the programming overhead of flopcounting. And in the BOINC world, David trumps Eric. CreditNew has been around for over six years now, and gradually all vestiges of previous credit schemes have been removed from the codebase. To answer your specific question, cumulative flops was reported back to the scheduler via the RPC that returns all the other metadata - CPU time, elapsed time, etc. etc. It doesn't appear in current client RPCs, so I doubt Eric would be able to give a current figure if he repeated that NASA talk now. But as with so much modern 'progress', we've thrown away something that might have been useful. I still have one museum piece running old code for old times' sake - I may be able to post an example of flops reporting later this evening. |
Raistmer Send message Joined: 16 Jun 01 Posts: 6325 Credit: 106,370,077 RAC: 121 |
OK, thanks. So, to avoid confusion, I'll remove FLOPs line from stderr. And comment out (if not already) FLOP counting (but leave commented code for future reference in case it will be needed later). SETI apps news We're not gonna fight them. We're gonna transcend them. |
EdwardPF Send message Joined: 26 Jul 99 Posts: 389 Credit: 236,772,605 RAC: 374 |
Sounds good to me ... Will this eventually move to the general release so as to fade away into obscurity? ... I.E retire... ;-) Ed F |
Raistmer Send message Joined: 16 Jun 01 Posts: 6325 Credit: 106,370,077 RAC: 121 |
Sounds good to me ... Eventually yes but I hardly will update current beta just for that. But repo will be updated so come with next build anyway. EDIT: there is progress on iGPU front on Linux (Urs said debugging finished so some new test binaries could be generated). So FLOPs removal maybe will slip into Linux binary first... SETI apps news We're not gonna fight them. We're gonna transcend them. |
petri33 Send message Joined: 6 Jun 02 Posts: 1668 Credit: 623,086,772 RAC: 156 |
Well, no, FLOPs and progress not connected. Hi, I have not read any further on this thread when I write this reply (so I apologize any duplicate (q or a) possibly found).... Is it needed to report flopcounter during or after the task (with parallel GPU implementations) or Could it be just ignored by the executable (if counting is taking a lot of CPU as Raistmer said)? Does it have any scientific significance? Is it even checked (from stderr :D)? Some optimizations ignore a lot of the original code path and do not do as many floating points operations as the original one. And then some may do a lot more FP but save on the memory access. So is that number needed at all in stderr.txt? My original question was about the estimates for the WU's that was displayed in the boinc manager -- task properties -- nn Gflops. To overcome Heisenbergs: "You can't always get what you want / but if you try sometimes you just might find / you get what you need." -- Rolling Stones |
petri33 Send message Joined: 6 Jun 02 Posts: 1668 Credit: 623,086,772 RAC: 156 |
OK. I read further. Can I remove mine too?? To overcome Heisenbergs: "You can't always get what you want / but if you try sometimes you just might find / you get what you need." -- Rolling Stones |
Raistmer Send message Joined: 16 Jun 01 Posts: 6325 Credit: 106,370,077 RAC: 121 |
|
EdwardPF Send message Joined: 26 Jul 99 Posts: 389 Credit: 236,772,605 RAC: 374 |
more cpu/gpu cycles for science! Ed F |
Raistmer Send message Joined: 16 Jun 01 Posts: 6325 Credit: 106,370,077 RAC: 121 |
Cause RPC that reports FLOPs back to client deprecated and commented out in our code this estimate has nothing in common with in-app FLOPs counter. SETI apps news We're not gonna fight them. We're gonna transcend them. |
petri33 Send message Joined: 6 Jun 02 Posts: 1668 Credit: 623,086,772 RAC: 156 |
Thank You Sir. *nods* To overcome Heisenbergs: "You can't always get what you want / but if you try sometimes you just might find / you get what you need." -- Rolling Stones |
Raistmer Send message Joined: 16 Jun 01 Posts: 6325 Credit: 106,370,077 RAC: 121 |
Thank You Sir. *nods* :D And for the record I plan to replace all these progress += SpikeProgressUnits(fftlen) * ProgressUnitSize/NumFfts; With progress based on icfft/cfft_num value. Of course progress isn't linear by icfft vs elapsed time, but those *units were devised for CPU code anyway so don't actually linearise GPU progress. Will save few CPU cycles too (and simplify % done handling). SETI apps news We're not gonna fight them. We're gonna transcend them. |
©2024 University of California
SETI@home and Astropulse are funded by grants from the National Science Foundation, NASA, and donations from SETI@home volunteers. AstroPulse is funded in part by the NSF through grant AST-0307956.