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

Impending kOS

archive.vector.org.uk

Post reply on HN
Print view View original

191–200 of 242 posts

Re: Impending kOS

#191

Post by geocar »

Dylan16807 wrote: post #129
geocar wrote: post #37

Earlier quoted context omitted.

If someone produces smaller and faster code than me, then I should want to learn from it. I wonder why other people have the exact opposite reaction. Why do you think that is?

It all depends on how you define "small and fast". Comments obviously are not code, so it's reasonable to complain about lack of comments. You suggested wordcount, I think wordcount is good, so it's reasonable to complain about single letter words rather than descriptive words. uberalex's suggestion for reformatting wouldn't change the algorithm or speed. It would simply spread operations across more lines. That also…

>I mean, I'm sure fitting more on the screen is valuable, but people already know how to fit many times as much code onto a screen. They avoid it on purpose for whatever reason.

I think this reason (whatever it happens to be) is probably wrong.

Re: Impending kOS

#192

Post by geocar »

xorcist wrote: post #182
geocar wrote: post #179

Earlier quoted context omitted.

You don't seem to be aware that Arthur did exactly that: http://code.kx.com/wiki/Startingkdbplus/qlanguage http://www.kx.com/q/d/kdb+.htm http://www.kx.com/q/d/kdb+1.htm It's a commercial product and I understand kx does pretty well.

I was not. Thank you. What is the source of the performance figures?

http://www.listbox.com/member/archive/107499/2014/05/sort/ti...

The list is subscriber-only, and I apologise that the information isn't very easy to get at.

Re: Impending kOS

#193

Post by svan99 »

I love K/Q and is using it in my startup. Thanks a lot for Kx's recent freeing up the 32bit version. To use APL-like languages I have to really shift the way of designing/modeling things. Most importantly K may not be best for lots of developers working on the same thing. Object oriented languages will fit better in that case. K projects often only involve one or two developers who model things in vector thinking (column based thinking in data domain), know exactly what to do and how to do it. Vector thinking is not suitable for all problems, but works really well if it does. Btw, new 3.2 version of kdb appears to be even faster than before. It also improves websocket integration and JSON data conversion. Very nice to integrate with nodejs/Qt.

We also use Forth which I think is a really another way of shifting mind.

Re: Impending kOS

#195

Post by [deleted] »

geocar wrote: post #34
jeffreyrogers wrote: post #12

> kOS is coming. Nothing will be the same afterwards. There seems to be this strange idea going around that if we just get the right tool, everything else is going to change forever. I see this a lot with people trying to create IDEs that let non-programmers create programs without really knowing how to code. But the thing is, most people just don't have anything worth coding. The problem isn't that the tools don't e…

If I am from another planet, and say I don't know why programs are so big and slow and buggy, and the most complicated program you see I've produced is a glorified calculator, it's too easy to be patronising and say well, that's because you haven't done anything complicated . However if I then show you a programming language, a database engine (similar in capability to SQL but around 1000x faster), a graphical deskto…

[deleted]

Re: Impending kOS

#196

Post by bhuztez »

wyc wrote: post #10
TheOsiris wrote: post #9

> “It is a lot easier to find your errors in four lines of code than in four hundred.” Looking at his code on http://www.kparc.com/edit.k I'd like to disagree with that statement

If I posted four lines of Chinese or Sanskrit, it's likely that native English speakers would disagree that they had much meaning either. However, this doesn't mean that those lines are inherently devoid of meaning or difficult to parse.

It is a pity that they don't use Chinese symbols but invented their own. I really hope one day I can write programs in Chinese, i.e., programs are also valid Chinese, and have the same meaning.

Re: Impending kOS

#197

Post by 616c »

ggreer wrote: post #48
616c wrote: post #17

Earlier quoted context omitted.

That is a fun experiment. I studied linguistics in college, and I do not think anyone ever discussed textual density of different languages with the "same" content (the latter part would be its own terrifying chestnut; if you have not studied machine translation and semantic eval and good luck ever confirming such a statement). I studied Arabic a lot, and Chinese about a year. I cannot speak to Chinese with only one…

It's important to separate spoken information density from written information density. Some languages win at one while losing at the other. Your arabic example was shorter than the equivalent english on paper, but longer when spoken (4 syllables vs 3). In terms of information density per syllable, mandarin wins, with english coming in a close second. When speaking, english usually has more syllables per unit time th…

This is very cool, man. Thanks for the link. It is so much fun when on HN and someone brings up a topic and someone throws out established research for said topic without much delay, no matter how big or small.

Like Apple fanbois have "there's an app for that", I love HN moments "Oh I got a citation for that" and for topics I would find very difficult to research at a cursory glance!

Re: Impending kOS

#198

Post by beagle3 »

mwcampbell wrote: post #76
geocar wrote: post #51

Earlier quoted context omitted.

What you're actually seeing is testimony: people saying they are seeing something amazing, and they aren't very good at explaining what they saw. Btw: k doesn't translate to C. It's actually a quite simple interpreter. The fact that it outperforms other languages so easily should be saying more about those languages than it should be saying anything about k.

So would k be even faster if it were compiled to machine code rather than being interpreted? Would that involve an unacceptable speed versus space trade-off? Or am I missing some crucial reason why k code has to be interpreted?

It would be even faster, with a sufficiently smart compiler (a feasible one, not they mythical beast[0]). E.g., the function

    sumsquares:{+/a*a*a*a:1+!x}
which sums pow(a,4) for a from 1 to x (its argument), when interpreted, allocates a vector of length x, initializes it to the numbers 0..(x-1), then allocates another vector of length(x), to which it copies the first vector while adding 1 to each element, and calls it a. Then makes another vector of length(x), puts a * a in respective elements, etc. - and finally, sums the elements of the remaining vector.

If we can learn from numpy (K equiv) -> numexpr (same work, smarter about allocations) -> numba (jit compiler, avoids allocations), we can expect x2 faster speed in both "upgrades" - about x4 overall.

If that sounds too little speedup for so much effort, you are not giving modern caches enough credit. Almost every single memory access here is in L1, as they are all sequential and perfectly predictable. So it's just 2-5 slower than doing the perfect register allocation with no memory access - but with the cost of ballooning code size (going out of L1 itself ...). Also, interpretation overhead is nearly nonexistent because operation on vectors are coded in tight cache aware C loops.

Overall in the interpreter/compiler tradeoff, K comes out far enough ahead of everything else that it did not make sense for them to invest in a sufficiently smart compiler. In fact, it is only a few months ago that they bothered using SSE/AVX vector instructions for significant speedup. It is so far ahead of the curve (for its use cases) that doing that didn't really give any marketing advantage until recently (and I'm not sure it does now).

[0] http://c2.com/cgi/wiki?SufficientlySmartCompiler

Re: Impending kOS

#199

Post by nemo1618 »

epsylon wrote: post #178
nemo1618 wrote: post #115

Earlier quoted context omitted.

I tried cleaning it up a bit: https://gist.github.com/lukechampine/f54fce8fd756254cefb2 But the actual meaning of the program is still lost on me. I can only guess it has something to do with parsing files (note the checks for curly braces). Feeding it its own source code produces some output, but I have no idea what it actually modified.

It's a solution to CS107 assignment 1 : http://web.stanford.edu/class/cs107/assign1.html

Guess I could have just looked at the URL, huh. Well, it was fun trying to reverse Whitney's code anyhow.

Humorously, it looks like this code would have received a poor grade. It meets just about every standard for low quality outlined here: http://web.stanford.edu/class/cs107/landmarks.html, particularly "Fast code which doesn't work quite right." (Due to an off-by-one error, this code fails to properly reconstruct the example text.)

Post reply on HN