[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
Re: [xml-dev] Speed in Languages and Browser Architectures
- From: Rick Marshall <rjm@zenucom.com>
- To: Peter Hunsberger <peter.hunsberger@gmail.com>
- Date: Tue, 06 Mar 2007 08:29:07 +1100
I used to do tricks like that, but the modern optimisers are so good I
don't even declare C variables as registers any more. In fact it seems
anecdotally at least that most modern optimisers work better if I don't
try to force variables into registers. Old PDP habits die hard....
Peter Hunsberger wrote:
> 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?
>
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]