"Although NVIDIA CUDA in the present form has some limitations, it is not an exaggeration to say that this technology could well be the most revolutionary thing to happen in computing since the invention of the microprocessor. It’s that fast, that inexpensive and has that much potential. "
…very true! However, for all of its positive spin the above user manual page is a good illustration of how the need to work around lack of x64 Windows support is lessening the market impact of CUDA. This is a real missed opportunity for NVIDIA that I hope will be remedied before November.
“Through some incomprehensible failure of the Fundamental Structure of the Universe, NVIDIA (normally the world leader in rapid response to modern Windows needs) has as of this writing implemented 64-bit Linux but not 64-bit Windows.” (http://demo.manifold.net/doc/nvidia_cuda.htm)
For sure that’s the reason ;-). Also if an nVidia statement explaining the reasons for this very delayed support would be fine… we’ll for sure still survive the remaining two months till the release in November. I just hope the story won’t be repeated.
You have to remember that Manifold is one of the most famously pro-Microsoft extremist companies around, so part of catering to our user community (who are by definition Windows people) is that the company reflexively makes fun of any effort that puts Linux ahead of Windows.
I personally disagree with some of that. There are times when it can make perfect sense to do Linux work and even to put Linux work ahead of Windows. This could well be one of those times.
The majority of existing parallelization and cluster work in the scientific community has been done in Linux or UNIX, not Windows. Linux is not where the volume applications are, but Linux is indisputably where most of the technical experience is today with parallelization. There are much fewer people with extensive parallelization experience in Windows (Manifold being the rare exception). If you want to move a lot of units in volume applications it makes sense that first you want to enlist existing experience so that you have some engineering talent recruited to develop those volume applications.
So it makes perfect sense to me that NVIDIA would go after that pre-existing pool of experience in Linux even if the ultimate objective is volume applications in Windows. I might have done the same thing, getting all the guys I could in the scientific community launched with CUDA using Linux and then having faith that kickstarting the technology that way would inevitably (as software always does) end up in high volume Windows applications as well. If you want to get a good fire burning you strike your sparks where there is lots of tinder ready to burn, not at the larger logs, even though the large logs will ultimately sustain the biggest fire.
There are also cases where development is aided by a two step process. A lot of that BLAS and FFT and other code which one might expect would necessarily be leveraged within NVIDIA’s own internal development organizations quite likely has come out of Linux projects, not Windows projects. So if NVIDIA wanted to have a rich toolset available for the use of its own internal development teams I can see how it might have had no choice but to implement Linux support first. And one major advantage of Linux is that, let’s face it, it is easier to get 64-bit environments going within Linux than it is within Windows, where there are a few more, ahem, evolutionary nuances that one must keep in mind.
My take on this is that I wish Windows had been first, but I can see both the business case and the developmental manager’s case how doing Linux first would be the best path for having a much stronger Windows x64 offering, even if that Windows x64 offering is delayed a few months.
Whatever the case, CUDA is astounding and revolutionary and nothing is holding people back from getting going with it right now today in 32-bit Windows. November will be here before you know it and until then there is plenty of CUDA work to get done to keep us all occupied.
I’m of course hoping that the nVidia crew are close to officially supporting WinXP 64-bit… However, for anyone curious, correctly-written programs compiled as 32-bit run just fine under WinXP 64, so far as my experience goes.
The main problem I did have (other than not being able to link directly to 64-bit apps) is that in case of a program crash or termination without freeing the memory reserved on the device, that memory is locked apparently until reboot. The only other issue I had was that this can and will crash your computer if you attempt to access memory outside of your allocations (wrong array indices, for example). I’m not sure if that’s protected against in the official drivers, though.
I dealt with the issue by breaking my program into three parts: a DLL containing just the NVCC-compiled stuff with basic C wrappers for those functions, a Win32 host program that loads the DLL, and a 64-bit client program that connects to the Win32 program using sockets to access CUDA. It was a bit of a pain to put together but works for my purposes.
setup: WinXP 64, Intel Quad Core CPU, dual 8800 GTS (using both simultaneously without issue), PCI-E slots are both 16x.
Just want to say → Thank you! ← to NVIDIA for a really outstanding 169 Forceware release for XP x64. 64-bit CUDA works perfectly with 64-bit Manifold - we are issuing a quick update to Manifold to take advantage of this.
I’ve tried new beta on 2k3 server x64 and everything seems to be fine. Thanks to NVidia. Anyway it’s a bit interesting qeuestion - why nither 1.0 no 1.1 versions doesn’t officialy support 2k3 server?
As promised, today’s Manifold update utilizes 64-bit CUDA on 64-bit Windows (beta 169.09 Forceware drivers). If you are running Manifold 8.00, download the new update free today.
In other news, this same update is the first software product to provide full support for Microsoft’s new November CTP spatial capabilities in SQL Server 2008 (Microsoft codename “Katmai”).
The two news items are related because GIS data is often very large data that is stored in spatial DBMS. The ability to use CUDA in 64-bits is critical to work with such large data efficiently, and the ability to store vast data (hundreds of gigabytes) in SQL Server 2008 provides the right infrastructure for analytic work using CUDA. It’s a perfect match of technologies.
64-bit Windows CUDA works so well and so fast that we are re-writing our entire system to use CUDA wherever possible. It’s going to go from several dozen functions in the current release to several hundred in the next. Thank you, NVIDIA!