Re: PC Motherboard Chipsets and Parts VendorsCarey Carlan wrote:
> Les Cargill <lcargill@cfl.rr . com > wrote in
> news:482f248e$0$3369$4c368faf@roadrunner . com :
>
>>> and programmers have
>>> been running out of CPU since Moore himself was involved.
>> I'm a bit tounge in cheek, but this is like saying an Arctic
>> expedition failed because they ran out of food. That's certainly
>> what happens, but there's more to it than just that.
>
> You are jumping to the conclusion that if a programmer runs out of
> memory he just gives up.
>
No. I am not.
> All the effort devoted in previous generations (and I was in some of
> that) to speed and efficiency were done to make up for the lack of
> cycles and space. When the programmer ran out of CPU or memory, THEN is
> when he started devoting time and effort to making it smaller and
> faster. Everything started with a reasonable efficiency level, but the
> real crunch only came when we ran out of CPU or RAM.
>
I know. That's why you start with ... that and work out from
there. How else are you supposed to identify
requirements that will be sinkholes?
> Modern demands have changed. In the majority of my Windows
> applications, my code is running for maybe 20% of the time. The rest of
> the time Windows is in control. Update the screen? Call Windows. Write
> to disk? Windows won't let me do that directly.
>
When last I checked, Windows is a program. Look, Windows is something
that sells itself as an engineering artifact but it's not. It a
cultural artifact. Ballmer sez "developers, developers, developers" - he
is not talking about engineering. He is talking about culture.
He's right, but that sort of thing never interested me.
> In my office, the efficiency required now is not efficiency of code--
> it's efficiency of delivery. If I don't get task X done by date Y, I
> may not eat on day Z (not quite that severe, but you get the idea).
>
I know. And that's all about people trying to keep the rank
and file in the office from going to sleep. What I have found is that
when you treat software problems as minimal-ization problems,
all the other stuff just goes away. You are done early, it works,
and all the "once more over the top, lads" hoo-ha just bounces
meaninglessly off the walls.
I admit this a strange way to look at the world.
I've been programming professionally for 25 plus years, and I
always call them back. They just don't have problems. I have gotten
one "can you help us" call, and I just asked if the guy had snapshot
the version that worked in the version control system. They said
"yes", and I didn't hear from them again.
> I design my code. I run my code. I get my code operational, THEN can I
> find the bottlenecks and fix them. Sometimes I have to wait for the
> user to get the code to see what parts are used and what parts are
> ignored. It is simply not cost effective to optimize everything all of
> the time. Shaving 20% off code that only runs 10 milliseconds per
> session is futile. OTOH, leaving code unoptimized that runs for seconds
> or minutes can lose a contract or a client.
>
To be fair, my goal with almost everything I have ever built was for
the software I wrote to be almost completely undetectable. I never ran
into a single instance in which I did not identify bottlenecks *first*,
then build around those. I can't say I have ever regretted
those choices. Sure, it looks like I'm messing around, but .... I'm
done early or on time, and it simply *works*. If I'm
late, it's because somebody missed some target upsgtream of me, and
then I throw instrumentation in it that comes very close to proving
the problem.
My main fun has been explaining in appropriate terms why the FPGA
is out of the interface contract or the vendor's booted something.
> As a side note, most of the explosive growth in application size is part
> of two separate evolutions. User interface design is growing
> increasingly complicated as each generation of Windows offers more
> screen widgets.
I usually wait the roughly ten years for those to be packaged in
something like Tcl/Tk before I bother with them. I messed around
with MASM32 for a while; great fun for Letwin style 'Doze stuff, but
that's about it. But 'Doze as a lifestyle choice ( and it is that)
was never an option.
> Applications that use massive processing and memory
> (such as DAWs and video) that were impossible a generation or two ago
> are now growing down into smaller and smaller desktop computers.
About '05, that simply was a solved problem. If a P4 wouldn't do it,
you were doing it wrong.
> Designing code for interface requires a thousand little routines that
> fit into Windows here and there answering event calls and queuing
> messages.
Indeed.
> The math portions of super-streaming jobs like audio and
> video are coded in optimized compilers. Sure, I must design well at the
> component level, but for bits and bytes, the compiler will override me.
>
I just found a defect in a compiler last week. An *old* compiler. Trust
noone.
> In neither of those two worlds, the interface or big math, can I do much
> to optimize my world beyond making simple, straightforward design
> without excess baggage.
>
> Time for me to get off my soapbox.
I have read you for years, and never known any of this about you.
Thanks.
--
Les Cargill