but not the other:
258.96 driver
G 105M
Computing capability 1.1
485 MB graphics memory
Hi
Note that the G 105 M has just 8 CUDA cores, compared to 192 on your GTS 450. Even if you get it to accept CUDA tasks by updating the driver and freeing enough memory, I'm afraid it probably won't be faster to run compared to the CPU version.
It will take it a few days, though, to finish the non-Einstein GPU workunits it already has.
If it's no faster than a CPU, I don't see that as a problem; it's still better than having BOINC insist on getting GPU workunits from somewhere before it will even try to get any CPU workunits. The other sources of GPU workunits that will run on a G 105M are all doing something I find less interesting.
Apparently the issue of the BRP CUDA App on Mac OS 10.6 ("SnowLeopard") has been fixed with the latest CUDA 4.0 development driver 4.0.19 from NVidia, which requires the system update to 10.6.8.
I don't think we'll issue a Mac CUDA App for BRP3 anymore, though, but go for BRP4.
If you look at the sticky 'BRP4' thread at the top of this message board, and read all the posts, you'll see that the plan was:
* Use exactly the same application as before, but with a new BRP4 name
* Reset the version number to 1.00
* Re-use the existing plan_classes
If there is a change in processing speed, I can only assume that the characteristics of the data vary slightly between the Parkes telescope recordings we were scanning during BRP3, and the Arecibo data used for BRP4.
If you look at the sticky 'BRP4' thread at the top of this message board, and read all the posts, you'll see that the plan was:
* Use exactly the same application as before, but with a new BRP4 name
* Reset the version number to 1.00
* Re-use the existing plan_classes
If there is a change in processing speed, I can only assume that the characteristics of the data vary slightly between the Parkes telescope recordings we were scanning during BRP3, and the Arecibo data used for BRP4.
But it's still BRP3, not BRP4, perhaps that's the typo.
But they are differnt applications, just happening to have the same "user friendly" name http://einstein.phys.uwm.edu/apps.php. That should not cause problems even if BRP4 apps should increase versions numbers , right?
RE: but not the
)
Hi
Note that the G 105 M has just 8 CUDA cores, compared to 192 on your GTS 450. Even if you get it to accept CUDA tasks by updating the driver and freeing enough memory, I'm afraid it probably won't be faster to run compared to the CPU version.
CU
HBE
I've already updated the
)
I've already updated the driver.
That laptop has plenty of main memory.
It will take it a few days, though, to finish the non-Einstein GPU workunits it already has.
If it's no faster than a CPU, I don't see that as a problem; it's still better than having BOINC insist on getting GPU workunits from somewhere before it will even try to get any CPU workunits. The other sources of GPU workunits that will run on a G 105M are all doing something I find less interesting.
Apparently the issue of the
)
Apparently the issue of the BRP CUDA App on Mac OS 10.6 ("SnowLeopard") has been fixed with the latest CUDA 4.0 development driver 4.0.19 from NVidia, which requires the system update to 10.6.8.
I don't think we'll issue a Mac CUDA App for BRP3 anymore, though, but go for BRP4.
BM
BM
Nvidia just updated CUDA
)
Nvidia just updated CUDA drivers for Mac to 4.0.21. Hopefully it doesn't nix the fix.
I just got a bunch of Binary
)
I just got a bunch of Binary Radio Pulsar Search v1.00 (BRP3cuda32nv270), is this a typo?
They are running a wee bit faster, and use just about half of the CPU-time the old Binary Radio Pulsar Search v1.08 (BRP3cuda32nv270) were using.
Grüße vom Sänger
RE: ... is this a
)
No, it's called recyling :-)
If you look at the sticky 'BRP4' thread at the top of this message board, and read all the posts, you'll see that the plan was:
* Use exactly the same application as before, but with a new BRP4 name
* Reset the version number to 1.00
* Re-use the existing plan_classes
If there is a change in processing speed, I can only assume that the characteristics of the data vary slightly between the Parkes telescope recordings we were scanning during BRP3, and the Arecibo data used for BRP4.
RE: RE: ... is this a
)
But it's still BRP3, not BRP4, perhaps that's the typo.
Grüße vom Sänger
There is no typo. We are
)
There is no typo. We are using the same plan classes (and plan class names) in order not to have to modify the scheduler again.
BM
BM
RE: There is no typo. We
)
So ....v1.00.... is BRP4, and ....v1.0x.... with x=4-8 is BRP3?
What will happen if you have to update the app?
Grüße vom Sänger
Hi! But they are differnt
)
Hi!
But they are differnt applications, just happening to have the same "user friendly" name http://einstein.phys.uwm.edu/apps.php. That should not cause problems even if BRP4 apps should increase versions numbers , right?
CU
HB