Jeremie Pelletier wrote:
Yigal Chripun wrote:
On 29/09/2009 16:41, Jeremie Pelletier wrote:
What I argued about was your view on today's software being too big and
complex to bother optimize it.
that is not what I said.
I was saying that hand optimized code needs to be kept at minimum and
only for visible bottlenecks, because the risk of introducing
low-level unsafe code is bigger in more complex and bigger software.
What's wrong with taking a risk? If you know what you're doing where is
the risk, and if now how will you learn? If you write your software
correctly, you could add countless assembly optimizations and never
compromise the security of the entire thing, because these optimizations
are isolated, so if it crashes there you have only a narrow area to
debug within.
There are some parts where hand optimizing is almost useless, like
network I/O since latency is already so high having a faster code won't
make a difference.
And sometimes the optimization doesn't even need assembly, it just
requires using a different high level construct or a different
algorithm. The first optimization is to get the most efficient data
structures with the most efficient algorithms for a given task, and THEN
if you can't optimize it more you dig into assembly.
People seem to think assembly is something magical and incredibly hard,
it's not.
Jeremie
Also, if you're using asm on something other than a small, simple loop,
you're probably doing something badly wrong. Therefore, it should always
be localised, and easy to test thoroughly. I don't think local extreme
optimisation is a big risk.
Greater risks come from using more complicated algorithms. Brute-force
algorithms are always the easiest ones to get right <g>.