

Ask HN: Why is software often slow, despite the great advances in hardware? - azeirah


======
J_Darnley
B L O A T

L

O

A

T

Why bother with optimisation these days? Who cares about making something fast
when you can make it pretty? So what if everyone uses double precision
floating point numbers? "Use assembly? But that's too hard." "So what if my
CPU has an instruction that will let me multiply 32 integers at once? I want
to use floats." "I want to do it in a browser."

Software runs slow because nobody cares any more.

------
insoluble
At least from the business side of things, code efficiency matters only when
it makes a difference in the bottom line. If you can get the solution cranked
out in half (or less) the time by being careless with memory, algorithms, and
selection of third-party functions, the result is essentially double (or more)
the return on investment. In many cases with routine processing of business
data, a programmer would have to try to make a program run noticeably slowly.
Put another way, paying a coder is often more expensive than buying and
running a faster CPU.

PS: I have written some of my industries' most CPU efficient code on the
market, but this is only because it matters in my industries. On the other
hand, I have been in situations where efficiency is pretty insignificant, such
as when programming an installation procedure that the user runs only when
installing or removing the software.

------
Nomentatus
Yes, it's bad algorithms/bloat/poor code efficiency that are the immediate
cause, but as Socrates pointed out re the Presocratic philosophers, describing
only immediate causes can yield quite shallow explanations. The real question
is why the bloat and awful code and algorithms? I'll add to my previous reply
to that question, with an idea that occurred to me last night: one answer to
prisoner's dilemmas/tragedies of the commons is to appoint a supervisor whose
word is law, say when programs are running...

And what do you know, we already have one - called an OS. Someday, I expect
that OSes will be smart enough to examine the executables they have been given
(note that that can be done in parallel) and reward tight code with more
cycles, and punish sloppy code with lower priority (unless the user says
otherwise, which she may.) Our A.I. might well be good enough now, for that -
to do at least crude reverse engineering or pattern recognition rapidly
(doesn't have to be real time, of course.) This solves the prisoner's dilemma
(which is also a freeloading problem) by punishing the freeloaders and
rewarding the cooperators; now good code isn't slowed down just as if it too
were bad code; and most companies are forced to start tightening things up,
and to actually compete with each other to produce better code than most other
outfits. (For webpages - either the browser or OS could police webpages after
examining the code and load of pages.)

I do believe that's a patentable idea. Or two. Pity I'm working on another
patentable idea I like still more - but if someone wants to front me some real
money, please do drop a comment here.

~~~
Nomentatus
Some editing by reply follows, since the editor just ate a lot of work
(perhaps my edit straddled the time limit after posted when edits are
allowed):

The identification of programs as well or badly coded can take place outside
of the OS, and at a very different time and place, just as antivirus programs
work. A bloat=identifying program can do the analysis, judge the programs and
provide identifying bit sequences or hashes (if necessary to prevent evasion)
to the OS, which can then use that information to police who gets what
priority.

Other efficiency evaluation, including of script behavior, could be done
either in nearly real time, or over days or months, by the OS or another
program feeding data to it.

Some of this analysis would be straightforward, looking for known bad
patterns, other analyses might requite AI, neural nets or the sort of
combination (AI flags, humans confirm/disconfirm) that make Palintir hum.

Note that this doesn't just produce an immediate effect of shielding good
programs from the sluggishness of bad ones; the competition that this sets up
becomes something of a marketplace promoting efficiency that keeps becoming
more demanding; a competition in which efficiency once again makes you look
very good to your customers, as used to be the case when users could only run
one program at a time. Back then, we knew who was feeding us garbage code and
who wasn't. This invention let's us get back to something like that standard
while keeping our shiny new hardware and multitasking, too.

Who knows, one edit at a time, I may have put a unicorn patent into the
comments section of Hacker News as the idea occurred to me. Sliding down a
slippery slope to publication.

------
eslachance
The way I see it, it's essentially because of frameworks and engines. For
example in games, I've seen simple isometric games with very little graphic
intensity build with huge game engines like Unity or Unreal. 20 years ago,
that same game would have been built almost directly with machine code and be
just as beautiful (adjusting for screen resolution and quality from back
then). Well, that's my theory based largely on assumptions.

Software and Web is probably the same - I remember building very small
websites from scratch, painstakingly writing each line of HTML and CSS myself
to be as optimized as possible. Today, I'd probably have to start with a
framework like Foundation or Bootstrap. Or maybe Semantic-UI which would
require node.js to be installed and gulp and whatever. That stack can help
with fast development, but it's probably not as optimized as doing everything
in notepad++, right?

The company I work for just re-built our whole flagship product from scratch.
It was previously in Delphi 6, and now it's in Java. Notwithstanding the
prejudice against Java and speed, the reality is that the software now
requires like 16MB of RAM and _still_ takes more than a minute to load. And
then it's slow as hell, both for use and for actually producing its output
(it's print management and VDP).

Does it have anything to do with the number of librairies our dev team uses to
"simplify their lives"? I'm guessing it might.
[http://help.objectiflune.com/EN/planetpress-connect-user-
gui...](http://help.objectiflune.com/EN/planetpress-connect-user-
guide/1.1/Legal_Notices_and_Acknowledgements.htm)

------
Nomentatus
Note that clock speed hasn't been zooming ahead recently, compared to the
astonishing past, which you can see a lovely illustration of at:
[http://www.dailytech.com/A+Supercomputer+on+Your+Wrist+Infog...](http://www.dailytech.com/A+Supercomputer+on+Your+Wrist+Infographic+Series+Shows+Moores+Law+in+Action/article37369.htm)
Instead we mostly get more cores, but there's no general solution to the Von
Neumann bottleneck, so that's of limited help to the majority of software.
A.I. is benefiting, though. Building a safe, self-driving car using one core
would be rather difficult. So some software IS vastly improved.

And then there's Parkinson's Law, "work expands to fill the time allotted to
it". Just substitute "sloppiness" for "work" and "bandwith" or "CPU cycles"
for "time". Programmers haven't become cheaper or less in demand, so "sloppy"
(resource heavy) code is way cheaper than tight-and-hard-to-debug-and-
maintain. If you must hire more programmer hours to analyze bottlenecks or use
a lower-level language you do. But only if you must. So homeostasis sets in
(Parkinson's Law is all about effort-related-homeostasis.)"The hardware giveth
and the software taketh away" because that's cheapest for competitive software
businesses.

Part of that situation, too, is that the more the software/hardware is capable
of, the more kinds of tasks get done with it; but that also means way more
demand for programmers, so now you _really_ can't waste their time
"optimizing" everything. And as a result we have word processors that are
actually slower at times now, than back when the monitor screens were green
dots on black backgrounds. So that's homeostasis at work, too.

And then there's multitasking. There are dozens of pages and programs open
right now on my desktop, so a tragedy of the commons is taking place within
the humming innards of my PC; a prisoner's dilemma in which each program (and
the firm that made it) can hope that the others will only sip resources so
that they can steal more cycles and download fatter ads in a browser tab and
use sloppier code. They can be wasteful because the user won't usually know
which code is being piggy, and because they know others will be piggy if they
aren't. On the other hand, if they optimize like hell the customer probably
won't notice (given the other piggy programs the customer is running in the
background) so the software company has just thrown that money (a lot of
money) away. More homeostasis.

~~~
J_Darnley
Clock speed might not have been increasing but have you looked at how quick
newer processors execute the same instructions?

~~~
Nomentatus
You're right, there are complexities, and parallelism within each core, too -
but again, some instructions will benefit from this a lot more than others
(Von Neuman bottleneck, again.)

------
svisser
"I can already tell you what's going to happen to all those extra cycles that
faster hardware is going to give us in the next hundred years. They're nearly
all going to be wasted."

[http://www.paulgraham.com/hundred.html](http://www.paulgraham.com/hundred.html)

------
znpy
Algorithms. I mean, bad algorithms.

When your algorithms is O(N^2) or worse, like O(N^3), the computer will handle
small amount of data, and faster hardware will only allow your N to grow very
little.

(N being the amount of data your algorithm is dealing with).

------
LarryMade2
because it ins't optimised as much mainly because hardware is so much faster
and has greater capacity.

Back in the 90s you would still see big chunks of OSs and processor intensive
applications written in assembly. But as the processors got more efficient and
storage and operating RAM wasn’t a limit, programs could achieve the same
results with higher level languages and without much effort to optimise, so
developers stopped putting in as much effort into it.

