Re: ADT Pro With Windows 7 (64-Bit)

[mdj <mdj.mdj@gmail.com>]

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.

> 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.

> 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

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.

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 ...

Matt