Hacker News Reader

Comment by m_mueller | Hacker News Reader

One should note that we already get 250GB/s peak on the GDDR5 used in NVIDIA Tesla K20x. Intel claims 320GB/s peak for the fastest MIC. What is claimed in this article is not that new then. From experience with tesla, you can usually expect about 70% of the peak bandwidth (and using Intel MIC with conventional x86 codebases it tends to be less, but that's second hand knowledge).

View on HN

The problem is you need to transfer data out to use CUDA. I'm assuming with HMC the CPU can access data with promised 320GB/s speed?

That's true, yes. Which is why the HPC community is moving towards having / leaving everything on GPU memory (except for the odd monitoring peaks, initializations and gathering of output of course). The GPU's architecture nowadays is general purpose enough that you can make this work - the tooling is still a work in progress though[1]. There's even some work going on for using GPUs for database purposes.

When it comes to bandwidth, the newest generation Teslas / Geforces tend to have a factor of 5 more than the latest Xeon running on all cores - I've talked to people at IBM who were able to get this speedup for random access as well - so it usually scales at 5x, no matter whether you look at peak, sustained or random access bandwidth.

[1] My current project is actually mainly done for this reason: https://github.com/muellermichel/Hybrid-Fortran

Thanks for the insight, interesting project. Would you mind sharing some links about gpu in/as database? I'm very interested in the idea, yet usually find only marketing babble ("yes we're working on it, it's been promising" kind of thing) Would love to dive into some research papers on the topic.

I'm not an expert when it comes to GPGPU for DBs (heck, I'd like to even find one ;) ), but see below what I could come up with.

This is a presentation from a member of the IBM Almaden research group I've been talking to at GTC. I can't find much else online, their work seems to be unpublished, but maybe if you ask nicely, they could give you a few pointers: http://cis565-spring-2012.github.com/lectures/02-13-Search-T...

http://www.cs.virginia.edu/~skadron/Papers/bakkum_sqlite_tr....

http://gpuscience.com/software/postgresql-gpu-pgstrom/

Edit: Tbh. this still seems to be a very young field of research - which is good if you're a graduate student or a member of a private research institute, but as a startup I'd think twice before spending a few man years for making this work.

That's 250 GigaBit/s, this is 320 GigaByte/s. No?

It's gigabytes, not gigabits.

From the GDDR5 Wikipedia entry (http://en.wikipedia.org/wiki/GDDR5):

The newly developed GDDR5 is the fastest and highest density graphics memory available in the market. It operates at 7 GHz effective clock-speed and processes up to 28 GB/s with a 32-bit I/O.[4] 2 Gbit GDDR5 memory chips will enable graphics cards with 2 GiB or more of onboard memory with 224 GB/s or higher peak bandwidth.

So, no, it seems that's bytes.

Wow. That does seem to require a crazy 512-bit wide bus though. The info I can find on HMC seems like it is achieving these speeds on a 16-bit bus and with much lower power requirements than even DDR3 so far.

Ok now that's new to me. If you can go 320GB/s on a measly 16bit bus, then it's really feasible to have this as your main memory. On the other hand imagine what you can do with this memory on a GPU, you'd probably get over 1TB/s there. Actually, that's something NVIDIA already has on their roadmap as far as I remember seeing it at GTC.

In the spec they talk about 8-links each is 16 bit(or lanes in their jargon) , which comes out to 128 bit (or 256 bit - there are some configurations where input and output bits are on different pins).

Reply on news.ycombinator.com