5 ms·

A good example of how bad it has become is that modern processors have a rather good understanding of the 'string' concept, and offer instructions to process th

by personZ 12y ago

A good example of how bad it has become is that modern processors have a rather good understanding of the 'string' concept, and offer instructions to process them. C offers a char. The x86 string functionality that I'm aware of was directly derived from C string functionality, and any decent library of course uses them. You don't directly map to those underlying opcodes because that would be silly, and would completely undermine any platform independence you might have. The same for vectorization. You don't explicitly express vectorization in your code, but of course all decent C compilers can easily and robustly generate such code. C isn't close to the hardware (beyond very high level notions like "contiguous memory"). But it's a simple enough language that it's very heavily optimizable.

ramchip 12y ago
> all decent C compilers can easily and robustly generate such code From what I've seen auto-vectorization is anything but robust, often you need non-portable annotations to get anything decent. See e.g.: http://locklessinc.com/articles/vectorize/ http://locklessinc.com/articles/vectorize/ where there's an interesting case where using "if" instead of a ternary operator is enough to prevent optimization.
plorkyeran 12y ago
I have never encountered a C compiler which can reliably vectorize code not specifically written for its "auto"vectorizer, and it's sometimes easier to just write some asm than to persuade the compiler to vectorize a loop.
ori_b 12y ago
> The x86 string functionality that I'm aware of was directly derived from C string functionality, and any decent library of course uses them. The string instructions tend to be slower than using generic instructions, especially in the presence of SSE.
- deleted 12y ago
  [deleted]
zanny 12y ago
> But it's a simple enough language that it's very heavily optimizable. The simplicity of C means you can't make many assumptions of how it is handled. Same problem in C++. You can make a lot of optimizations to assembler if you can guarantee a value won't change, or if the relative location in memory needs to remain static because anything can rip the address and do awful pointer arithmetic with it. I like to compare to asm.js - it is a reduced language in that it restricts the environment from doing things it can't easily optimize away, except in that case its to assembler. Reduced set versions of C exist to do the same already, but it would be nicer if you just had a fast language default with straightforward rules with ways to just declare wonderland functionality that can mess things up that means the compiler needs to preserve the machine assumptions rather than the language structures.
pixelglow 12y ago
The problem with vectorization is that it cannot be applied to arbitrary code. You have to consciously design your algorithms, data and libraries to be SIMD-friendly. I once wrote a SIMD C++ template library based on valarray: http://www.pixelglow.com/macstl http://www.pixelglow.com/macstl. Sadly it has languished over the years but I would love to work on it again. It had novel (at the time?) vectorized trigonometric functions, for example.

by personZ 12y ago

ramchip 12y ago

> all decent C compilers can easily and robustly generate such code From what I've seen auto-vectorization is anything but robust, often you need non-portable annotations to get anything decent. See e.g.: http://locklessinc.com/articles/vectorize/ http://locklessinc.com/articles/vectorize/ where there's an interesting case where using "if" instead of a ternary operator is enough to prevent optimization.

plorkyeran 12y ago

I have never encountered a C compiler which can reliably vectorize code not specifically written for its "auto"vectorizer, and it's sometimes easier to just write some asm than to persuade the compiler to vectorize a loop.

ori_b 12y ago

> The x86 string functionality that I'm aware of was directly derived from C string functionality, and any decent library of course uses them. The string instructions tend to be slower than using generic instructions, especially in the presence of SSE.

deleted 12y ago
[deleted]

zanny 12y ago

> But it's a simple enough language that it's very heavily optimizable. The simplicity of C means you can't make many assumptions of how it is handled. Same problem in C++. You can make a lot of optimizations to assembler if you can guarantee a value won't change, or if the relative location in memory needs to remain static because anything can rip the address and do awful pointer arithmetic with it. I like to compare to asm.js - it is a reduced language in that it restricts the environment from doing things it can't easily optimize away, except in that case its to assembler. Reduced set versions of C exist to do the same already, but it would be nicer if you just had a fast language default with straightforward rules with ways to just declare wonderland functionality that can mess things up that means the compiler needs to preserve the machine assumptions rather than the language structures.

pixelglow 12y ago

The problem with vectorization is that it cannot be applied to arbitrary code. You have to consciously design your algorithms, data and libraries to be SIMD-friendly. I once wrote a SIMD C++ template library based on valarray: http://www.pixelglow.com/macstl http://www.pixelglow.com/macstl. Sadly it has languished over the years but I would love to work on it again. It had novel (at the time?) vectorized trigonometric functions, for example.