wmemchar for unix

[H. S. Teoh]

On Tue, Aug 27, 2013 at 11:18:50PM +0400, Dmitry Olshansky wrote:
> 27-Aug-2013 18:41, H. S. Teoh пишет:
> >On Tue, Aug 27, 2013 at 07:37:02AM -0700, Sean Kelly wrote:
> >>On Aug 26, 2013, at 11:57 PM, monarch_dodra <monarchdodra at gmail.com> wrote:
> >>
> >>>For performance reasons, I need a "w" version of memchr.
> >>>
> >>>C defines wmemchr as:
> >>>wchar_t * wmemchr ( const wchar_t *, wchar_t, size_t );
> >>>
> >>>Unfortunatly, on unix, "wchar_t" is defined a *4* bytes long,
> >>>making wmemchr, effectivelly, "dmemchr".
> >>>
> >>>Are there any "2 byte" alternatives for wmemchr on unix?
> >>
> >>Why not cast the array to ushort[] and do a find()?  Or is that too
> >>slow as well?
> >
> >Optimized searches of this kind ideally translate to the various rep*
> >instructions on x86.
> 
> Rather a loop with XMM moves. What's best though is always a moving
> target.
> 
> >I'm not sure if dmd does that optimization. If you really feel
> >inclined, you could do static if (X86) and throw in an asm block (but
> >that would break purity, @safety, etc., so probably not a good idea).
> >
> 
> It would be awesome to have pure D analogs for memchr, memcpy and its
> ilk that won't be so limiting (as in types used) but would guarantee
> top performance.
[...]

Those would have to be compiler intrinsics, since they are CPU-dependent
optimizations. Plus they could improve dmd code generation. :)


T

-- 
The only difference between male factor and malefactor is just a little emptiness inside.