Re: Never reinstall XP again

On Wed, 18 Feb 2009 06:04:42 -0800 (PST), MooseFET
<kensmith@xxxxxxxxx> wrote:

On Feb 18, 5:09 am, Sylvia Else <syl...@xxxxxxxxxxxxxxxxxxx> wrote:
krw wrote:
In article <008ea72d$0$1043$c3e8...@xxxxxxxxxxxxxxxxx>,
syl...@xxxxxxxxxxxxxxxxxxx says...>
krw wrote:
On Tue, 17 Feb 2009 19:52:04 -0800 (PST), MooseFET
<kensm...@xxxxxxxxx> wrote:

On Feb 17, 6:44 am, krw <k...@xxxxxxxxxxxxx> wrote:
In article <fc4680b5-b18e-42cf-8815-749e75f71d02
@a12g2000pro.googlegroups.com>, kensm...@xxxxxxxxx says...>

On Feb 16, 5:59 pm, Sylvia Else <syl...@xxxxxxxxxxxxxxxxxxx> wrote:
MooseFET wrote:
On Feb 15, 9:22 pm, Sylvia Else <syl...@xxxxxxxxxxxxxxxxxxx> wrote:
MooseFET wrote:
On Feb 15, 5:45 pm, Sylvia Else <syl...@xxxxxxxxxxxxxxxxxxx> wrote:
repairtool....@xxxxxxxxx wrote:
Never reinstall XP again, New professional repair tool. Keeps data and
applications in-tact.
Even when I upgrade my MB/CPU?
No, your new MB has to run with Vista because there is no XP driver
for the type of hard disk chip it uses.  None of your programs from
XP, however, will run under Vista so you have to upgrade them to the
new Vista version.  Unfortunately for some reason, the new version
can't read all of the files made with the older versions.  You can buy
a conversion program to fix this, but that won't install because the
hard disk isn't big enough.
Perhaps a little overstated, but I know the feeling.
Memo to whoever makes these decisions - PCI-Ex and SATA are good enough.
Please don't change these interfaces again.
You know that they will change them.
Yes, I do. But one can dream.
The best we can hope for is that the next step is a big one.  I think
that the next place that really needs a look is in the area of getting
rid of most of the memory to CPU and back transfers.
It is common already for CPUs to multiple cores and those cores to
have multiple ALUs but they all live on the same end of the same bus
structure.  If some of the ALUs were moved elsewhere, trips over the
bus could be saved.
Please explain. The ALU is *part* (actually, many parts) of the
CPU.  How are you going to move it "elsewhere" and where is
"elsewhere".
Consider incrementing a word in memory.  If the memory in question can
be told to increment, the value doesn't have to travel, only the
command does.  This is a simple case, but is common enough that the
saving on bus trips could be real.
The difference in size between the "command" and the data is?  Someone
has to be the master.

Graphics cards now contain a lot of the stuff that used to be done by
CPUs.  This could be extended.  Painting a transparent image over an
existing picture requires some multiplies and adds.  The graphics card
could handle this in real time.
Only because CPUs were really *bad* at it.  GPUs still need a little
bit of memory, and bandwidth to same.

Still, other than on-MB GPUs, they use their own dedicated memory, thus
avoiding loading the CPU-memory bus. They do therefore illustrate to
some extent the memory bandwidth benefits that accrue from
decentralising computation.

True, though this is also done with SMP (ex. Opteron).  This isn't
what MF is suggesting, though.  Well, since he's in hiding...

It's not. I'd say that what he was thinking of was something closer to
some kinds of array processor, where the distinction between memory and
processing becomes somewhat blurred.

Consider the transputer as an example of one type of array processor.

Consider how successful that's been.

Which is not to say I expect any movement in that direction. Such
techniques are useful for special problems, but most of the work done by
a typical PC (graphics apart) is not of that type.

Most PCs spend most of their time play Freecell. The games are very
graphic intense. Moving processing power into the the memory that
holds the image makes sense for those.

Moving processing power (or adding hardwired logic) to any *fixed*
algorithm makes sense. Not so much with general purpose processors.

I suspect that any benefit that could be achieved by decentralised
processing for a typical PC workload could be achieved at a lower cost
by increasing the size of the processor cache.

You may be right in all but the graphics or sound areas. When actual
outputs must be made the data from the cache must go to the device.

Because graphics aren't general purpose processing.
.

Relevant Pages

  • Re: Never reinstall XP again
    ... XP, however, will run under Vista so you have to upgrade them to the ... rid of most of the memory to CPU and back transfers. ... bus could be saved. ... a typical PC (graphics apart) is not of that type. ...
    (sci.electronics.design)
  • Re: Never reinstall XP again
    ... XP, however, will run under Vista so you have to upgrade them to the ... rid of most of the memory to CPU and back transfers. ... bus could be saved. ... Consider incrementing a word in memory. ...
    (sci.electronics.design)
  • Re: Never reinstall XP again
    ... XP, however, will run under Vista so you have to upgrade them to the ... It is common already for CPUs to multiple cores and those cores to ... bus could be saved. ... Consider incrementing a word in memory. ...
    (sci.electronics.design)
  • Re: Never reinstall XP again
    ... XP, however, will run under Vista so you have to upgrade them to the ... rid of most of the memory to CPU and back transfers. ... bus could be saved. ... Consider incrementing a word in memory. ...
    (sci.electronics.design)
  • Re: 4GB Memory on my 32 bit CPU
    ... Your header says you're using the Windows Mail program, ... runs under the Vista versions of Windows. ... and not the programs you tell it to run, even if more memory is installed. ... send to the graphics board. ...
    (comp.sys.hp.hardware)
Loading