zerozerocool

It wouldn't be a hacker news kdb thread without exaggerated claims about kdb's exaggerated performance.

When you say KDB is "amazingly slow" in real life, you're either talking about your own attempt at KDB, or make-believe KDB.

Expensive, terse, and 'amazingly slow' software would not be exist, let alone be competitive.

To give you an idea, here are some benchmarks comparing Python (with pandas/numpy) vs k (aka q/kdb+).

https://www.linkedin.com/pulse/data-analysis-example-python-...

https://www.linkedin.com/pulse/lists-python-q-side-by-side-f...

I think that software history page is meant to convey general workloads achievable, rather than performance.

-(not the author of the benchmarks nor an employee of shakti FWIW)

Here are some actual benchmarks comparing Python (with pandas/numpy) vs k (aka q/kdb+). It seems k is orders of magnitude more performant - without applying any no brainer optimizations/indexing:

https://www.linkedin.com/pulse/data-analysis-example-python-...

https://www.linkedin.com/pulse/lists-python-q-side-by-side-f...

Last I was told - removing the avx hard requirement is on the roadmap.

This Intel SDE emulator took care of issues I ran into on an older laptop running shakti release circa ~ September:

https://software.intel.com/en-us/articles/intel-software-dev...