3 ms·

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

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).

polskibus 14y ago
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?
- m_mueller 14y ago
  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 https://github.com/muellermichel/Hybrid-Fortran
  - polskibus 14y ago
    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.
    - m_mueller 14y ago
      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-Tim-Kaldewey.pdf http://cis565-spring-2012.github.com/lectures/02-13-Search-T... http://www.cs.virginia.edu/~skadron/Papers/bakkum_sqlite_tr.pdf http://www.cs.virginia.edu/~skadron/Papers/bakkum_sqlite_tr.... http://gpuscience.com/software/postgresql-gpu-pgstrom/ 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.
__alexs 14y ago
That's 250 GigaBit/s, this is 320 GigaByte/s. No?
- Sephr 14y ago
  It's gigabytes, not gigabits.
- unwind 14y ago
  From the GDDR5 Wikipedia entry (http://en.wikipedia.org/wiki/GDDR5 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.
  - __alexs 14y ago
    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.
    - m_mueller 14y ago
      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.
    - ippisl 14y ago
      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).

polskibus 14y ago

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?

m_mueller 14y ago
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 https://github.com/muellermichel/Hybrid-Fortran
- polskibus 14y ago
  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.
  - m_mueller 14y ago
    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-Tim-Kaldewey.pdf http://cis565-spring-2012.github.com/lectures/02-13-Search-T... http://www.cs.virginia.edu/~skadron/Papers/bakkum_sqlite_tr.pdf http://www.cs.virginia.edu/~skadron/Papers/bakkum_sqlite_tr.... http://gpuscience.com/software/postgresql-gpu-pgstrom/ 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.

__alexs 14y ago

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

Sephr 14y ago
It's gigabytes, not gigabits.
unwind 14y ago
From the GDDR5 Wikipedia entry (http://en.wikipedia.org/wiki/GDDR5 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.
- __alexs 14y ago
  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.
  - m_mueller 14y ago
    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.
  - ippisl 14y ago
    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).