Re: [xml-dev] Speed in Languages and Browser Architectures

["Peter Hunsberger" <peter.hunsberger@gmail.com>]

On 3/2/07, Rick Marshall <rjm@zenucom.com> wrote:
> String processing in C is tricky at best. Why? well there's no such
> thing as a string in C...
>
> So Dennis decided a string was an ascii sequence of bytes terminated by
> a 'NUL' (and not containing a NUL). This has lots of limitations and
> over the years the definition and libraries have changed - but string is
> a library, not a language concept.
>
> Then to confound the issue most modern C compilers take advantage of
> native string processing instructions in modern CPUs so many elements of
> the standard C string library are actually compiled into single CPU
> instructions (yeah I know the microcode does lots of instructions).

But of course you're not really done optimizing until the code is
conditionally compiled to exploit the differences in the performance
of various CPU implementations at the microcode level....

I've actually been involved in writing core OS memory and cache
management routines where we played such games; certain CPUs can be
slower on certain instructions so that using multiple instruction
equivalents can perform better.  We also played games like manually
pipelining the instruction set to eliminate consecutive register
access, etc. on some CPUs.  Can't imagine anyone really engaging in
such practices any more?

-- 
Peter Hunsberger