4 ms·

MapD is doing some fascinating stuff, but I'm really skeptical about the business need for speed. I was working on a similar concept (GPU-accelerated Hadoop Ma

MapD is doing some fascinating stuff, but I'm really skeptical about the business need for speed. I was working on a similar concept (GPU-accelerated Hadoop MapReduce) at the time, and everyone I talked to in the Valley (and believe me, I knocked on a lot of doors) was perfectly happy with their Hadoop jobs running overnight or in an hour instead of instantaneously. It also amazed me how many people were using Hadoop only for the distributed storage. Maybe data scientists love taking coffee breaks... In the end, I scrapped the project because nobody wanted it -- everybody said they were only doing I/O bound work, which my solution didn't really accelerate. Interestingly enough, I talked to people from Fusion.io (data center PCI-E SSDs) who mentioned that everybody told them that they didn't need Fusion because they were only doing compute bound work. A YC company, BigCalc, was trying to do a similar thing with accelerating R (by rewriting library routines in highly-optimized pure C), targeting hedge funds, but suffered a similar fate as my map reduce project. Shockingly, people just don't need speed.

semi-extrinsic 10y ago
I think your conclusion can be amended to "the people who are willing to pay for more speed get the most value for money by creating or buying an application-specific solution rather than a generic one". Like your hedge fund example: why pay for accelerated R, when you can spend just a little more money on hiring a low-level C/assembly programmer instead and get 50x more speedup? It's not just startups, big companies suffer the exact same problem. Look at Portland Group's OpenACC initiative, for instance, which intends to make GPU acceleration as easy to use as OpenMP, with pragmas etc. But everyone interested in GPUs just go and run straight CUDA or OpenCL code instead, there are essentially no "casual GPU acceleration users". Also see Cray Chapel.
- Hydraulix989 10y ago
  This is especially true for Wall Street. I know some hedge funds are even working with FPGAs and ASICs.
  - seanp2k2 10y ago
    http://algo-logic.com http://algo-logic.com FPGA network cards that run business logic on order books before they even get into the CPU. Pretty hard to beat an approach like that. By the time you've executed a single instruction, you've already lost the race :) Edit: spelling
- Hydraulix989 10y ago
  That's very true.
tener 10y ago
Perhaps people from Wall Street would have different needs?
- Hydraulix989 10y ago
  People in Wall Street build this stuff in house because their secret sauce is so proprietary -- they're also the ones experimenting with ASICs, FPGAs, custom network switches, and microwave transmitters (for cutting latency).
  - blahi 10y ago
    That sounds more like HFT which is such a small part of Wall Street that it practically doesn't exist.
    - Hydraulix989 10y ago
      In other words, you're saying that the guys on Wall Street who would use something like MapD are "such a small part of Wall Street that it practically doesn't exist?"
paulasmuth 10y ago
To me the problem seems more that on a GPU you can only execute fast queries on fairly small datasets. I would assume that the space of problems that still fit into a few gigs of GPU RAM but need to be answered rapidly with a lot of parallelism is fairly small. In my anecdotal sample, most of the users of hadoop/bigquery/etc seem to use it less because of raw query speed but more because the datasets are simply to large for any classical solution (i.e. much larger than fits into RAM on a single machine)
- tmostak 10y ago
  You can fit up to 256GB of GPU RAM in a standard server these days, backed by terabytes of CPU RAM as cache. In a rack we can easily deploy on terabytes of GPU RAM. This is big enough to handle datasets of over a hundred billion rows, which is not big data by everyone's standard but big enough that its almost intractable to handle in real-time with other solutions, particularly if the use cases requires a lot of scans (witness Mark's other benchmarks).
  - paulasmuth 10y ago
    256GB is 256 billion bytes. So you can only fit over a hundred billion rows into 256GB if you have zero overhead and every row is smaller than roughly two bytes... ;) [so you couldn't even store a single proper integer in each row in your example] Also, querying a static dataset that you can fit completely into RAM is not exactly "intractable to handle in real-time" without a GPU. You can do that just fine using the CPU right now. Case in point: Even MySQL can handle 256gb of rows in memory with ease if you give it that much ram... Essentially, any single-machine database (gpu or not) can only process the same datasets that traditional single-machine databases (like MySQL) can already handle, albeit maybe a bit faster. I think a good example for a "newsql" usecase that does _not_ fit into classical solutions like MySQL or Postgres would be web tracking (clickstream) data: Even a medium sized web property (say alexa top 100 in germany or france) will generate dozens of gigabytes of tracking data per hour. over the period of months, this adds up to hundreds of terrabytes of data. There is no way to load that much data in one piece into any of the classical databases. EDIT: Maybe I should add a disclaimer: I'm the founder of another open-source database product that could be considered a competitor to MapD.
tmostak 10y ago
Hi, CEO of MapD here. I agree that while some users don't need this level of speed, many do. Hadoop use cases are often very different than those that demand the speed of in-memory processing for real time answers. Think about all the money going into high-performance solutions like Spark, HANA, Vertica, Redshift, Exadata, MemSQL, etc. And many use cases demand even more speed, which is where GPU acceleration comes in. We just launched this year but already are being used in telco, hedge fund, social media, adtech, defense and retail deployments, with many more on the way. Most of our customers have been inbound, motivated by a common pain point of not having real-time visibility into their datasets. For example, Hadoop would not be acceptable for our use cases at Verizon, where troubleshooting needs to occur in real-time and not with lags measured in hours. I'm a firm believer in horses for courses. Not everyone needs the fastest tech, but for those that do, it makes all the difference.

semi-extrinsic 10y ago

I think your conclusion can be amended to "the people who are willing to pay for more speed get the most value for money by creating or buying an application-specific solution rather than a generic one". Like your hedge fund example: why pay for accelerated R, when you can spend just a little more money on hiring a low-level C/assembly programmer instead and get 50x more speedup? It's not just startups, big companies suffer the exact same problem. Look at Portland Group's OpenACC initiative, for instance, which intends to make GPU acceleration as easy to use as OpenMP, with pragmas etc. But everyone interested in GPUs just go and run straight CUDA or OpenCL code instead, there are essentially no "casual GPU acceleration users". Also see Cray Chapel.

Hydraulix989 10y ago
This is especially true for Wall Street. I know some hedge funds are even working with FPGAs and ASICs.
- seanp2k2 10y ago
  http://algo-logic.com http://algo-logic.com FPGA network cards that run business logic on order books before they even get into the CPU. Pretty hard to beat an approach like that. By the time you've executed a single instruction, you've already lost the race :) Edit: spelling
Hydraulix989 10y ago
That's very true.

tener 10y ago

Perhaps people from Wall Street would have different needs?

Hydraulix989 10y ago
People in Wall Street build this stuff in house because their secret sauce is so proprietary -- they're also the ones experimenting with ASICs, FPGAs, custom network switches, and microwave transmitters (for cutting latency).
- blahi 10y ago
  That sounds more like HFT which is such a small part of Wall Street that it practically doesn't exist.
  - Hydraulix989 10y ago
    In other words, you're saying that the guys on Wall Street who would use something like MapD are "such a small part of Wall Street that it practically doesn't exist?"

paulasmuth 10y ago

To me the problem seems more that on a GPU you can only execute fast queries on fairly small datasets. I would assume that the space of problems that still fit into a few gigs of GPU RAM but need to be answered rapidly with a lot of parallelism is fairly small. In my anecdotal sample, most of the users of hadoop/bigquery/etc seem to use it less because of raw query speed but more because the datasets are simply to large for any classical solution (i.e. much larger than fits into RAM on a single machine)

tmostak 10y ago
You can fit up to 256GB of GPU RAM in a standard server these days, backed by terabytes of CPU RAM as cache. In a rack we can easily deploy on terabytes of GPU RAM. This is big enough to handle datasets of over a hundred billion rows, which is not big data by everyone's standard but big enough that its almost intractable to handle in real-time with other solutions, particularly if the use cases requires a lot of scans (witness Mark's other benchmarks).
- paulasmuth 10y ago
  256GB is 256 billion bytes. So you can only fit over a hundred billion rows into 256GB if you have zero overhead and every row is smaller than roughly two bytes... ;) [so you couldn't even store a single proper integer in each row in your example] Also, querying a static dataset that you can fit completely into RAM is not exactly "intractable to handle in real-time" without a GPU. You can do that just fine using the CPU right now. Case in point: Even MySQL can handle 256gb of rows in memory with ease if you give it that much ram... Essentially, any single-machine database (gpu or not) can only process the same datasets that traditional single-machine databases (like MySQL) can already handle, albeit maybe a bit faster. I think a good example for a "newsql" usecase that does _not_ fit into classical solutions like MySQL or Postgres would be web tracking (clickstream) data: Even a medium sized web property (say alexa top 100 in germany or france) will generate dozens of gigabytes of tracking data per hour. over the period of months, this adds up to hundreds of terrabytes of data. There is no way to load that much data in one piece into any of the classical databases. EDIT: Maybe I should add a disclaimer: I'm the founder of another open-source database product that could be considered a competitor to MapD.

tmostak 10y ago

Hi, CEO of MapD here. I agree that while some users don't need this level of speed, many do. Hadoop use cases are often very different than those that demand the speed of in-memory processing for real time answers. Think about all the money going into high-performance solutions like Spark, HANA, Vertica, Redshift, Exadata, MemSQL, etc. And many use cases demand even more speed, which is where GPU acceleration comes in. We just launched this year but already are being used in telco, hedge fund, social media, adtech, defense and retail deployments, with many more on the way. Most of our customers have been inbound, motivated by a common pain point of not having real-time visibility into their datasets. For example, Hadoop would not be acceptable for our use cases at Verizon, where troubleshooting needs to occur in real-time and not with lags measured in hours. I'm a firm believer in horses for courses. Not everyone needs the fastest tech, but for those that do, it makes all the difference.