info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Do I Think VVM Is a Bad Idea?
71 views
Skip to first unread message
Quadibloc
Sep 5, 2021, 8:37:43 AM9/5/21
to
No, not at all.
One thing, though, should be noted. I think that even the original Cray-I had
data forwarding - so that if a vector instruction was followed by another vector
instruction that operated on its result, and which used a different ALU that was
available, that second instruction started before the first instruction completed
working on the whole vector.
So conventional vector operations don't have to have the flaw that VVM
addresses.
In fact, in my original Concertina architecture, I believe I stole that idea. If you
look at that architecture, though, you might not see it. It has long vectors
and short vectors. Long vectors are conventional Cray-I style, and short
vectors are conventional MMX/SSE/AVX style. Neither one is anything like
VVM.
So where did I steal VVM?
Elsewhere, I have what I refer to as "dataflow instructions". *This* is
where I conceptualized something like VVM as belonging. That's where I
define a series of operations that work on one operand at a time, but are
chained together, with input arrays and output arrays defined for it.
So absolutely I recognized that since one can put multiple ALUs on a chip,
there ought to be a way to directly specify an operation that keeps them
all busy for a while. But I put that in a separate category from conventional vector instructions, which I also saw as useful.
John Savard
One thing, though, should be noted. I think that even the original Cray-I had
data forwarding - so that if a vector instruction was followed by another vector
instruction that operated on its result, and which used a different ALU that was
available, that second instruction started before the first instruction completed
working on the whole vector.
So conventional vector operations don't have to have the flaw that VVM
addresses.
In fact, in my original Concertina architecture, I believe I stole that idea. If you
look at that architecture, though, you might not see it. It has long vectors
and short vectors. Long vectors are conventional Cray-I style, and short
vectors are conventional MMX/SSE/AVX style. Neither one is anything like
VVM.
So where did I steal VVM?
Elsewhere, I have what I refer to as "dataflow instructions". *This* is
where I conceptualized something like VVM as belonging. That's where I
define a series of operations that work on one operand at a time, but are
chained together, with input arrays and output arrays defined for it.
So absolutely I recognized that since one can put multiple ALUs on a chip,
there ought to be a way to directly specify an operation that keeps them
all busy for a while. But I put that in a separate category from conventional vector instructions, which I also saw as useful.
John Savard
Quadibloc
Sep 5, 2021, 9:04:27 AM9/5/21
to
On Sunday, September 5, 2021 at 6:37:43 AM UTC-6, Quadibloc wrote:
> Elsewhere, I have what I refer to as "dataflow instructions".
I thought I did, but I see that, no, I hadn't gotten that far. The Extended
> Elsewhere, I have what I refer to as "dataflow instructions".
Translate Instructions don't quite qualify.
John Savard
Stefan Monnier
Sep 5, 2021, 12:11:10 PM9/5/21
to
> One thing, though, should be noted. I think that even the original Cray-I had
> data forwarding -
I believe the official name for it is "chaining".
> data forwarding -
Stefan
MitchAlsup
Sep 5, 2021, 1:21:52 PM9/5/21
to
On Sunday, September 5, 2021 at 7:37:43 AM UTC-5, Quadibloc wrote:
> No, not at all.
>
> One thing, though, should be noted. I think that even the original Cray-I had
> data forwarding - so that if a vector instruction was followed by another vector
> instruction that operated on its result, and which used a different ALU that was
> available, that second instruction started before the first instruction completed
> working on the whole vector.
<
The CRAY-1 had a "chain slot" and if the subsequent instruction was ready to
> No, not at all.
>
> One thing, though, should be noted. I think that even the original Cray-I had
> data forwarding - so that if a vector instruction was followed by another vector
> instruction that operated on its result, and which used a different ALU that was
> available, that second instruction started before the first instruction completed
> working on the whole vector.
<
"go" by the time the chain slot rolled around, the 2 instructions forwarded data
and ran "as one" until the end of the vector arrived.
<
The CRAY-1 X/MP solved this problem and could forward on/at any cycle after
the data arrived. This machine also had 3 AGEN ports to memory per cycle.
>
> So conventional vector operations don't have to have the flaw that VVM
> addresses.
>
> In fact, in my original Concertina architecture, I believe I stole that idea. If you
> look at that architecture, though, you might not see it. It has long vectors
> and short vectors. Long vectors are conventional Cray-I style, and short
> vectors are conventional MMX/SSE/AVX style. Neither one is anything like
> VVM.
>
> So where did I steal VVM?
>
> Elsewhere, I have what I refer to as "dataflow instructions". *This* is
> where I conceptualized something like VVM as belonging. That's where I
> define a series of operations that work on one operand at a time, but are
> chained together, with input arrays and output arrays defined for it.
<
You don't need to consider VVM as "dataflow" instructions, you can just
> So conventional vector operations don't have to have the flaw that VVM
> addresses.
>
> In fact, in my original Concertina architecture, I believe I stole that idea. If you
> look at that architecture, though, you might not see it. It has long vectors
> and short vectors. Long vectors are conventional Cray-I style, and short
> vectors are conventional MMX/SSE/AVX style. Neither one is anything like
> VVM.
>
> So where did I steal VVM?
>
> Elsewhere, I have what I refer to as "dataflow instructions". *This* is
> where I conceptualized something like VVM as belonging. That's where I
> define a series of operations that work on one operand at a time, but are
> chained together, with input arrays and output arrays defined for it.
<
as easily consider this simply a means to perform several iterations of
a loop simultaneously.
Quadibloc
Sep 5, 2021, 10:54:16 PM9/5/21
to
On Sunday, September 5, 2021 at 11:21:52 AM UTC-6, MitchAlsup wrote:
> You don't need to consider VVM as "dataflow" instructions, you can just
> as easily consider this simply a means to perform several iterations of
> a loop simultaneously.
That's true enough, but I hope I've made my point clear: while I was perfectly
> You don't need to consider VVM as "dataflow" instructions, you can just
> as easily consider this simply a means to perform several iterations of
> a loop simultaneously.
satisfied with conventional vector instructions as a way to perform operations
on vectors... I do also see the value of a mechanism that somewhat resembles
VVM, where one specifies input vectors and output vectors - and then associates
with them multiple operations, linked to each other in code that doesn't look too
much different from a conventional loop.
But the value I see in such a mechanism is primarily as a tool to make use of
dataflow-style hardware, if available on the CPU. Not as a better way to do
"ordinary" vector arithmetic.
Now, I may have conceptualized this wrong, or I'm working in a direction that
really hasn't much to do with your goals with VVM.
John Savard
gareth evans
Sep 6, 2021, 6:49:33 AM9/6/21
to
I've googled and come up with the Visual Virtual Machine which appears
to be a didactic thing, and cannot possibly be what is discussed above?
Anton Ertl
Sep 6, 2021, 9:27:58 AM9/6/21
to
Mitch Alsup's Virtual Vector M. Not sure whether M stands for method,
machine, or something else.
- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>
machine, or something else.
- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>
Stefan Monnier
Sep 6, 2021, 10:24:28 AM9/6/21
to
Anton Ertl [2021-09-06 13:26:32] wrote:
> gareth evans <headst...@yahoo.com> writes:
>>Pardon my ignorance, but what is VVM in computing?
> Mitch Alsup's Virtual Vector M. Not sure whether M stands for method,
> machine, or something else.
M..itch?
> gareth evans <headst...@yahoo.com> writes:
>>Pardon my ignorance, but what is VVM in computing?
> Mitch Alsup's Virtual Vector M. Not sure whether M stands for method,
> machine, or something else.
Stefan
Michael S
Sep 6, 2021, 10:27:28 AM9/6/21
to
Quadibloc
Sep 6, 2021, 11:10:50 AM9/6/21
to
On Monday, September 6, 2021 at 4:49:33 AM UTC-6, gareth evans wrote:
> Pardon my ignorance, but what is VVM in computing?
Oops, must have been crossposted. Virtual Vector Method refers to
> Pardon my ignorance, but what is VVM in computing?
something Mitch Alsup has devised in his personal architectural
projects.
John Savard
Stephen Fuld
Sep 6, 2021, 11:20:27 AM9/6/21
to
VVM is Virtual Vector Method, a feature of a CPU that frequent poster
Mitch Alsup is designing. Briefly, it is new way to implement the
functionality of vector handling without all the "mess" of SIMD
instructions. IMHO it has many very nice features.
--
- Stephen Fuld
(e-mail address disguised to prevent spam)
MitchAlsup
Sep 6, 2021, 12:08:05 PM9/6/21
to
On Sunday, September 5, 2021 at 9:54:16 PM UTC-5, Quadibloc wrote:
> On Sunday, September 5, 2021 at 11:21:52 AM UTC-6, MitchAlsup wrote:
>
> > You don't need to consider VVM as "dataflow" instructions, you can just
> > as easily consider this simply a means to perform several iterations of
> > a loop simultaneously.
<
> That's true enough, but I hope I've made my point clear: while I was perfectly
> satisfied with conventional vector instructions as a way to perform operations
> on vectors...
<
Only for a brief time around 1980 was I satisfied with CRAY-like vectors.
> On Sunday, September 5, 2021 at 11:21:52 AM UTC-6, MitchAlsup wrote:
>
> > You don't need to consider VVM as "dataflow" instructions, you can just
> > as easily consider this simply a means to perform several iterations of
> > a loop simultaneously.
<
> That's true enough, but I hope I've made my point clear: while I was perfectly
> satisfied with conventional vector instructions as a way to perform operations
> on vectors...
<
Only for a brief time around 2002 was I satisfied with SIMD-like vectors.
<
> I do also see the value of a mechanism that somewhat resembles
> VVM, where one specifies input vectors and output vectors - and then associates
> with them multiple operations, linked to each other in code that doesn't look too
> much different from a conventional loop.
>
> But the value I see in such a mechanism is primarily as a tool to make use of
> dataflow-style hardware, if available on the CPU. Not as a better way to do
> "ordinary" vector arithmetic.
<
While the tool does highly leverage the resources used to fire instructions into
> I do also see the value of a mechanism that somewhat resembles
> VVM, where one specifies input vectors and output vectors - and then associates
> with them multiple operations, linked to each other in code that doesn't look too
> much different from a conventional loop.
>
> But the value I see in such a mechanism is primarily as a tool to make use of
> dataflow-style hardware, if available on the CPU. Not as a better way to do
> "ordinary" vector arithmetic.
<
execution data-flow style, it was not developed directly to utilize those. That
fell out for free.
>
> Now, I may have conceptualized this wrong, or I'm working in a direction that
> really hasn't much to do with your goals with VVM.
<
VVM started life as a means to allow a 1-wide in order machine to match the
> Now, I may have conceptualized this wrong, or I'm working in a direction that
> really hasn't much to do with your goals with VVM.
<
average performance of GBOoO machines when performing small loops.
>
> John Savard
MitchAlsup
Sep 6, 2021, 12:08:30 PM9/6/21
to
On Monday, September 6, 2021 at 8:27:58 AM UTC-5, Anton Ertl wrote:
> gareth evans <headst...@yahoo.com> writes:
> >Pardon my ignorance, but what is VVM in computing?
> Mitch Alsup's Virtual Vector M. Not sure whether M stands for method,
> machine, or something else.
<
Method.
> gareth evans <headst...@yahoo.com> writes:
> >Pardon my ignorance, but what is VVM in computing?
> Mitch Alsup's Virtual Vector M. Not sure whether M stands for method,
> machine, or something else.
<
MitchAlsup
Sep 6, 2021, 12:08:55 PM9/6/21
to
>
>
> Stefan
0 new messages