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 <monarchdo...@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.