Re: KDB+ performance

[Viral Shah]

This is the first time I am hearing about it - but feel free to submit a pull request to add it to the benchmark.

-viral

On Thursday, February 28, 2013 7:39:54 AM UTC+5:30, Fil Mackay wrote:

Has anyone looked into including KDB+/Q in the performance benchmarks? Would be interested to know how that compares with Julia..

[Patrick O'Leary]

For an enlightening experience, see how the modern implementations of the APL languages are written: https://github.com/kevinlawler/kona/blob/master/k.c

[Stefan Karpinski]

I have to object even in principle to including benchmarks for the K language, which is proprietary – so we couldn't run the benchmarks – and which I've never heard of before. We're not in the business of maintaining benchmarks for every programming language that's ever been used for numerical computing. Unless this language is somehow beating the performance of both C and Fortran, it's not really an informative comparison since we're already comparing ourselves to the fastest systems around as a baseline. To answer the original question: I have no idea how we compare to KDB+/Q, but how does KDB+/Q compare to C or Fortran?

[Stefan Karpinski]

Hah. I know Kevin. He used to work at Etsy (and recently made a pretty sweet spreadsheet app for the iPad). We were the two guys there with crazy programming language projects. I remember looking at that very file and being slightly terrified.

I also realize that this may seem to contradict that I'd never heard of the K language before. I hadn't actually realized that what Kevin was working on was an open source version of something called K that was an APL descendant. I just thought he really liked naming files and variables with only one letter.

[Patrick O'Leary]

On Wednesday, February 27, 2013 10:55:36 PM UTC-6, Stefan Karpinski wrote:

Hah. I know Kevin. He used to work at Etsy (and recently made a pretty sweet spreadsheet app for the iPad). We were the two guys there with crazy programming language projects. I remember looking at that very file and being slightly terrified.

Small world!
 

I also realize that this may seem to contradict that I'd never heard of the K language before. I hadn't actually realized that what Kevin was working on was an open source version of something called K that was an APL descendant. I just thought he really liked naming files and variables with only one letter.

AIUI, this is in keeping with tradition. APL programmers wanted their implementations to look as much like APL as possible, even if it was C.

As to your other message, if we were to accept K benchmarks, I think they'd have to be compilable by kona. I agree that it isn't likely to bring anything new to the table. On the other, other hand, I'm morbidly curious to see an implementation of the benchmark suite in a single line of source code.

[Fil Mackay]

On Thursday, February 28, 2013 3:50:44 PM UTC+11, Stefan Karpinski wrote:

I have to object even in principle to including benchmarks for the K language, which is proprietary – so we couldn't run the benchmarks – and which I've never heard of before. We're not in the business of maintaining benchmarks for every programming language that's ever been used for numerical computing. Unless this language is somehow beating the performance of both C and Fortran, it's not really an informative comparison since we're already comparing ourselves to the fastest systems around as a baseline. To answer the original question: I have no idea how we compare to KDB+/Q, but how does KDB+/Q compare to C or Fortran?

Hi Stefan,

KDB+/Q (which implements K) is hardly an unknown. It is #1 in its space (numerical processing in capital markets), the only negatives I have ever heard about are the syntax (compacto-APL) and the price (horrendous - $100K/year+). Despite this the use is massive (it is used everywhere in capital markets) and growing. This is the space I am interested in contributing to Julia.

I don't mention this to add to your burden, as I don't think this is "just another" language (I'd say platform). The fact is that KDB is known for its performance, and I think there is an opportunity for Julia in this space, but speed is the first question that will need to be answered for these users. Plus the fact that Julia's pitch opens with performance as a major plus.

Note that I'm actually not interested in a K benchmark (Kona etc.) but KDB. As I understand it, the mystique surrounding KDB is that it is unique and extremely optimised over a long history (going back to 1993).

Your comment regarding C/Fortran is reasonable, I guess the answer is "it depends on the benchmark". I was hoping to capitalise on the benchmark methodology that had already been developed.

Regards, Fil.

[Stefan Karpinski]

My ignorance of KDB+/Q certainly wasn't meant to imply that it's unknown – but I suspect there are lots of excellent niche languages that I've never heard of and direct comparison to all of them would be nuts, as we all seem to agree. Do you happen to know how KDB+/Q compares to C and Fortran? Are there areas where it significantly beats well-written, optimized C or Fortran code?

[Viral Shah]

This is certainly interesting. I had no idea about the popularity of KDB in capital markets.

The practical issue with the KDB benchmark is that if it is proprietary, we won't be able to run it on julia.mit.edu and include it with all the other benchmarks. Thinking out aloud, would it make sense to have it as a package?

As Stefan suggested, could you also tell us a bit more about its performance compared to C/Fortran, and what language features make it appealing to the capital markets domain?

-viral

[Sean O'Hagan]

hi, just joined today. Very interested in learning about julia. Did anyone ever get benchmarks completed for julia vs q/k?

Thanks,

Sean

[Avik Sengupta]

While this is an old thread, I'm not sure if a K/Q benchmark is all that relevant to Julia.  I've only seen K/Q code written in conjunction with KDB  (which is an in memory columnar database). So its not just benchmarking a language. Also given the specialised nature of KDB, I imagine the answer will very much depend on the workload.

Tangentially, In regard to some of the earlier comments on this thread about this being a properitary solution, there is a free version available for download. However, its license disallows benchmarking. 

Regards
-
Avik

[Fil Mackay]

On Wednesday, May 28, 2014 10:17:20 AM UTC+10, Avik Sengupta wrote:

While this is an old thread, I'm not sure if a K/Q benchmark is all that relevant to Julia.  I've only seen K/Q code written in conjunction with KDB  (which is an in memory columnar database). So its not just benchmarking a language. Also given the specialised nature of KDB, I imagine the answer will very much depend on the workload.

As with any benchmark yes, but you could benchmark the language without any columnar database elements. In fact the latter in kdb not that prescriptive, and you are left to assemble the pieces you really want. It's not like writing a benchmark for an SQL database or anything where you're forced to use a large portion of the infrastructure.

Tangentially, In regard to some of the earlier comments on this thread about this being a properitary solution, there is a free version available for download. However, its license disallows benchmarking.

Yes, that does limit the possibilities.. disappointing license provision :)