[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ADT Pro With Windows 7 (64-Bit)
mdj wrote:
On Jun 15, 6:22 pm, "Michael J. Mahon" <mjma...@aol.com> wrote:
The industry would like nothing better than to be perceived as creating
real value at a pace that leaves users in danger of being "left behind".
The truth is that the PC industry is essentially stagnant, and has been
so for almost the last decade. They gave up on more sequential MIPS,
which actually reduces the delay between click and screen update, and
replaced it with more cores, which deliver very little speedup to most
users doing most tasks (assuming a reasonable OS scheduler).
My own predictor for this unfortunate situation was media: once
commodity hardware could manipulate AV data easily, the last
application requiring more raw grunt passed us by ... It's not so much
that you *can't* make a faster chip, but without the next big app to
drive it, there's no compelling reason to invest the billions in the
r&d required.
Actually, it's still worth a lot to Intel (and AMD) to design and
manufacture faster chips--the problem is that they don't know how to
do it within the constraints of mainstream systems (eg, less than 100W
of power dissipation by the processor).
The fact is, if they can sell people on the idea that "more cores" is
as good as "faster cores", then they can play the standard "memory-like"
Moore's "Law" improvement, just replicating more cores on a single chip.
(Of course, they need to share a lot of cache, so it's not "simple"
replication, but the rules are pretty simple and well understood.
Making faster cores, on the other hand, is not so simple. Most of the
low-hanging fruit of single-thread parallel execution was harvested by
the late 1990s, so there's not much left to do to speed up a single
thread but increase the clock speed--and that has become increasingly
difficult--especially given power limitations.
As lithography is pushed to ever finer feature sizes, it has become
necessary to do heroic things to work around metal lines becoming
more like RC delay networks, and MOS gates from becoming quite leaky.
There are still some small clock speedups, but they are certainly
minor compared to the "doubling every year and a half" that the PC
industry cut its teeth on.
So it isn't so much that they don't think they would be plentifully
rewarded for developing faster cores--it's that it has become a losing
game, regardless of how much money you have to invest.
BTW, chip fabricators--particularly Intel--continue to invest billions
to build new fabs for the next smaller process "node"--it's just that
newer processes enable *more* cores, not noticeably *faster* cores. And
the cost of the "next generation" fab continues to grow exponentially--
just like Moore's "Law". ;-)
Physical limits aside, it seems that we are approaching a point where
the game may not be worth the candle.
Tiny *low power* chips and circuits are, on the other hand, in great
demand--mobile devices demand them.
The applications available for PCs (and Macs, no reason to leave anyone
out ;-) have not changed much in several years, so rational users do not
see a compelling value proposition for more, more, more.
What they *would* value is a system that delivered a more carefree,
easier to use computing experience. We used to think that meant more
processing, but the Mac has demonstrated that it can be delivered on
exactly the same hardware with only cleverer software and tighter
configuration control.
I don't use a Mac, but the success of their current marketing
strategy shows that the market values reliability and ease of use
over raw (and mostly wasted) *potential* performance.
And interestingly, the current Mac OS allows programs that can benefit
from it (ie. Photoshop, Final Cut) to run as 64-bit processes on an OS
that is still ostensibly 32-bit. This is probably the most sensible
solution, although I note that the new OS "Snow Leopard" seems to have
gone 64, probably just so the engineering team can avoid maintaining
both a server and client OS build.
That's the main driving force for Microsoft, too. Getting back to a
single OS root and testing process is a huge cost saver.
I'll be the first to move to 64-bits when it enables me to do
something *that I want to do*, preferably without preventing me
from doing a bunch of other things that I want to do. ;-)
Likewise, although I admit my work machine is currently a 64 bit linux
VM running on a Mac. This is only so that I can guarantee the software
stack I develop on is byte-for-byte the same as our server
infrastructure. Also means we don't have to package everything for
both x86_64 and ia32
I would expect developers to be "early adopters", since it is their
work that will eventually drive widespread adoption (if it's a "pull"
adoption rather than a Microsoft "push" ;-).
It's interesting how many "programmers" have made the assumption that
more==faster with regards to 64-bit, completely overlooking the fact
that 8 byte vs 4 byte pointers eats cache lines *much* faster, reduces
pipelining effectiveness, and just generally wastes resources,
particularly considering that current 64-bit processors only have
40-48 bit MMU's. I keep wondering if we'll see a repeat of what
happened in the 68k era, where unused bits at the high end of address
registers were re-purposed for other things ... It's perhaps a
testament to how much 'headroom' there is in current systems vs. the
typical workload that nobody has noticed the performance hit.
Yes, it will be quite a while before the upper 16 bits of 64-bit
physical addresses mean anything--or even exist! ;-)
That said (and without wanting to play devils advocate), there are a
few interesting data structures you can start playing with once things
are 64 bit, for instance very large sparse hash tables. This is useful
for "desktop search" applications like Apple's Spotlight or Google
Desktop (and whatever the Microsoft equivalent is), which can use this
to efficiently index and correlate all the information on your system.
That's about the only legitimate use of a 64 bit address space I can
think of on a desktop machine these days, but that said, Spotlight-
like functionality is very handy, and you couldn't pay me to go
back ...
Actually, one of the possibilities of a 64-bit address space is that
libraries (DLLs) can be statically linked to fixed addresses. The
Apollo Domain OS took this approach in the early 1990s allowing some
very advanced system concepts to be implemented rather simply.
Using the large address space to enable large, sparse tables will, of
course, make every "hit" into a page fault...
-michael
******** Note new website URL ********
NadaNet and AppleCrate II for Apple II parallel computing!
Home page: http://home.comcast.net/~mjmahon/
"The wastebasket is our most important design
tool--and it's seriously underused."