Re: Re: Flat Short of MEMORY_BLOCK

Berend de Boer:

> I assume if SmartEiffel assumed that gcc was the backend and therefore
> left some optimizations to the C compiler, it would be far less
> optimal compiler.

Maybe, maybe not. If it does some optimisations less well 
than gcc, it will be the other way. It could happen 
in general (optimisations that gcc always does better) or 
due to being too high level (optimisations that take 
architecture/processor parameters, which are available 
to gcc but not SE).

> Just assuming the C compiler will take care of an issue, 
> isn't a safe bet.

Assuming that memcpy is slower than the array notation 
seems to me a similarly unsafe bet: maybe some 
C compilers implement memcpy faster, e.g. if they do 
a bounds check for arrays they don't do for memcpy.
C does not require bounds checks, but a C compiler 
could still do them and display warnings or the like,
maybe even in optimised mode if it's particularly 
safety minded.

Premature optimisation has costs (more complexity, 
bugs, maintenance) so this should be balanced against 
the benefits, and the benefits are fairly limited 
when the optimisation technique is only a guess that 
may turn out not to apply in reality. If this 
optimisation was proven to often increase performance 
by 2%, I would also think it's not worth doing.



------------------------ Yahoo! Groups Sponsor ---------------------~-->
Upgrade to 128-bit SSL Security!
http://us.click.yahoo.com/VV_nUB/yjVHAA/TtwFAA/saFolB/TM
---------------------------------------------------------------------~->

To Post a message, send it to:   [email protected]
To Unsubscribe, send a blank message to: [email protected] 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
     http://groups.yahoo.com/group/gobo-eiffel/

<*> To unsubscribe from this group, send an email to:
     [email protected]

<*> Your use of Yahoo! Groups is subject to:
     http://docs.yahoo.com/info/terms/