4 ms·

I'm guessing kOS will be released at about the same time as the first article about K that actually says how it achieves the performance.

by aasasd 7y ago

tluyben2 7y ago
Besides Whitney being being very good at finding and sidestepping bottlenecks (like writing his own memory management because the OS one is too slow), the entire interpreter, db engine and 3rd party software fits into L1 or at least L2 cache. This is a marketing blurb saying that as well https://kx.com/discover/in-memory-computing/ https://kx.com/discover/in-memory-computing/ . But when you read about and try out Whitney software you will see that terseness in every way does makes things faster.
- aasasd 7y ago
  I've heard about the cache thing, but that doesn't explain much. How is it different from machine code or VMs? Does it remove the need to read program's data? How much time does a non-K program usually spend moving the code from memory? Why wouldn't generations of programmers make the same optimizations―or just copy them from K? Or what are the tradeoffs, considering that K programs are essentially bytecode? Also, there are plenty of memory allocators to choose from, and every runtime that doesn't use the libc has to ship its own (if it does memory management, of course). The OS only gives you big chunks to use as you please, and you can't sidestep the syscall. So that's not a super novel thought.
  - tluyben2 7y ago
    > I've heard about the cache thing It's very optimized for in memory use, so assuming the db is all in working memory and the code operating on the data is in L1/L2, and for the type of data in the column store (Kdb+), you usually pull related chunks into the Lx data cache on which you filter. I would say k is fast for the use case where column memory based storage is a good fit, so relatively small data sets that live in memory and where the operations on the data fit column stores well; I would bet almost all k programmers (including myself) mostly have experience with those datasets or have shoehorned less suitable cases into that case because it did not perform otherwise. There is obviously no magic, besides, for many 'new' programmers and for current standards, the incredibly small binaries for so much functionality. And that helps with always staying in cache vs almost every other software you will use these days where there is continues chunks of instruction data going to and from cache. That's why C (and maybe Rust some time in the future but the binaries were too large when I last checked) is still important if you really want to get to that point. Ofcourse in that 200something kb k/kdb+/q binary there is no room for much optimizing, that is why it absolutely falls down for cases it was not optimized for. And when you use a lot of k you know how (and automatically do) to shoehorn basically anything in those cases. It is not magic by any means, but it comes closer to magic for many as it is alien like assembly compared to JS or C# or something like that I guess. And the speed comes from keeping to your niches. > Also, there are plenty of memory allocators As I understand it, he did it because he did not find the Windows memory allocator efficient enough specifically; not sure why he didn't check for other allocators; I guess because he was optimizing a runtime, he just rolled his own instead.

I'm guessing kOS will be released at about the same time as the first article about K that actually says how it achieves the performance.

by aasasd 7y ago

I'm guessing kOS will be released at about the same time as the first article about K that actually says how it achieves the performance.

tluyben2 7y ago

Besides Whitney being being very good at finding and sidestepping bottlenecks (like writing his own memory management because the OS one is too slow), the entire interpreter, db engine and 3rd party software fits into L1 or at least L2 cache. This is a marketing blurb saying that as well https://kx.com/discover/in-memory-computing/ https://kx.com/discover/in-memory-computing/ . But when you read about and try out Whitney software you will see that terseness in every way does makes things faster.

aasasd 7y ago
I've heard about the cache thing, but that doesn't explain much. How is it different from machine code or VMs? Does it remove the need to read program's data? How much time does a non-K program usually spend moving the code from memory? Why wouldn't generations of programmers make the same optimizations―or just copy them from K? Or what are the tradeoffs, considering that K programs are essentially bytecode? Also, there are plenty of memory allocators to choose from, and every runtime that doesn't use the libc has to ship its own (if it does memory management, of course). The OS only gives you big chunks to use as you please, and you can't sidestep the syscall. So that's not a super novel thought.
- tluyben2 7y ago
  > I've heard about the cache thing It's very optimized for in memory use, so assuming the db is all in working memory and the code operating on the data is in L1/L2, and for the type of data in the column store (Kdb+), you usually pull related chunks into the Lx data cache on which you filter. I would say k is fast for the use case where column memory based storage is a good fit, so relatively small data sets that live in memory and where the operations on the data fit column stores well; I would bet almost all k programmers (including myself) mostly have experience with those datasets or have shoehorned less suitable cases into that case because it did not perform otherwise. There is obviously no magic, besides, for many 'new' programmers and for current standards, the incredibly small binaries for so much functionality. And that helps with always staying in cache vs almost every other software you will use these days where there is continues chunks of instruction data going to and from cache. That's why C (and maybe Rust some time in the future but the binaries were too large when I last checked) is still important if you really want to get to that point. Ofcourse in that 200something kb k/kdb+/q binary there is no room for much optimizing, that is why it absolutely falls down for cases it was not optimized for. And when you use a lot of k you know how (and automatically do) to shoehorn basically anything in those cases. It is not magic by any means, but it comes closer to magic for many as it is alien like assembly compared to JS or C# or something like that I guess. And the speed comes from keeping to your niches. > Also, there are plenty of memory allocators As I understand it, he did it because he did not find the Windows memory allocator efficient enough specifically; not sure why he didn't check for other allocators; I guess because he was optimizing a runtime, he just rolled his own instead.