Re: Re: On Golf

> Less symbols means less code, so it's optimization

Can't good optimization sometimes increase the number of symbols in your code (assuming you're not working in assembler)?

You can have verbose code that is highly optimized in that it avoids any expensive processes, and you can have short, compact code that actually translates to expensive machine code.

On any high level language like Perl, the code is never going to map directly to the same quantity of machine instructions.

All I'm saying is that anything done in the name of optimization has to be considered from the machines point of view.

willdooUK
--------------

Comment on Re: Re: On Golf

Replies are listed 'Best First'.
Re: Re: Re: On Golf by rchiav (Deacon) on May 21, 2001 at 18:51 UTC
Just to add to this, in C, a for-loop is smaller but less optimized than writing out each statement seperately. And using cos() or other trig functions might be smaller but a lookup table is much faster. When you're not specifically dealing with instructions, code size doesn't really have any correlation to speed. Rich	[reply]
Re^4: On Golf by FoxtrotUniform (Prior) on Jul 14, 2004 at 21:01 UTC
Just to beat a dead horse: in C, a for-loop is smaller but less optimized than writing out each statement seperately. ...unless the unrolled loop's extra code size causes a cache miss across a slow bus, in which case the for-loop is more optimized (assuming, of course, that the loop fits in a cache line). `-- F o x t r o t U n i f o r m Found a typo in this node? /msg me % man 3 strfry`	[reply]
Re: Re: Re: On Golf by Cybercosis (Monk) on May 22, 2001 at 10:24 UTC
I agree completely. However, optimization can mean any of several different things; you can optimize for speed, readability, size, footprint, or whatever. What is more important than the actual direction of optimization is mastering the process of thought involved in optimization. ~Cybercosis nemo accipere quod non merere	[reply]


XP is just a number
	PerlMonks