Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

1.1B Taxi Rides on Kdb+/q and 4 Xeon Phi CPUs

tech.marksblogg.com

Post reply on HN
Print view View original

61–70 of 104 posts

Re: 1.1B Taxi Rides on Kdb+/q and 4 Xeon Phi CPUs

#61

Post by LeifCarrotson »

WhitneyLand wrote: post #56
LeifCarrotson wrote: post #29

Earlier quoted context omitted.

All conclusions are only valid for similar workloads, but each of MapD and GPUs, Q/kdb+ and Xeon Phi, Redshift, Athena, Big Query, Presto, and Elasticsearch claim to be fast, inexpensive, easy to work with, and otherwise great for Big Data. Which ones really are fast? How fast is fast? How much is this going to cost? Do I need 5 nodes or 50? A few examples of some useful conclusions: - Just because a relatively well-…

These conclusions don't seem very useful because either they are already well established or are not valid. Some examples: Just because a relatively well-optimized PostgreSQL database on a regular workstation takes 5 minutes to run a query doesn't mean you can't get special hardware to run that query faster than you can type. Already well established for years with systems like redis, and more recently with gpu datab…

The speed comparisons may be well known to you, but as someone only really using trivial desktop app SQLite databases, they weren't known to me. Thanks for pointing out my errors!

> I don't see how it's possible for 104GB of csv text data to decompress into only 125GB. For cvs to compress only ~20%...doesn't make sense.

The CSV file itself is around 500 GB. The internal representation, which might use binary formats for numbers, or compress text, uses 125 GB. Redshift expands it to 2TB for all the indexing and mapping.

> Bigger problem: The MapD software itself will be $50,000.

Ouch. That's a rather large oversight. Is the author affiliated with MapD, perhaps?

Re: 1.1B Taxi Rides on Kdb+/q and 4 Xeon Phi CPUs

#62

Post by astrodust »

AlphaSite wrote: post #31
shaklee3 wrote: post #26

Earlier quoted context omitted.

GDDR5 can typically do 240GB/s access time on a typical GPU, and there are multiple chips on many cards (Tesla K80). The newer cards use HBM2 and can do 732GB/s ( http://www.nvidia.com/object/tesla-p100.html ).

HBM2 is 1024GB/s (256 per stack).

1TB/s is pretty nuts by today's standards but I bet it'll elicit a yawn in ten years time. Amazing indeed.

Re: 1.1B Taxi Rides on Kdb+/q and 4 Xeon Phi CPUs

#63

Post by protomyth »

Twirrim wrote: post #59
mmcclellan wrote: post #19

This was a good idea for a test. I'll definitely check out the author's other stuff. Commenting briefly on cost: while the article mentions the free 32 bit version early on, the actual benchmarks were done using the commercial version. I've had the impression the comercial version was cost prohibitive for us poor folks. For those interested in experimenting with Xeon Phi though, it looks like you can get started for…

If you just want to meddle with a Xeon Phi, you can get some as cheap as $300: https://www.amazon.com/Intel-BC31S1P-Xeon-31S1P-Coprocessor/... , though that's from the 3100 rather than 7200 family, and so won't perform as fast. That kind of money puts it more into the hobby territory, though.

Is there a difference in how you program the different Xeon Phi families?

Re: 1.1B Taxi Rides on Kdb+/q and 4 Xeon Phi CPUs

#65

Post by mtanski »

protomyth wrote: post #63
Twirrim wrote: post #59

Earlier quoted context omitted.

If you just want to meddle with a Xeon Phi, you can get some as cheap as $300: https://www.amazon.com/Intel-BC31S1P-Xeon-31S1P-Coprocessor/... , though that's from the 3100 rather than 7200 family, and so won't perform as fast. That kind of money puts it more into the hobby territory, though.

Is there a difference in how you program the different Xeon Phi families?

With the new generation there is now a difference. This is because this generation has Phis in both addin card (PCIe) and a bootable CPU package (when you run Linux or windows or whatever on the Phi).

Generally with the PCIe one you're running something like OpenCL and with system CPU package you run threads and processes like you normally would.

Technically you could run software directly on the old addin cards since they boot to Linux but you had handle the distribution, running and communication of your software with the host. (you could run any x86_64 binary)

Re: 1.1B Taxi Rides on Kdb+/q and 4 Xeon Phi CPUs

#66

Post by mtanski »

I've build columnar OLAP databases and database engines in C++ for work. Now I'm doing it in my free time. Based on my experience the Phi and it's architecture is very exciting for OLAP databases workloads.

Reasons:

- Even in a OLAP database you end up with quite a few places that have very branchy code. Research on GPU friendly algorithms on things like (complex) JOINS and GROUP BY is pretty new. Additionally complex queries will functions and operations that you might not have a good GPU implementation for (like regex matching)

- Compression. You can use input data that compressed in anyway that there is a x86_64 library for. So you can now use LZ4, ZHUFF, GZIP, XZ. You can have 70+ independent threads decompressing input data (it's OLAP so it's pre-partitioned anyways). (Technically branching, again)

- Indexing techniques that cannot efficient implemented on the GPU can be used again. (Again branching)

- If you handle your own processing scheduling well, you will end up with near optimal IO / memory pattern (make sure to schedule the work on the core with local memory) and you not bound PCIe speed of the GPU. With enough PCIe lanes and lots of SSD drives you process as near memory speeds (esp. when we'll have Xpoint memory)

So the bottom line is if can intelligently farm out work in correct size chunks (it's OLAP so it's prob partitioned anyways) the the Phi is fantastic processor.

I'm primarily talking about the bootable package with Omni-Path interconnect (for multiple).

Re: 1.1B Taxi Rides on Kdb+/q and 4 Xeon Phi CPUs

#67

Post by posnet »

RodgerTheGreat wrote: post #47
shitgoose wrote: post #46

Earlier quoted context omitted.

K, not Q? nice! if you don't mind me asking, where? i am curious who is using K these days.

I work for an NYC-based company called 1010data which specializes in business analytics products. Most of our backend infrastructure is written in K3. And if anyone's curious, yes, we're hiring.

If you don't mind me asking, how does someone start with Q/Kdb+?

Can you learn it with just the free version or realistically does it require working with it in a professional setting and learning from others who already use it.

Are there any sources you recommend for a someone just starting out?

Thanks.

Re: 1.1B Taxi Rides on Kdb+/q and 4 Xeon Phi CPUs

#68

Post by qume »

nnx wrote: post #2

I absolutely love this blog series. Can't wait to read what's next :) First time I noticed (mention of) recap at http://tech.marksblogg.com/benchmarks.html

If he made the layout a bit uglier, and made the language more esoteric and generally difficult to understand, this would make a fantastic academic paper.

But seriously, what a wonderful world it would be if all papers were this well written.

Re: 1.1B Taxi Rides on Kdb+/q and 4 Xeon Phi CPUs

#69

Post by jxy »

buckie wrote: post #17

In my experience, kdb+'s k and q (which is broadly speaking a legibility wrapper around k, which again broadly speaking is APL without unicode) are phenomenally fast for dense time series datasets. Though they can struggle (relatively, still pretty fast) with sparse data that's not really what they are built for. They were built for high-performance trading systems, and trading data is dense. If you like writing dens…

   > their main drawback: k/q (like clever regexes) are often write-only code
This depends on the code reader's mentality. One line of k (or q or j or apl) would do what 10 lines of verbose languages do. For verbose languages, your expectation is spending 1 minute for 10 lines of code to fully understand it; but for terse languages, you need to change your expectation to spending 1 minute for only 1 line of code. You are not going to understand anything if you still want to spend 6 seconds per line.

On the other hand, proficiency is important. You read English articles in a slow pace in your first grade; you are not going to be a speed reader without practice, even if English is the only language you speak. No one would expect you to speed read Japanese right after you can compose simple Japanese sentences.

Re: 1.1B Taxi Rides on Kdb+/q and 4 Xeon Phi CPUs

#70

Post by geocar »

valarauca1 wrote: post #54
geocar wrote: post #52

Earlier quoted context omitted.

> There is no reason not to use camel cased variable names and indent functions, There is: it makes the program bigger. Program source code length is significant, and if you have more lines, you have more opportunities for bugs.

Bugs don't hide in variable names or white space. Compiler errors do. But you catch those first run. If tab vs 2 spaces vs 3 spaces can induce a logic error that is a purposely obtuse language.

> Bugs don't hide in variable names or white space.

Bugs do hide in variable names and whitespace.

    thisIsALongVariableName = True
    thisIsaLongVariableName = True
is easy to spot when they're side-by-side, but not so much when they're two pages away from each other. Python's tabs and spaces can confuse the indention in cases so that code that "looks" aligned actually isn't.

If you haven't run into a problem caused by a typo, you haven't been programming long enough.

Post reply on HN