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

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

On Jun 19, 4:17 pm, "Michael J. Mahon" <mjma...@aol.com> wrote:

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

Which is as it should be I think... Transparent technology like for
instance pens that record what you write, and what you heard as you
wrote it - in sync :-)

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

That's a good one. I suspect we'll see the consolidation of multiple
applications into single address spaces as well. With many large apps
today running on VM's, it gets obscenely wasteful to run multiple
copies of said VM's holding multiple copies of bytecode and JIT
output. The security models of the two most popular VM's today permit
using the relatively cheap 'thread' context switch instead of a full
'process' switch. So there's a least some common areas where spending
the overhead of 64 bits ends up saving more in the long run.

> Using the large address space to enable large, sparse tables will, of
> course, make every "hit" into a page fault...

But a comparatively cheap hit, when compared to doing it further up
the stack...

Matt