Message boards :
Number crunching :
CPU time on GPU tasks?
Message board moderation
Author | Message |
---|---|
draco Send message Joined: 6 Dec 05 Posts: 119 Credit: 3,327,457 RAC: 0 |
Hello! i have two different computers - one with old ati 4350 videocard, and another with never nvidia gt630 rev 2 videocard. both is setup to use lunatics for seti. but when i compare it's astropulse results - ATI setup uses far less cpu, than Nvidia. http://setiathome.berkeley.edu/results.php?hostid=7199324 that is ati, average cpu time is about 2000 - 2500 CPU seconds on workunits about 70 000 - 80 000 seconds "large". it looks like consumes very small cpu time. Nvidia shows differently thing: http://setiathome.berkeley.edu/results.php?hostid=7210225 - its CPU time is almost the same as task time - i e task times is 15 007, cpu time - 14 227. why that? looks like ati works more effective ( do less cpu work, and almost all on GPU)? |
Mike Send message Joined: 17 Feb 01 Posts: 34261 Credit: 79,922,639 RAC: 80 |
Thats because of different syncronisaton inside driver model. Raistmer could fix that for windows version but nobody implemented it for Linux yet. With each crime and every kindness we birth our future. |
Richard Haselgrove Send message Joined: 4 Jul 99 Posts: 14654 Credit: 200,643,578 RAC: 874 |
Note that it's only the Astropulse tasks where CPU time is close to run time on the NVidia card. |
draco Send message Joined: 6 Dec 05 Posts: 119 Credit: 3,327,457 RAC: 0 |
it means, in reality, there is not that worse ( cpu time is not equivalent task time on nvidia too)? |
draco Send message Joined: 6 Dec 05 Posts: 119 Credit: 3,327,457 RAC: 0 |
yes, i note that. but on ati the same AP tasks ( it cannot crunch MB tasks due to buggy ati driver in catalyst 13.1, as i understand) looks different in that aspects... |
Raistmer Send message Joined: 16 Jun 01 Posts: 6325 Credit: 106,370,077 RAC: 121 |
In reality NV's OpenCL runtime spins on perhaps any waiting for kernel/transfer completion. Also, NV OpenCL runtime makes only synchronous transfers (no matter what OpenCL semantics dictates). So, CPU used for those spins, CPU wastes energy for active polling. To reduce this on Windows Sleep() calls used with -use_sleep switch. I hope Urs will implement similar option under Linux when he will have some time for that. EDIT: on OpenCL source level app used almost the same code. All these differencies in CPU usage lie inside OpenCL runtime implementation from particular vendor. 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 |
P.S. and we have third supported vendor now, Intel. There synching after each runtime call ensures low CPU usage. It's third separate case. Both NV and ATi only loose from such total synching. 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 |
In linux .. To reduce the CPU usage with AP save this as libsleep.c Copy the resulting libsleep.so somewhere, but not to boinc seti directory since it will be deleted from there. This will replace the yield with sleep and give other threads with lower priority too a chance to run. Yield would give only threads of the same or higher priority a slice. #include <time.h> #include <errno.h> /* * To compile run: * gcc -O2 -fPIC -shared -Wl,-soname,libsleep.so -o libsleep.so libsleep.c * * To use: * daemon --check $BOINCEXE --user $BOINCUSER +10 "LD_PRELOAD=/etc/init.d/libsleep.so $BOINCEXE $BOINCOPTS --dir $BOINCDIR >>$LOGFILE 2>>$ERRORLOG &" >& /dev/null * * * */ int sched_yield(void) { struct timespec t; struct timespec r; t.tv_sec = 0; t.tv_nsec = 1000000; // 1 ms while(nanosleep(&t, &r) == -1 && errno == EINTR) { t.tv_sec = r.tv_sec; t.tv_nsec = r.tv_nsec; } return 0; } 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 |
draco Send message Joined: 6 Dec 05 Posts: 119 Credit: 3,327,457 RAC: 0 |
petri33: thank you very much. always a pleasure to meet deep knowing person. i try this way in next week. |
draco Send message Joined: 6 Dec 05 Posts: 119 Credit: 3,327,457 RAC: 0 |
Hello, petri33. got a problem - i try to compile your .c as it described inside ( gcc -O2 -fPIC -shared -Wl,-soname,libsleep.so -o libsleep.so libsleep.c ), but no any output, no error messages - nothing. also cannot find libsleep.c after... ? i do this command in folder, where i put an your libsleep.c file... my system is slackware64 14.0 |
petri33 Send message Joined: 6 Jun 02 Posts: 1668 Credit: 623,086,772 RAC: 156 |
I'll check the command line when I get back from work in 9 hours. In the meantime You could save the libsleep.c file again and try to compile again. That sounds odd that the source file would have disappeared. 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 |
Seems to work for me. I copied the source from the original message. #mkdir libsleep [make your compilation directory] #cd libsleep [go there] #cat > libsleep.c [ctrl+ins to paste the copied source code followed by Ctrl+d to stop pasting] #ls [see what's here] libsleep.c [ok, the source file] # gcc -O2 -fPIC -shared -Wl,-soname,libsleep.so -o libsleep.so libsleep.c [compile. No messages should appear, just the prompt for the next command.] # ls [see what's here now] libsleep.c libsleep.so [ok, source and the new library] # To use the new libsleep.so place it somewhere. Then export LD_PRELOAD=/your/path/libsleep.so before running BOINC (in BOINC startup script). 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 |
K2ULR Send message Joined: 31 Jul 05 Posts: 4 Credit: 2,393,713 RAC: 1 |
I wonder if this is related to a recent phenomenon: it seems the display of Time To Completion shows impossible durations... like 640 hours 52 minutes 57 seconds. On this machine, the process completes in 8 or 9 hours, which was a common TTC in the past. This only seems to be the case with work units that are NOT Astropulse WUs. Weird. 73 de Ray |
Claggy Send message Joined: 5 Jul 99 Posts: 4654 Credit: 47,537,079 RAC: 4 |
I wonder if this is related to a recent phenomenon: it seems the display of Time To Completion shows impossible durations... like 640 hours 52 minutes 57 seconds. On this machine, the process completes in 8 or 9 hours, which was a common TTC in the past. This only seems to be the case with work units that are NOT Astropulse WUs. You're running particularly ancient Boinc versions, (Boinc 5.4.9), these Boinc had a single DCF, the DCF will swing wildly as different apps complete their Wu's, you're also got the project side APR in use (Application Processing Rate), here the correct processing Rate isn't supplied to the client until 11 validations are done for each app version, with one of your hosts only just completing it's 11th Astropulse validation, it's times should settle down, the other with just one Astropulse validation will have wacky duration estimates for some time yet, you could (or should) upgrade to a more recent Boinc, but given your macs i don't know what the most recent Boinc they can run is. Claggy |
JohnDK Send message Joined: 28 May 00 Posts: 1222 Credit: 451,243,443 RAC: 1,127 |
Seems to work for me. I copied the source from the original message. Guess I will have to install Win7, using Ubuntu but have no idea about compiling or anything Linuxish. |
©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.