On Thursday, 22 August 2013 at 19:28:42 UTC, Nick Sabalausky
wrote:
On Wed, 21 Aug 2013 18:50:35 +0200
"Ramon" <s...@thanks.no> wrote:
I am *not* against keeping an eye on performance, by no means.
Looking at Moore's law, however, and at the kind of computing
power available nowadays even in smartphones, not to talk
about 8 and 12 core PCs, I feel that the importance of
performance is way overestimated (possibly following a
formertimes justified tradition).
Even if we assume Moore's law is as alive and well as ever, a
related
note is that software tends to expand to fill the available
computational power. When I can get slowdown in a text-entry
box on a
64-bit multi-core, I know that hardware and Moore's law,
practically
speaking, have very little effect on real performance. At this
point,
it's code that affects performance far more than anything else.
When we
hail the great performance of modern web-as-a-platform by the
fact that
it allows an i7 or some such to run Quake as well as a Pentium
1 or 2
did, then we know Moore's law effectively counts for squat -
performance is no longer about hardware, it's about not writing
inefficient software.
Now I'm certainly not saying that we should try to wring every
last
drop of performance out of every place where it doesn't even
matter
(like C++ tends to do). But software developers' belief in
Moore's law
has caused many of them to inadvertently cancel out, or even
reverse,
the hardware speedups with code inefficiencies (which are
*easily*
compoundable, and can and *do* exceed the 3x slowdown you
claimed in
another post was unrealistic) - and, as JS-heavy web apps
prove, they
haven't even gotten considerably more reliable as a result (Not
that JS
is a good example of a reliability-oriented language - but a
lot of
people certainly seem to think it is).
I agree. However I feel we should differentiate:
On one hand we have "Do not waste 3 bytes or 2 cycles!". I don't
think that this a the, or at least not an adequate answer to
doubts of Moore's laws eternal validity.
On the other hand we have what is commonly referred to as "code
bloat". *That's" the point where a diet seems promising and
reasonable. And btw., there we are talking megabytes instead of 2
or 5 bytes.
Now, while many look in the hobby-programmers corner for the
culprits, I'm convinced the real culprits are graphics/gui and
the merciless diktat of marketing.
The latter because they *want* feature hungry customers and they
don't give developers the time needed to *properly* implement,
maintain, and repair those features.
Often connected to the this is the graphical guys (connected
because graphical is what sells; customers rarely pay for
optimized algorithm implementations deep down in the code).
Probably making myself new enemies I dare to say that gui,
colourful and generally graphics is the area of lowest quality
code. Simplyfying it somewhat and being blunt I'd state: Chances
are that your server will hum along years without problems. If
anything with a gui runs some hours without crashing and/or
filling up stderr, you can consider yourself lucky.
Not meaning to point fingers. But just these days I happened to
fall over a new gui project. Guess what? They had a colourful
presentation with lots of vanity, pipe dreams and, of course,
colours. That matches quite well what I have experienced.
Gui/graphical/colour stuff is probably the only area where people
seriously do design with powerpoint. I guess that's how they tick.
You can as well look at different developers. Guys developing for
an embedded system are often hesitating to even use a RTOS. Your
average non-gui, say server developer will use some libraries but
he will ponder their advantages, size, dependencies and quality.
Now enter the graphic world. John, creating some app, say, to
collect, show, and sort photos will happily and very generously
user whatever library sounds remotely usefull and doesn't run
away fast enough.
Results? An app on a microcontroller that, say, takes care of
building management in some 10K. A server in some 100K. And the
funny photo app with 12MB plus another 70MB
libraries/dependencies. The embedded sytem will run forever and
be forgotten, the server will be rebooted ever other year and the
photo app will crash twice a day.
