Earlier quoted context omitted.
Another question, is CUDA actually fast enough? Because in bitcoin mining, it's always ATI/AMD and OpenCL because ATI cards are like ten times faster than Nvidia cards. This is because of architecture differencies. Does it not affect this postgres table-scanning task? I wonder if they did any benchmarks.
NVidia cards do not efficiently implement bit rotation, while AMD cards do, and it happens to be the core part of the SHA algorithm used for bitcoin. In general for an arbitrary task they're fairly close in performance.
Postgres on the GPU
51–60 of 79 posts
Re: Postgres on the GPU
#52Alas, Tim's been talking about this for two years now, and as far as we know he's the only one whose ever seen the code.
Re: Postgres on the GPU
#53Its written in CUDA, not OpenCL. Stop that.
Re: Postgres on the GPU
#54NVidia's CUDA only (for now?) Anyone can explain why opensource projects embrace CUDA over OpenCL? As I understand OpenCL is more generic API which could be potentially used with CPUs and GPUs.
Nvidia software has always been much better than AMD. AMD on Linux is a complet disaster. So if you work on GPU it's natural to go Nvidia.
So is nvidia. Both companies produce absolutely horrible drivers. Not just for linux either, tons of bluescreens, crashes and other windows instability issues are video driver bugs. That is what happens when the sole concern is speed, and stability is totally ignored.
Re: Postgres on the GPU
#55Earlier quoted context omitted.
Another question, is CUDA actually fast enough? Because in bitcoin mining, it's always ATI/AMD and OpenCL because ATI cards are like ten times faster than Nvidia cards. This is because of architecture differencies. Does it not affect this postgres table-scanning task? I wonder if they did any benchmarks.
That is really interesting. I had to look it up. https://en.bitcoin.it/wiki/Mining_hardware_comparison The fastest Nvidia showing is the Tesla S2070 which is a $18k Server with 8 GPU's! It can just barely keep up with a slightly over clocked single gpu HD7970.
Re: Postgres on the GPU
#56Earlier quoted context omitted.
I've been working on a rather large computation library using OpenCL. OpenCL is useful for providing an abstraction over multiple device types. If you are only interested in producing highly-tuned parallel code to execute on NVidia hardware, I suggest sticking to CUDA for the above reasons. I utilised the OpenCL programming interface to write code that would run the same kernel functions on CPU and/or GPU devices (us…
FYI regarding highly-tuned code -- An ex ATI/AMD GPU core designer told me that the price you pay for writing optimized code in OpenCL versus the device specific assembler is roughly 3x. Something to keep in mind if you're targeting a large enough system to OpenCL and you find spots that can't be pushed any faster.
Since I am working on code generation of Kernels to perform dynamic tasks, I can't afford to write at the lowest level available. (I'm accelerating Python/Ruby routines though so OpenCL gives a significant bonus without much pain at all.)
[1] http://dl.acm.org/citation.cfm?id=2066955 (Sorry about the paywall, I access through University VPN)
Re: Postgres on the GPU
#57Earlier quoted context omitted.
There are probably a lot of factors. I worked on CUDA code for around a year, and used to understand the landscape pretty well, but if I were to start a high-performance computing project today I'd probably take my lumps and go with OpenCL. There would be a lot of lumps. Firstly, CUDA is just more mature; there is a very large and well-established set of libraries for a lot of common operations, there is a decent siz…
So why would you go with OpenCL? Is it portability? For a while I thought that was worth it but I am having a hard time remaining convinced of that.
Re: Postgres on the GPU
#58Earlier quoted context omitted.
FYI regarding highly-tuned code -- An ex ATI/AMD GPU core designer told me that the price you pay for writing optimized code in OpenCL versus the device specific assembler is roughly 3x. Something to keep in mind if you're targeting a large enough system to OpenCL and you find spots that can't be pushed any faster.
Unlike previous versions, OpenCL 2.0 been shown to only be about 30%[1] slower than CUDA and can approach comparable performance given enough optimisation. Since I am working on code generation of Kernels to perform dynamic tasks, I can't afford to write at the lowest level available. (I'm accelerating Python/Ruby routines though so OpenCL gives a significant bonus without much pain at all.) [1] http://dl.acm.org/cit…
Re: Postgres on the GPU
#59Earlier quoted context omitted.
There are probably a lot of factors. I worked on CUDA code for around a year, and used to understand the landscape pretty well, but if I were to start a high-performance computing project today I'd probably take my lumps and go with OpenCL. There would be a lot of lumps. Firstly, CUDA is just more mature; there is a very large and well-established set of libraries for a lot of common operations, there is a decent siz…
So why would you go with OpenCL? Is it portability? For a while I thought that was worth it but I am having a hard time remaining convinced of that.
Nvidia is in the slow process of eventually discontinuing further CUDA support, and it is recommended to write new code in OpenCL only.
Re: Postgres on the GPU
#60Earlier quoted context omitted.
That is really interesting. I had to look it up. https://en.bitcoin.it/wiki/Mining_hardware_comparison The fastest Nvidia showing is the Tesla S2070 which is a $18k Server with 8 GPU's! It can just barely keep up with a slightly over clocked single gpu HD7970.
I'm not a miner, so correct me if I'm wrong, but that seems like a bit of an apples-to-oranges comparison. Tesla cards (and the servers designed around them) are intended for specific use cases: mission-critical enterprise solutions and scientific HPC. As a result, they run slower processor and memory speeds in comparison to nVidia's own consumer products, use ECC memory, and are optimized for double-precision over s…