describes a number of benchmarks for an interesting data problem. kdb+ is the
third fastest performer and the fastest CPU performer. kdb+ is 1000x faster than another database written in C (kdb+ is written in k); but only about 100x faster than other C-based databases. The next closest looks like Yandex Clickhouse which is written in C++ and still less than half the speed of kdb+.
How much work is spent getting C++ to approach half the speed of an interpreted language?
> How can you be "a lot faster" than Julia?
That is an incredibly loaded question, but a big part of "how" is because of the notation: Because it's written in a language that is very dense, and puts parts of the solution near eachother, it is very easy to be correct, and to find repetitive parts of the program that can be coalesced and merged.
> Im sorry, but when i see apl, I just see a lot of symbols I can't bother to look up to understand.
It never ceases to amaze me when a programmer thinks that just because they can't do something, that somehow that follows that nobody else should either.
I mean, seriously!
> Code reviews would be a nightmare.
Why would you do code reviews in a language you don't understand?
The dense and carefully chosen symbols and meanings in an APLish language is its value. Not that it's fast (although it is), but specifically that it's easy to understand. Heck, the article we're commenting about mentions several algorithms that are so much easier to understand in an array language than anything else.
> Why isn't [matrix multiply] * [instead of something else]
I think you added this question after I responded, or maybe I missed it. It's a good question.
Because inner product (apl: +.×) is row-wise multiplication then column-wise summation. You can do a row-wise = then a column-wise > to see if the bottoms of a column end in a value (2>.=M).
There's also an outer-product (apl: ∘.×) which is the left-argument currying times the right row-wise.
* usually means power in APL. Not multiply. APL uses the standard × character for multiplication.
APL is designed to be read, but it's still describing numerical methods and operations as opposed to a mathematical notation which frequently hides complexity.
> in Julia, if I were to write a numerical type for galois fields (and I have), I could write compile-time optimized code for performing reed-solomon erasure coding using the builtin matrix operators - the code would be exactly the notation you see in the papers describing erasure coding.
That sounds great, but I don't understand any of that or why it's valuable.
Maybe that's because I don't typically read mathematical journals and type in the algorithm presented.
However you gave me an idea. Take a trie as a simple data structure with a great deal of literature about it. Some googling leads me here:
Now I can write "find" in k/q as @/ if I implement a 256-trie. Maybe the author doesn't know APLish languages and that's why they chose a poor notation. Maybe not.
But having to decode some paper like this occurs much more frequently than even wanting to implement a bunch of type code that the compiler can optimise so I can copy and paste mathematical notation.
It is very difficult to say a language is faster than another, and only slightly easier to say an implementation is faster.
http://tech.marksblogg.com/benchmarks.html
describes a number of benchmarks for an interesting data problem. kdb+ is the third fastest performer and the fastest CPU performer. kdb+ is 1000x faster than another database written in C (kdb+ is written in k); but only about 100x faster than other C-based databases. The next closest looks like Yandex Clickhouse which is written in C++ and still less than half the speed of kdb+.
How much work is spent getting C++ to approach half the speed of an interpreted language?
> How can you be "a lot faster" than Julia?
That is an incredibly loaded question, but a big part of "how" is because of the notation: Because it's written in a language that is very dense, and puts parts of the solution near eachother, it is very easy to be correct, and to find repetitive parts of the program that can be coalesced and merged.
> What's mmu?
http://code.kx.com/q/ref/matrixes/#mmu
> Im sorry, but when i see apl, I just see a lot of symbols I can't bother to look up to understand.
It never ceases to amaze me when a programmer thinks that just because they can't do something, that somehow that follows that nobody else should either.
I mean, seriously!
> Code reviews would be a nightmare.
Why would you do code reviews in a language you don't understand?
The dense and carefully chosen symbols and meanings in an APLish language is its value. Not that it's fast (although it is), but specifically that it's easy to understand. Heck, the article we're commenting about mentions several algorithms that are so much easier to understand in an array language than anything else.