Application Timing

[Robert Collins]

Many times I see posts in here centered around optimizing and trying to get the best or fastest time for code executions. Unless one is writing a time critical application or something for batch processing for a company I wonder why there is so much emphasis on this matter. As long as the program works what difference does it make for a few less milliseconds of faster processing? 90% of the applications I do are for user interface and users probably wouldn't know if one version is faster than another. About the only application I ever had to build was a mass data sorting program that was run in the batch state and here timing was very important but other than that I have yet to see any program where faster processing was paramount. Anyway, just curious.   

[Brett Kuntz]

It's a fun challenge?

[liquidsilver]

It's most likely because eventually you will want your program to do more and that will make it lag. For example in a game, a complicated maths orientated program or a word processor that checks spelling as you type. if you think about it, that's why most people program in assembly in the first place - it's just SO much faster. If you don't care about speed, then maybe another language might be better?

Let's take a simple text processor, in version 1, it's almost just like notepad, but then in version 2, it's more like wordpad, and eventually it's like word. If you started with bad, unoptimized programming, then you would have to almost start from scratch! See my point?

[pbrennick]

Hi Robert,
I have always believed that what you say is true.  What difference does it make whether you get the answer in picoseconds or nanoseconds, as long as it is correct is the line I have always used.  I also feel that struggling to save a few bytes here and there is also wasted effort, especially when the storage mediums we must use today control the minimum storage size we are allowed (not the actual program size).  The few times I have bothered to mention these facts were not well received, however, and the responses I got were very close to being flames.  As a result, I usually keep my own counsel on these matters now-a-days.  I just thought I would mention that I totally agree with you.

Paul

[dsouza123]

Both points can be true.

For example Prime95.exe,  http://mersenne.org/primenet/
a distributed computing program trying to find very large Mersenne prime numbers,
(currently has found the largest know prime number)
it's user inteface, file access, networking parts are in C
and the calculation routines are in optimized 32 bit (now also 64 bit) MASM.

[Mark_Larson]

  Robert,

  Knowing when to optimize is just as important as knowing how.  The programs you are writing don't need to be optimized.  However I have come across quite a few time sensitve programs.  Programs that runs for hours or days, and so tweaking them to be faster is very important.  Let me give my philosophy on the whole thing.  Optimization in general is very tough.  To excel at it, you have to be intimately familiar with how the hardware works.  Most code optimizations I have seen in assembly language aren't very good ( I am not talking about this board, but in general).  So to me that means most assembler programmers aren't good optimizers.  So how does one sharpen ones ability to optimize?  Optimize everything.  What?  Yep.  If you pick short easy to understand algorithms that people post on here, or procedures of your own, you will make your optimization skills better for when you really need to make code fly.  That was how I got my optimization finely honed.  I spent time optimizing code on an everyday basis to sharply hone my skills.  Now when I need to make code fly for a program, I can do it very well.  So when you see me optimizing a procedure to calculate the length of a string ( probably not something that really needs to be optimized), it's because I am further honing my optimization skills.  So don't assume that, because I optimize a procedure on this board, that that is a good procedure to optimize.  I am probably just doing it to make my skills sharper.  I hope that clarifies a lot of the optimization that goes on on the boards.

  And also knowing when to optimize is very important.  I have seen people trying to optimize Windows message loops.  That's silly.  If your code runs for an extended period of time, and you want to optimize it, you need to profile it.  For good program optimization you have to profile.  It's a very important step.  Generally code optimization follows the 80/20 rule ( or the 90/10 rule, depending on who you talk to).  80% of the time is spent in 20% of the code.  So learning what parts of your code eat up most of the time, let's you only optimize the parts of the code that need optimizing.  Generally I write my program in C.  If I need to optimize, I then run a profiler on it to find the slow parts.  I then try new algorithms.  Algorithmic changes usually give you the biggest speed up, unless you are just an insane assembler optimizer.  If it is still slow I try different tricks in C to speed it up ( loop unrolling, aligning data, etc).  If it is still too slow then I re-write the slow parts in assembler. 

  So what do I run across at work that needs to be faster?  Lots of things.  We run Perl scripts every night to run automated testing on different processors.  The perl scripts used to run in three hours.  And someone has to be around when they finish to make sure they finish properly.  We launch the scripts at 5pm after everyone has had a chance to make changes to the processors.  The perl scripts are currently taking until 1:30 am to run.  That's 8 and a half hours.  Do you want to be up at 1:30 am every night to make sure the script completes?  not me.  So that's one of things I am optimizing.  I am trying to get the runtime of the scripts down below 3 hours ( faster than it was before).  I found a perl profiler( cool, huh?), and I am profiling all the scripts to see which ones take the most time, to concentrate on them first for optimization.  Optiimization doesn't just apply to assembly language.  There are lots of tricks I can do in Perl to make them run faster.  And if that still isn't fast enough I will convert the code to assembly language, to get the utmost speed.

  So what else?  Well we run MySQL ( the scripts call our database), and it also takes up a good portion of our perl script time.  So I am optimizing MySQL.  So what does that entail?  Lots of things.  I am making sure we have the right hardware, I am trying different environment settings, I am trying different compilation settings.  I am also looking at the source code.  MySQL has some batch files you can use to make a MySQL program that is set up with profiling information.  So I can run it and see where the slow parts are, and then optimize them in the code.  And if that still isn't fast enough I will convert it to assembler to make it as fast as possible.

  So what else runs slow?  Well we don't have real processors for the testing.  We simulate it via software, which runs a LOT slower, however it let's us do some things that having hardware couldn't.  Intel does the same thing.  The perl scripts run every test from a database of tests ( over 1 million different tests) on the emulator.  That means the emulator gets run over 1 million times per processor.  We have about 8 or 9 processors we emulate.  So thats over 9 million tests.  So emulating the hardware faster would give us a big speed up.  I have the source code to the emulator, and I have tried various things to make it run faster.  I also have run a profiler on it, so I know what parts are slow.  The first step is to try C ways of making it faster.  And if it still is not fast enough to convert it to assembler.

  I hope these things may have given you some ideas of where optimization is needed.  As well as address why people are optimizing on this board.  And secondly why optimizing in assembler shouldn't be your first optimization step.  Try algorithmic changes first, then tricks in your high level language, and then last break out the assembler if it still isn't fast enough.