Comment by snidane | Hacker News Reader

Comment by snidane | Hacker News Reader

I always wondered why people assume that the more high level abstractions or high level programming languages you use the less performance you should expect. C is faster than Java, Java will be faster than Python etc. The 'interpretation overhead' is supposed to kill your performance.

But there is one weird exception. You have the APL family, which are a very high at level of abstraction but perform even faster than C. Especially because od using vectorized processing. When you work on vectors of 1000s items in one instruction, you amortize language interpretation cost away and since working with vectors is actually the only natural way to work with computers you get massive performance from those instructions using vectorized instructions or even running on gpu. (All memory access is naturally linear in computing. Random access memory is an unnatural computing myth which comes at enormous cost and has to be hardware accelerated to be even usable).

Similar can be said about databases and SQL. Especially in OLAP processing, where you can linearize your data tables and columns and vectorize your processing. Because it is near impossible to overcome von Neumann bottleneck in traditional single computer languages like C or Java, any SQL or APL will beat the crap out of them if you span the processing over multiple cores and machines.

Days of single machine processing are over and clusters of computers are the future. AWS (and potentially other clouds) are essentially Operating Systems for sich environent. It'd be nice for open source to catch up though.

APL is limiting itself to numeric arrays. It's no wonder if you only have one datatype that vectorization is easy. As soon as you have a more complicated datastructure like a hashmap or a tree it's almost impossible.

> (All memory access is naturally linear in computing. Random access memory is an unnatural computing myth which comes at enormous cost and has to be hardware accelerated to be even usable).

Are you saying that the order of memory access doesn't matter? Because it's well known in the computer vision / graphics / game industries changing the order of memory access makes a huge difference, especially if you have a cache miss.

This is very obvious if you have a large object that can't fit into L1/L2/L3 cache. In that case, random access causes many cache misses, which destroys performance.

They're saying the opposite, and agreeing with you

>The 'interpretation overhead' is supposed to kill your performance.

Java isn't interpreted

>You have the APL family, which are a very high at level of abstraction but perform even faster than C.

No they don't. You process an array of numbers in contiguous order in C (or anything else compiled with llvm or gcc or similar) it gets vectorized too. APL may encourage the programmer down the right data layout path for vectorization more often though. Which would certainly be a good quality on modern hardware.

I’ve personally experienced naive kdb+/Q (which is interpreted) code that is faster than a somewhat optimized C version.

> Java isn't interpreted

Correct. Not sure why you’re being downvoted.

Java and C# are JIT’d, but only hotspots are aggressively optimized (at least in C#; not sure about Java). So in short runs, prevectorized C code will run faster, but once the optimizer kicks in (with long runs), they’ll be neck and neck.

Side note: C# also supports AOT compilation with optimization. Not sure about Java

C frequently cannot vectorize without explicit hints. This is because with pointer arithmetic, what you're writing to could be within the array you're reading from. So order of operation could matter, and vectorization could break it.

I guess, cause in C#, you can’t have pointers to the middle of an array (when not using `unsafe` code). So I guess one would just check if the arrays’ pointers were equal, and if they aren’t, the arrays don’t overlap.

Side note: C# 8’s ranges and indices return an IEnumerable, so I wonder how those vectorize. Can IEnumerable’s even be vectorized?

The only vectorization I'm aware of in C# is the few classes in System.Numerics that are provided specifically for this optimization. In theory, the C# compiler and/or JIT could automatically issue SIMD ops for some array operations, if it could determine that order of operations doesn't matter (as could just about any other language), but I think as a general rule this is too expensive at compile time or runtime to be worth it, and most languages force you to make it explicit. Except a couple languages like FORTRAN and apparently APL. (Though I'd love to be shown wrong in the C# case).

C has the `restrict` keyword now that allows automatic vectorization without dorking up your code too much.

Reply on news.ycombinator.com