2 ms·

Take map/reduce for example. Totally do-able as a hardware implementation. Added bonus being that branch prediction would be greatly simplified (from a heuris

Take map/reduce for example. Totally do-able as a hardware implementation. Added bonus being that branch prediction would be greatly simplified (from a heuristic and/or dual-execution scenario down to a simple counter). That we have to do crap like `for(i=0;i<n;i++)` just to iterate an array, or this kind of insanity https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/strncpy-strncpy-l-wcsncpy-wcsncpy-l-mbsncpy-mbsncpy-l?view=msvc-160 https://docs.microsoft.com/en-us/cpp/c-runtime-library/refer... to handle strings is nuts. Having to state your solution in such primitive terms is throwing away information--the kind that an ever-so-slightly-improved compiler could use to great effect.

rbanffy 6y ago
> Take map/reduce for example. Totally do-able as a hardware implementation Not sure I follow. The hardware would have to know a lot about how your arrays are organized and how they'd map (or not) to your SIMD instructions. The compiler, at this level, is generating instructions that are no longer very close to the code you wrote.
- chaganated 6y ago
  For a language with richer semantics (i.e. a string type with built-in operators instead add-on libraries implemented at a lower semantic level), the compiler has a better idea of what we are trying to do. If we only have a minimal RISC instruction set, it can generate a large batch of RISC instructions. If we have a wizard SIMD instruction to speed things up, we have a higher likelihood of being able to put it to use. For languages of a lower semantic level (just a wrapper over loads, stores, and arithmetic), making a compiler that can figure out whether the source is a good candidate for a particular hardware feature can be an intractable problem.