<div class="gmail_quote">On Thu, May 20, 2010 at 2:32 PM, Daniel Pittman <span dir="ltr"><<a href="mailto:daniel@rimspace.net">daniel@rimspace.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
my $x = '.' x 10000; # preallocate<br>
sysread(FH, $x, 5000); # ...and use that storage<br></blockquote><div><br>C-C-C-Combo Breaker.<br><br>As you can see from above, always know what your system is doing. In Abrash's Zen of Code Optimization, he shows that simple C can outperform simple assembly. I hear you say that's impossible because assembly is *closer* to the bare metal than C. In fact it *is* the bare metal! Later in the book, after you realise what the CPU and memory bus is doing, what Daniel said comes closer to the truth: you (almost) can't beat hand-tuned assembly.<br>
<br>But again, it all depends on what you're doing. For equivalent code paths of different languages, if nothing is firing off in the background like GC or you're not thrashing your language's malloc etc then is all O(1), so who cares. Once performance comparisons get to O(1) for different languages, then I would rather optimise my typing and comprehension (i.e. easiest language for the job).<br>
<br>Once again. It all depends on what you're doing. If you run your program on different architectures like an i7, amd64, P4, core2duo, then you'll probably see huge differences on where the performance spectrum languages sit. You'd be surprised what nasties might bite.<br>
<br> >I don't know of any compiled language that performs better than well-written<br>
> C for many cases, because C is close to the metal, and allows the programmer<br>
> to do things their own way.<br><br>And as for that one: FORTRAN.<br><br>Alfie<br></div></div>