Welcome to MilkyWay@home

Amount of concurrent blocks


Advanced search

Message boards : Number crunching : Amount of concurrent blocks
Message board moderation

To post messages, you must log in.

AuthorMessage
ProfileMC707
Avatar

Send message
Joined: 5 Jun 09
Posts: 2
Credit: 1,704
RAC: 0
1 credit badge10 year member badge
Message 36989 - Posted: 6 Mar 2010, 2:33:13 UTC

Ok so I just saw this option in my milkyway@home preferences. I just want to know exactly what it is, and more specifically, why default is 128 compared to the humongous 50000 maximum, and what would be an appropriate amount. Finally, would 50 k burn my GPU or something xD?

Thanks in advance.
ID: 36989 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
NuclearRage

Send message
Joined: 10 Mar 10
Posts: 6
Credit: 955,895
RAC: 0
500 thousand credit badge10 year member badge
Message 37117 - Posted: 10 Mar 2010, 3:39:43 UTC

would also like to know this as well , i am new to the project
ID: 37117 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Emanuel

Send message
Joined: 18 Nov 07
Posts: 280
Credit: 2,442,757
RAC: 0
2 million credit badge10 year member badge
Message 37146 - Posted: 10 Mar 2010, 19:43:51 UTC

I don't have a technical understanding of the preference, but I believe it essentially indicates how long the application can request control over the GPU at a time. That means that for higher values, the application can do more calculations in a row without giving control back to the operating system, but that also means that anything the operating system wants to do (such as drawing to the screen to update what you see) will have to wait until it gets control. So it's a trade-off between system responsiveness and Milkyway application performance - however, the amount of performance gained by using a higher setting may be negligible.
ID: 37146 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
nmeofdst8

Send message
Joined: 7 Mar 10
Posts: 11
Credit: 1,284,443
RAC: 0
1 million credit badge10 year member badge
Message 37147 - Posted: 10 Mar 2010, 19:55:55 UTC - in response to Message 37146.  

I don't have a technical understanding of the preference, but I believe it essentially indicates how long the application can request control over the GPU at a time. That means that for higher values, the application can do more calculations in a row without giving control back to the operating system, but that also means that anything the operating system wants to do (such as drawing to the screen to update what you see) will have to wait until it gets control. So it's a trade-off between system responsiveness and Milkyway application performance - however, the amount of performance gained by using a higher setting may be negligible.


I'm 99% sure from experience in other areas...its "memory" block usage. Basically how much Video RAM can be dedicated for tasks. Thus the "interface lag" at "higher values"

I have a GTX280, set it to 50000 and can't tell a difference video wise unless I play a full screen video file, then get the occassional chop.
ID: 37147 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Anthony Waters

Send message
Joined: 16 Jun 09
Posts: 85
Credit: 172,476
RAC: 0
100 thousand credit badge10 year member badge
Message 38264 - Posted: 7 Apr 2010, 2:57:05 UTC

The field concurrent blocks dictates how much of the GPU will be used by the application in a single iteration. The more concurrent blocks the faster the workunits are finished, but it will cause more user interface lag.
ID: 38264 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
ProfileSutaru Tsureku

Send message
Joined: 30 Apr 09
Posts: 95
Credit: 24,003,766
RAC: 0
20 million credit badge10 year member badge
Message 40537 - Posted: 19 Jun 2010, 1:33:10 UTC
Last modified: 19 Jun 2010, 1:44:48 UTC

I tested on my manufacturer OCed GTX260-216 @ 680/1500/1250 MHz [core/shader/RAM] the stock 128 and 50,000 and the calculation times are the same.

Which blocks are meant with this settings?

GTX260-216 - GT200b, 55nm:
Shader? This are 216.
CUDA Cores? This are 27.
ROPs? This are 28.
Shader-Cluster? This are 9.
Texture units? This are 72.
Fillrate Pixel (GP/s) - 16,128.
Fillrate Texture (GT/s) - 41,472.
[wikipedia.org/GeForce_200_Series]

Maybe I would need to insert the correct value of my GPU?


Thanks! :-)


[EDIT: The screen is connected to the onboard GPU. The GTX260-216 do only CUDA.]
ID: 40537 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Astromancer.
Avatar

Send message
Joined: 21 Nov 09
Posts: 49
Credit: 20,618,688
RAC: 0
20 million credit badge10 year member badge
Message 40543 - Posted: 19 Jun 2010, 18:42:26 UTC - in response to Message 38264.  
Last modified: 19 Jun 2010, 18:43:57 UTC

The field concurrent blocks dictates how much of the GPU will be used by the application in a single iteration. The more concurrent blocks the faster the workunits are finished, but it will cause more user interface lag.


Much like Sutaru I didn't see any difference in completion time or interface responsiveness between 128 and 50,000. And my screen is run through the video card.

GTX260 55nm with 216 cores as well. Perhaps it would have more effect with single precision calculations where the gpu is more completely used for the computation?


nmeofdst8, As for memory usage, GPU-Z reports the same ammt of memory used no matter what the setting is set to.
ID: 40543 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
newfuntek

Send message
Joined: 12 Jun 11
Posts: 2
Credit: 154,955
RAC: 0
100 thousand credit badge8 year member badge
Message 49861 - Posted: 4 Jul 2011, 5:51:18 UTC
Last modified: 4 Jul 2011, 5:56:44 UTC

With gtx560ti and 384 concurrent (as many as stream processors) and no cpu in milkyway preferences I have gained 2 minutes from 8 min to 6 min, any higher value results in no acceleration or no run at all cuda milkyway chunks.
The only problem I cannot remove cpu tasks n-body simulation, even i have forbidden cpu for ever. it is heat maker, always 100% on one cpu processor.
ID: 49861 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
newfuntek

Send message
Joined: 12 Jun 11
Posts: 2
Credit: 154,955
RAC: 0
100 thousand credit badge8 year member badge
Message 49866 - Posted: 4 Jul 2011, 9:40:25 UTC - in response to Message 49861.  

Maybe I was wrong, it only works with 128, anybody has any clues about this feature? With 128 still have 6 min without any cpu...
ID: 49866 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Matt Arsenault
Volunteer moderator
Project developer
Project tester
Project scientist

Send message
Joined: 8 May 10
Posts: 576
Credit: 15,979,383
RAC: 0
10 million credit badge9 year member badge
Message 49935 - Posted: 6 Jul 2011, 6:33:56 UTC - in response to Message 49866.  

Maybe I was wrong, it only works with 128, anybody has any clues about this feature? With 128 still have 6 min without any cpu...
This isn't a feature. I think the old CUDA version might have used it. If you're changing it now it won't do anything.
ID: 49935 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote

Message boards : Number crunching : Amount of concurrent blocks

©2020 Astroinformatics Group