Prev: Last Call for Papers Reminder (extended): World Congress on Engineering and Computer Science WCECS 2010
Next: ARM-based desktop computer ? (Hybrid computers ?: Low + High performance ;))
From: George Neuner on 22 Jul 2010 12:39
On Thu, 22 Jul 2010 09:46:44 +0100 (BST), nmm1(a)cam.ac.uk wrote:

>
>Also, the usefulness of [vector processors] was very dependent on
>whether they would allow 'fancy' vector operations, such as strided
>and indexed vectors, gather/scatter and so on. The number of programs
>that need only simple vector operations is quite small.
>
>I believe that, by the end, 90% of the cost of such machines was in
>the memory management and only 10% in the computation. At very
>rough hand-waving levels.

I get that ... but the near impossibility (with current technology) of
feeding several FPUs - vector or otherwise - from a shared memory
feeds right back into my argument that they need separate memories.

Reading further down the thread, Robert seems to be mainly concerned
with keeping his FPUs fed in a shared memory environment. I don't
really care whether the "Right Thing" architecture is a loose gang of
AL/FP units with programmable interconnects fed by scatter/gather DMA
channels[*]. Data placement and staging are, IMO, mainly software
issues (though, naturally, I appreciate any help the hardware can
give).

George

[*] Many DSPs can pipe one or more of their DMA channels through the
ALU to do swizzling, packing/unpacking and other rearrangements. Some
DSP permit general ALU operations on the DMA stream for use in real
time data capture.
From: nmm1 on 22 Jul 2010 12:49
In article <bjqg46hoimkgf5gj1jgedhv2q7h5k2jo8o(a)4ax.com>,
George Neuner <gneuner2(a)comcast.net> wrote:
>>
>>Also, the usefulness of [vector processors] was very dependent on
>>whether they would allow 'fancy' vector operations, such as strided
>>and indexed vectors, gather/scatter and so on. The number of programs
>>that need only simple vector operations is quite small.
>>
>>I believe that, by the end, 90% of the cost of such machines was in
>>the memory management and only 10% in the computation. At very
>>rough hand-waving levels.
>
>I get that ... but the near impossibility (with current technology) of
>feeding several FPUs - vector or otherwise - from a shared memory
>feeds right back into my argument that they need separate memories.

And, as I said, the killer with that is the very small number of
programs that can make use of such a system. The requirement for
'fancy' vector operations was largely to provide facilities to
transfer elements between locations in vectors.


Regards,
Nick Maclaren.
From: jacko on 22 Jul 2010 13:58
On 22 July, 17:49, n...(a)cam.ac.uk wrote:
> In article <bjqg46hoimkgf5gj1jgedhv2q7h5k2j...(a)4ax.com>,
> George Neuner  <gneun...(a)comcast.net> wrote:
>
>
>
> >>Also, the usefulness of [vector processors] was very dependent on
> >>whether they would allow 'fancy' vector operations, such as strided
> >>and indexed vectors, gather/scatter and so on.  The number of programs
> >>that need only simple vector operations is quite small.
>
> >>I believe that, by the end, 90% of the cost of such machines was in
> >>the memory management and only 10% in the computation.  At very
> >>rough hand-waving levels.
>
> >I get that ... but the near impossibility (with current technology) of
> >feeding several FPUs - vector or otherwise - from a shared memory
> >feeds right back into my argument that they need separate memories.  
>
> And, as I said, the killer with that is the very small number of
> programs that can make use of such a system.  The requirement for
> 'fancy' vector operations was largely to provide facilities to
> transfer elements between locations in vectors.
>
> Regards,
> Nick Maclaren.

Let's call this the data shovelling to data processing ratio. SPR.
From: George Neuner on 22 Jul 2010 14:16
On Wed, 21 Jul 2010 21:48:38 -0700, Andy Glew <"newsgroup at
comp-arch.net"> wrote:

>On 7/21/2010 3:46 PM, Alex McDonald wrote:
>
>> Can you be more explicit on this? I understand the lack of complete
>> virtualization is an issue with the x86, but I'm fascinated by your
>> claim of exploitable design flaws; what are they?
>
>The 80386 and othrr processors, up until recently, were incompletely
>self virtualizing.
>
>However, as far as I know, with the addition of VMX at Intel, and
>Pacifica at AMD, the x86 processors are now completely self virtualizing.

Yes, but last year there was a claim of some rootkit type hack that
could take control of Intel's hypervisor. I don't know any details, I
just remember seeing a headline.

George
From: Robert Myers on 22 Jul 2010 14:41
On Jul 22, 11:37 am, George Neuner <gneun...(a)comcast.net> wrote:
> On Wed, 21 Jul 2010 18:18:19 -0400, George Neuner
>
> <gneun...(a)comcast.net> wrote:
>
> > Some stuff
>
> I think the exchange among Robert, Mitch and Andy that just appeared
> answered most of my question.
>

I feel like I'm walking a tightrope in some of these discussions.

At a time when vector processors were still a fading memory (even in
the US), an occasional article would mention that "vector computers"
were easier to use for many scientists than thousands of cots
processors hooked together by whatever.

The real problem is not in how the computation is organized, but in
how memory is accessed. Replicating the memory access style of the
early Cray architectures isn't possible beyond a very limited memory
size, but it sure would be nice to figure out a way to simulate the
experience.

Robert.

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
Prev: Last Call for Papers Reminder (extended): World Congress on Engineering and Computer Science WCECS 2010
Next: ARM-based desktop computer ? (Hybrid computers ?: Low + High performance ;))