[gameprogrammer] Re: Blue Collar Coding
- From: Bob Pendleton <bob@xxxxxxxxxxxxx>
- To: Gameprogrammer Mailing List <gameprogrammer@xxxxxxxxxxxxx>
- Date: Tue, 11 May 2004 10:09:23 -0500
On Tue, 2004-05-11 at 08:06, latimerius wrote:
> On Thu, May 06, 2004 at 08:32:24AM -0500, Bob Pendleton wrote:
>
> > Here is a great essay. It should make a lot of people rethink what they
> > know about programming:
> >
> > Programming as if Performance Mattered
> > http://www.dadgum.com/james/performance.html
>
> Hmmm ... it seems to be based on the old claim that the hardware is
> "fast enough". I don't believe this is the case, or that it will ever
> be the case. Demonstrating that 1985's problems are solvable in no time
> today is only half the truth, IMHO. There are new problems today,
> undreamt of in 1985, that still require full processing power available.
>
> E.g. it's nice to be able to decode one TGA file in 15 ms - but what if
> you need to decode 10's or 100's of them while the user is waiting (like
> in gqview or similar apps)?
>
> I also wonder what his claim that even games don't need more power is
> based on. Sure, with all those new GPU's and some competence in driving
> them we can say that the graphics is no longer the problem it used to
> be. But how about AI? We all know that even half-decent AI can eat
> significant amount of processing power. Pathfinder alone can break your
> neck performance-wise in some kinds of games.
>
> I'm no optimization freak, I'm afraid I can't optimize all that well for
> that matter since I haven't done any appreciable optimizing work in last
> couple of years. But I can see that different apps have different
> demands on speed of execution, safety (whatever that means) etc. So
> sweeping claims like "everybody should focus on safety now since
> everything's fast enough" are quite far from truth IMHO.
>
> Or am I missing something?
>
> latimerius
>
I didn't get the same things out of it that you did. I thought he was
making a couple of different points. The first being that algorithmic
optimization works better than low level optimization. This is something
that has been shown to be true many times. The counter argument, and all
the counter examples show that while algorithmic optimization works best
it is hard to do in low level languages like C. And that the performance
of high level languages (in this case erlang) is so poor that even with
algorithmic optimization the code is still slower than poorly written C
code.
The second point was that computers are now fast enough to allow the use
of high level languages for problems that they were never considered for
in the past because of performance concerns. Which makes algorithmic
optimization easier to do.
My own example of this goes back to when I used to write a lot of
assembly languages code. I did that for many years working for several
companies and under a number of bosses. I drove all my bosses crazy by
insisting that I be allowed to write all my code and debug it in a high
level language, usually Pascal in those days, and then translate it by
hand into assembly language. The bosses always hated that I was
"wasting" time coding in Pascal. But, then after a few months or even a
year of seeing that I was generating 2 or 3 or 10 times as much code as
everyone else and that my code had 1/10 the number of bugs and that the
time needed to fix my bugs was 1/10 of what it took everyone else...
They stopped objecting to what I was doing.
The thing is, it is a lot easier to do algorithmic optimization in a
high level language. It is also a lot easier to design, code, and debug
in a high level language. The higher the level of the language, the
easier it is. OTOH, coding in assembler requires a lot of concentration
just to get the details of the code right. If your mind is occupied with
the details of which register to use, you aren't thinking about the high
level algorithm that you are implementing. So, assembly coding is best
done as a separate task from design and debug.
At the time I could consistently hand translate code better than the
available compilers could. And, on a lot of those projects the
processors were so new there were no compilers for them. So, it made
sense to code the projects in assembler.
Anyway, that is what I thought he was saying.
Bob Pendleton
>
>
> ---------------------
> To unsubscribe go to http://gameprogrammer.com/mailinglist.html
>
--
+--------------------------------------+
+ Bob Pendleton: writer and programmer +
+ email: Bob@xxxxxxxxxxxxx +
+ blog: www.Stonewolf.net +
+ web: www.GameProgrammer.com +
+--------------------------------------+
---------------------
To unsubscribe go to http://gameprogrammer.com/mailinglist.html
- Follow-Ups:
- [gameprogrammer] Re: Blue Collar Coding
- From: Latimerius
- References:
- [gameprogrammer] Blue Collar Coding
- From: Bob Pendleton
- [gameprogrammer] Re: Blue Collar Coding
- From: latimerius
Other related posts:
- » [gameprogrammer] Blue Collar Coding
- » [gameprogrammer] Re: Blue Collar Coding
- » [gameprogrammer] Re: Blue Collar Coding
- » [gameprogrammer] Re: Blue Collar Coding
- » [gameprogrammer] Re: Blue Collar Coding
- » [gameprogrammer] Re: Blue Collar Coding
- [gameprogrammer] Re: Blue Collar Coding
- From: Latimerius
- [gameprogrammer] Blue Collar Coding
- From: Bob Pendleton
- [gameprogrammer] Re: Blue Collar Coding
- From: latimerius