On Monday, 29 September 2014 at 14:25:34 UTC, monarch_dodra wrote:
This just misses the *entire* familly of algorithms that operate on generic types, such as "map". EG: the totality of std.algorithm. Oops.
But if you know the common operations on strings used in many programs, then you want them to perform. So you need a mix of special cased precomputed lookup-tables and/or special cased SIMD instructions that will outperform a generic map() by a significant margin.
I am not arguing against generic apis being desirable, I am questioning of the feasibility of being competitive in the space of utf-8 strings without designing for SIMD.
Obviously, doing bitwise and 0x80808080...80 followed by a simd compare with " " will beat anything scalar based if you want to test for a space in a utf-8 string.
Intel has made a real effort at making UTF-8 SIMD optimizable with the last few generations of instruction sets.
Figuring out how to tap into that potential is a lot more valuable than defining an api a priori. That means writing SIMD code and comparing it to what you have. If SIMD blows what you have out of the water, then it ain't god enough.
If you can define the string APIs to fit what SIMD is good at, then you are onto something that could be really good. D is in a position where you can do that. C++ aint.
