Just last week I went through the exercise of looking up the original
definition of Moore’s law and then used published
data on the number of transistors per processor chip in Intel processors
covering the time period from 1971 to 2008
and I can tell you that Moore’s law is still very healthy and still
cranking along. (I’m writing an article on the emergence
of the giga-age of computing.) The number of transistors on a processor
chip has increased at the average rate of
sqrt(2) per year.
The fact that you think that Moore’s law has something to do with cycle
times indicates to me that you do not understand
Moore’s law. That doesn’t surprise me, I had it wrong too and I have
written other papers on the subject. Moore’s law is
only about the number of transistors on chip, not about the speed of
those transistors.
Yes, I’m well aware of that. I was using it in the commonly-understood
sense, of increasing processor speeds and RAM
availability. The stuff that the article calls “the free lunch”. The
article covers exactly what you mentioned, in fact: that
transistor count has increased even though performance pretty much leveled
off after 2003.
Also, the implication that I think that Moore’s law allows you to write
inefficient code is just plain insulting. Moore’s law
changes computing so that what is efficient at one turn of the crank is no
longer effiecient at the next turn of the crank.
That’s a very odd interpretation, and one which I’ve never heard anywhere
else. Possibly because it’s just plain not true
and never has been. The availability of new computing power does not take
something that used to work efficiently and
make it perform poorly now; if it does, that means someone at the CPU
manufacturer screwed up badly.
You and I have got to argue more often, this is fun.
Yes, it is an odd interpretation, but then I am known for having an odd
point of view. Take the example of fixed point arithmetic. It used to be the
most efficient way to do computations for 2D and 3D graphics. Integer
arithmetic used to be by far the fastest way to do any kind of numeric
computation. A couple of turns of Moore’s crank and floating point
arithmetic becomes very much faster than integer arithmetic and fixed point
graphics pipelines went the way of the dinosaur. Another turn of the crank
and consumer CPUs got pipelined floating point vector operations and what
was a a few years ago a long sequence of integer and shift becomes one
vector instruction.
There are a couple of examples of Moore’s law making something that was the
most efficient way to do something the least efficient way to do something.
Unfortunately, that effect often works in reverse. Something that used to
be horribly slow in the past is now faster
because there’s more hardware to throw at it, and suddenly everyone thinks
they can get away with doing it that way.
Unfortunately, much like college professors
Don’t get me started on computer science college professors. I think we have
an equally low opinion of the current crop of computer science college
professors. Unforetunately I am a college instructor and I understand why
they do the stupid things they do. I don’t excuse them, but I do understand.
who all tend to assign an entire weekend’s worth of homework to their
students
when Friday comes around, there’s an unfortunate tendency for programmers
to overestimate the benefit they get from
their new hardware and also to arrogantly assume that they get it all to
themselves. When you’re running on a multitasking
system, (which is pretty much all of them these days), you’ll often see the
OS guys do this, and the driver guys, and the
people who write background processes/services, and the ones who write the
applications that the user cares about, and
before you know it, you’ve got Windows Vista.
Yep… and Windows XP before that and … and … Ever try to install Unix
on a 386?
I think you have the effect right, but I think you miss one important fact
that is the real culprit. Hardware has a life cycle measured in months to
years. Software has a life cycle measured in decades. The core assumptions
that go into a piece of software are like rails that force it down a fixed
path for a very long time. To change it you have to build a new set of
rails, i.e. rethink the whole thing. Hardware gets rethought constantly.
Hardware gets redesigned, sold, and forgotten, in over very short periods of
time.
Hardware is dramatically less complex than software.
This is the primary reason why today’s computers, despite having thousands
of times more raw hardware available,
actually execute fundamental real-world tasks such as booting up and
launching programs much, much slower
than computers of twenty years ago did.
Let me restate that, ok? The transfer rate from disk to RAM has not
increassed at anywhere near the rate of expansion of the size of OSes and
applications. Or to put it another way, if the speed limit is doubled but
the number of trucks has tripled you don’t get the load through as fast as
you used to.
Yep. That has happened. But, also the boot loader does a lot more than it
used to.
Problem is, people are still writing that way, even though that kind of
thinking
hasn’t been valid for at least six years now. (Anyone want a nice, hot cup
of Java?)
Actually, Java is one of the few languages out there that has built in
mulitprocessing. Some Java applications see a real improvement in
performance going from a single processor to a dual processor.
But, I get your point.
So if you were using “Moore’s Law” in the technical sense instead of the
colloquial sense, that’s good.
Well… I was to the best of my ability. BTW, when did Moore’s law start?
If you’re one of the
people who gets it, I’m very glad you’re here. There’s not too many people
left that do these days. I’m just trying to do
what little I can to stem the tide.
That’s OK by me. I’ve been programming since the early '70s I have some
accumulated knowledge.
Bob PendletonOn Thu, Mar 26, 2009 at 3:46 PM, Mason Wheeler wrote:
From: Bob Pendleton <@Bob_Pendleton>
Subject: Re: [SDL] SDLNet_TCP_Send blocking
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
–
±----------------------------------------------------------