Status of Cardinal (was Re: Proposal to create a new mailing

[pat_eyler]

On 12/30/06, Gregory S. [email protected] wrote:

[deleted] Cardinal (Ruby on Parrot, which may or may not be dead)

It’s not dead, it’s pining for the fjords. No, actually, Kevin T., the
maintainer, has been bogged down with school related issues the
last two months, but has told me that he’s chomping at the bit to
start chasing Cardinal again.

You can track his progress at:
http://http://cardinal2.rubyforge.org/

(The original cardinal project appears to be dead, and Kevin’s had
no luck raising the maintainer to get the project transferred – if
anyone’s up to helping with with that, Kevin would probably
appreciate it.)

[pat_eyler]

On 12/30/06, pat eyler [email protected] wrote:

-pate

http://on-ruby.blogspot.com

I think Ruby/Parrot is pretty interesting. Anyone else interested
enough to put some time into it?

[pat_eyler]

Francis C. wrote:

http://http://cardinal2.rubyforge.org/
thanks,
-pate

http://on-ruby.blogspot.com

I think Ruby/Parrot is pretty interesting. Anyone else interested
enough to put some time into it?

Well … I’m not! Don’t you think jRuby, Rubinius, “Microsoft Ruby”, and
YARV are enough? jRuby and “Microsoft Ruby” have industrial support,
Rubinius and YARV have vibrant communities and core teams of excellent
hackers. The other two – Cardinal and the vmgen/Forth version, whose
name I’ve forgotten – have languished as half-person projects.

At one point I considered reviving the vmgen one because I’m a Forth
hacker (I know Forth better than I know C, in fact), but once I learned
that YARV had adopted direct threading and a stack machine – the two
core ideas behind vmgen – I abandoned that idea in a big hurry. Parrot
is a register machine because it caters to assembler programmers who
grew up on things like the Motorola 68000 and System\360, not because
that’s the “right way” to build a virtual machine for dynamic languages.

–
M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC(P)
http://borasky-research.blogspot.com/

If God had meant for carrots to be eaten cooked, He would have given
rabbits fire.

[pat_eyler]

On 12/30/06, M. Edward (Ed) Borasky [email protected] wrote:

You can track his progress at:

is a register machine because it caters to assembler programmers who

And another interesting idea bites the dust.

[pat_eyler]

On 12/30/06, M. Edward (Ed) Borasky [email protected] wrote:

You can track his progress at:

is a register machine because it caters to assembler programmers who
grew up on things like the Motorola 68000 and System\360, not because
that’s the “right way” to build a virtual machine for dynamic languages.

Exactly. I wasn’t going to chime in until someone broke the ice… but
the Parrot team basically can’t explain the design rationale. It’s
even featured in a solid book about virtual machines, along with a
narrative that amounts to: “Uhh… umm… this is certainly an
interesting way to go about it.”

From Ruby’s perspective, it also has the odd feature of having
separate registers for Strings and for Objects. shudder

Anyone who wants to hack on a Ruby VM will receive a warm welcome in
the arms of Rubinius.

P.S. I have the utmost respect for Parrot’s implementation team. It’s
just not the VM I want to see for Ruby.

[pat_eyler]

Francis C. wrote:

start chasing Cardinal again.

–Greg
enough to put some time into it?
that YARV had adopted direct threading and a stack machine – the two
If God had meant for carrots to be eaten cooked, He would have given
rabbits fire.

And another interesting idea bites the dust.

Well … as the old saying goes, “Adding programmers to a late project
makes it later.” I certainly don’t want to discourage Kevin T. from
pursuing his goals with Cardinal, and I don’t want to discourage anyone
else who thinks it’s “interesting”. But I have my own languishing
half-person projects to look after. And I have confidence that at
least jRuby, Rubinius and YARV are “good enough” without diluting the
Ruby implementation space with Parrot or vmgen.

I’m less sure about “Microsoft Ruby” for a number of reasons:

1. Microsoft’s attitude towards open source and software patents,
2. The fact that I haven’t heard much about the .NET/CLR-based
   implementations since RubyConf 2006, unlike the others, which are
   regularly discussed here,
3. The difficulties Austin Z. and Curt H. are having connecting
   with Microsoft over the issues associated with compiled Ruby extensions
   on the Windows platform,
4. The general feeling, as noted by Eric Raymond, that MacOS is the
   horse to beat in the race to the 64-bit desktop OS. Again, see

http://www.catb.org/~esr/writings/world-domination/world-domination-201.html

–
M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC(P)
http://borasky-research.blogspot.com/

If God had meant for carrots to be eaten cooked, He would have given
rabbits fire.

[pat_eyler]

Wilson B. wrote:

Exactly. I wasn’t going to chime in until someone broke the ice… but
the Parrot team basically can’t explain the design rationale. It’s
even featured in a solid book about virtual machines, along with a
narrative that amounts to: “Uhh… umm… this is certainly an
interesting way to go about it.”
What’s the name of the book? The only book I’ve seen is the O’Reilly
book on Perl 6 and Parrot. That pretty much ignores Python, PHP and
Ruby, of course.
From Ruby’s perspective, it also has the odd feature of having
separate registers for Strings and for Objects. shudder
IIRC they also have separate integer and float registers, just like many
real machines. That – a separate floating point stack vs. a single
“parameter stack” – was a big debate point in the discussions leading
up to the ANS Forth standard, and in the end, the standard had to be
written so either could be implemented.
Anyone who wants to hack on a Ruby VM will receive a warm welcome in
the arms of Rubinius.
Well … to repeat myself:

1. Adding programmers to a late project makes it later.
2. I have my own languishing half-person projects to look after.
3. I really really suck at C programming – I can just barely read C.

P.S. I have the utmost respect for Parrot’s implementation team. It’s
just not the VM I want to see for Ruby.
P.P.S: What exactly is the status of Perl 6?

–
M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC(P)
http://borasky-research.blogspot.com/

If God had meant for carrots to be eaten cooked, He would have given
rabbits fire.

[pat_eyler]

Wilson B. wrote:

P.P.S: What exactly is the status of Perl 6?

I will let this link stand on its own, with… no… further… commentary:
http://dev.perl.org/perl6/doc/design/syn/S05.html
Holy Toledo!

Forth is looking better every day

–
M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC(P)
http://borasky-research.blogspot.com/

If God had meant for carrots to be eaten cooked, He would have given
rabbits fire.

[pat_eyler]

On 12/30/06, M. Edward (Ed) Borasky [email protected] wrote:

Wilson B. wrote:

Exactly. I wasn’t going to chime in until someone broke the ice… but
the Parrot team basically can’t explain the design rationale. It’s
even featured in a solid book about virtual machines, along with a
narrative that amounts to: “Uhh… umm… this is certainly an
interesting way to go about it.”
What’s the name of the book? The only book I’ve seen is the O’Reilly
book on Perl 6 and Parrot. That pretty much ignores Python, PHP and
Ruby, of course.

Virtual Machines: Craig, Iain D.: 9781849969802: Amazon.com: Books

Badly needed an additional editor to fix typos and other mistakes, but
is a very interesting book none the less.

From Ruby’s perspective, it also has the odd feature of having
separate registers for Strings and for Objects. shudder
IIRC they also have separate integer and float registers, just like many
real machines. That – a separate floating point stack vs. a single
“parameter stack” – was a big debate point in the discussions leading
up to the ANS Forth standard, and in the end, the standard had to be
written so either could be implemented.

Anyone who wants to hack on a Ruby VM will receive a warm welcome in
the arms of Rubinius.
Well … to repeat myself:

1. Adding programmers to a late project makes it later.
2. I have my own languishing half-person projects to look after.
3. I really really suck at C programming – I can just barely read C.

Well, I meant it as a general invite.

P.P.S: What exactly is the status of Perl 6?

I will let this link stand on its own, with… no… further… commentary:
http://dev.perl.org/perl6/doc/design/syn/S05.html

[pat_eyler]

Robert D. wrote:

would be rolling already
Of the Ruby implementations, I’m guessing Rubinius is closest to a
“SmallRuby” as you describe it. At least the way Evan P. described
it at RubyConf makes me think that. However, I’m not at all thrilled
with the Squeak UI. It is so contrary to everything I do on a daily
basis that I find it difficult to do any more than replay the built-in
demos. And it’s visually unappealing to me on top of that. Squeak is an
exciting and interesting project – it’s just too far away from my
default modus operandi.

Actually it would attack the two most criticised points of Ruby
“speed” and
“IDE”
I haven’t seen benchmarks from the jRuby people recently and I don’t
recall ever seeing any from Rubinius, but I think jRuby is even now
faster than the standard C version on some benchmarks, and YARV is four
times as fast as the standard C version on my “Matrix” benchmark, which
(very indirectly) tests speed of “exact math”.

Concerning IDEs, I’ve already said that I find the Squeak UI unusable,
although I know I could learn it. But what’s the motivation for learning
Squeak? Aside from a rather nifty continuation-based web framework
called Seaside, there’s nothing written in Squeak that remotely
resembles any of the projects that interest me – computational finance,
applied mathematics, performance engineering.

The only thing that I find very interesting in Squeak is Squeak’s
rather extensive built-in MIDI/audio capabilities. Squeak appears to be
a fine platform for algorithmic composition and synthesis. But I’m so
used to the Lisp and CSound (and Lilypond and Rosegarden and Alsa-jack)
way of doing those things that it’s a tradeoff between learning another
way of doing something I already know how to do for the joy of learning
or just getting stuff done. Once again, it’s the triumph of “good
enough” over “cool beyond words”.

Let’s have a Ruby IDE that works the way Rubyists work – integrated
with Rspec/Rdoc/Ri/ZenTest/Rake/Hoe/Rubygems (and Rails/Mongrel – let’s
not forget Rails). Again, that’s probably a lot more like Rubinius and a
lot less like jRuby or “Microsoft Ruby”, which, after all, work the way
Java programmers or .NET programmers work for the most part.

As an aside, perhaps the JVM is more than just a virtual machine – at
least that’s the way it appears to me after seeing what jRuby is all
about. It seems to me to be very much an “operating system” –
concurrency primitives, process, thread and memory management, windowing
toolkit, mixing of languages (at least Ruby, Python, Java and C
extensions), etc.

Hmmm be careful about that statement I guess you know you might be
wrong
Yeah, I know – there’s no such thing as the one best way to do
something. And there’s nothing wrong with designing the Parrot virtual
machine as a register machine because the majority of people who will be
programming at that level are Motorola 68000 assembly programmers
either. But there is something wrong with implementing a new Ruby
virtual machine in Forth or Pascal or pseudo-M68000 assembler when the
majority of the people who will be programming at that level are C
programmers. C and the JVM and the CLR are “good enough”, with the
possible exception of concurrency primitives.

–
M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC(P)
http://borasky-research.blogspot.com/

If God had meant for carrots to be eaten cooked, He would have given
rabbits fire.

[pat_eyler]

I’m not jumping back into this in a big way, since it’s obvious
Ruby-on-Parrot isn’t intriguing to enough people to make it worth the
attention.

But on this point of register vs. stack machines. Most of the people
writing to the VM are language implementors, not ordinary users, and
they have a lot of sophisticated things to learn anyway. Most real
hardware supports the register-file model either natively, in
microcode, or with opcodes. I’m not convinced that the stack-based
model necessarily gives advantages over the register-based, and my
intuition says that other factors in the machine architecture are more
important.

Most of the recent work in VM optimization has taken place in the JVM
context, and involves extreme cleverness in regard to what code should
be compiled or recompiled to native opcodes, and when. But look at the
older literature, from before the release of Java, and you’ll find a
lot of stuff that is probably more germane to dynamic-language
processing (much of it done in the Smalltalk context, but still
generic): things like detecting and hard-compiling code that is not
likely to be metaprogrammed, and tuning these code paths heuristically
during the run.

My bottom line is this: I don’t care about Perl, not even a little
tiny bit. But I’m not convinced that we’ve asked enough questions
about the ideal VM characteristics for supporting highly-dynamic
languages. I know little about Rubinius and have not conversed with
Evan. I’m quite impressed with Charles’ work to date on JRuby, but the
JVM may not be the ideal platform for running Ruby. I don’t think
we’ve heard the last word.

And Ruby is in a distinct class compared to other dynamic languages
because of the unusual degree to which it encourages and benefits from
metaprogramming. No, that’s not to say other languages can’t do
similar things. It is to say that this is part of “the Ruby way,” and
I find Ruby handicapped by the huge performance penalty that
metaprogramming often imposes.

Concurrency primitives: at the end of the day, there is only one
primitive that is really required, and it MUST be supplied by the
hardware, not the VM. That’s the atomic check-and-set operation, of
course. Threading packages for C can be and often are supplied as
pure-userland libraries.

[pat_eyler]

Francis C. wrote:

But on this point of register vs. stack machines. Most of the people
writing to the VM are language implementors, not ordinary users, and
they have a lot of sophisticated things to learn anyway. Most real
hardware supports the register-file model either natively, in
microcode, or with opcodes. I’m not convinced that the stack-based
model necessarily gives advantages over the register-based, and my
intuition says that other factors in the machine architecture are more
important.
Well … most of the interesting problems in this area are either
NP-Complete or flat out unsolvable, so it boils down to questions of
what reasonably good programmers can get done in reasonable amounts of
time. For example, I think there’s an awful lot of optimization in GCC
that most of us could live very well without. Back in the “good old
days”, people used to compare compilers optimized for compile speed with
compilers that worked hard to generate fast code, and the typical result
was that there was only a factor of two improvement in run time speed
from working hard to generate fast code.

But when the code in question is a language interpreter or run-time,
that’s another thing entirely. In that case, I think you do want to
work hard to squeeze the most out of the hardware. I think you do want
to do what the vmgen/gforth project does – exploit things in GCC that
aren’t part of the C language standard to squeeze every last wasted
cycle out of the “inner interpreter”. And if it’s more efficient to
manage two or three stacks than dozens of registers, I think you want a
stack machine and not a register machine.

And given that you’ve embraced a GCC dependency, I think you do want
to go the extra step and put in assembly language kernels for x86,
x86-64 and probably PPC and SPARC and ARM architectures as well. Why
should a linear algebra library like Atlas, which runs continuously for
hours on a problem, be allowed to do that and not a language
interpreter, which also runs continuously for hours on a problem?

Most of the recent work in VM optimization has taken place in the JVM
context, and involves extreme cleverness in regard to what code should
be compiled or recompiled to native opcodes, and when.
Well, I’m not at all familiar with the Microsoft CLR, but I suspect
they’re got some equally bright folks hacking on it as well.
But look at the
older literature, from before the release of Java, and you’ll find a
lot of stuff that is probably more germane to dynamic-language
processing (much of it done in the Smalltalk context, but still
generic): things like detecting and hard-compiling code that is not
likely to be metaprogrammed, and tuning these code paths heuristically
during the run.
I’m not at all familiar with any of that. My background is “VLIW”,
vector and parallel supercomputing and FORTRAN compilers for same. As an
aside, it really saddens me that the current crop of pundits bemoans the
ascendancy of multi-core processors with whining about “the applications
aren’t ready, the software isn’t ready, the languages aren’t ready, the
operating systems aren’t ready, programmers don’t know how to deal with
concurrency,” etc., etc. Come on, people – Gene Amdahl formulated
Amdahl’s Law in 1967! There are teraflop computing platforms operating
today! The guts of multi-media – digital signal and image processing
– have been parallelized and vectorized since the mid-1970s!
My bottom line is this: I don’t care about Perl, not even a little
tiny bit. But I’m not convinced that we’ve asked enough questions
about the ideal VM characteristics for supporting highly-dynamic
languages. I know little about Rubinius and have not conversed with
Evan. I’m quite impressed with Charles’ work to date on JRuby, but the
JVM may not be the ideal platform for running Ruby. I don’t think
we’ve heard the last word.
Well … maybe we haven’t heard the “last” word, but we’ve certainly
heard the directions of the four major Ruby implementors – if there are
indeed still four. I think when all the smoke clears, at least jRuby and
YARV will still be standing and will be “for all practical purposes”
equivalent in performance. Rubinius in some form or another will survive
and thrive, though I’m not sure it will be as a virtual machine – I
think of it more as an IDE/OS in the same sense as Squeak is to
Smalltalk.
And Ruby is in a distinct class compared to other dynamic languages
because of the unusual degree to which it encourages and benefits from
metaprogramming. No, that’s not to say other languages can’t do
similar things. It is to say that this is part of “the Ruby way,” and
I find Ruby handicapped by the huge performance penalty that
metaprogramming often imposes.
This is where I think the edge goes to Rubinius.
Concurrency primitives: at the end of the day, there is only one
primitive that is really required, and it MUST be supplied by the
hardware, not the VM. That’s the atomic check-and-set operation, of
course. Threading packages for C can be and often are supplied as
pure-userland libraries.
It’s not just atomic check-and-set – it’s all of the conveniences
people expect. Message passing, monitors, lightweight processes a la
Erlang/Termite, drb, Rinda, starfish, high-speed numeric vector
processing – it all has to be there, either in the language or in a
library and supported efficiently by the run time on the major
operating systems and hardware. Otherwise, it violates the dictum that
it’s possible to write FORTRAN programs in any language.

–
M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC(P)
http://borasky-research.blogspot.com/

If God had meant for carrots to be eaten cooked, He would have given
rabbits fire.

[pat_eyler]

Robert D. wrote:

I guess it is very reasonable what you are saying and yet I`d wish to have
a SmallRuby, something squeakish you see. First that might really make the
difference for both languages and secondly it might as well turn out to be
faster and more agile than YARV or JRuby (well JRuby for sure as the used
language is just faster - Smalltalk just fits better to Ruby than Java).

You do know that Smalltalk, even in its fastest incarnations, is still
slower than Java, right? And Squeak is far from being one of the fastest
incarnations.

[pat_eyler]

On 12/31/06, M. Edward (Ed) Borasky [email protected] wrote:

And if it’s more efficient to
manage two or three stacks than dozens of registers, I think you want a
stack machine and not a register machine.
<<<

You haven’t established that it is more efficient. I’m completely
sympathetic to leveraging the strengths of particular hardware platforms
as
available, but observe that most mainstream hardware is register-based.
High-quality register-based code is far harder to automatically generate
than stack-based (try it sometime), but you have more potential to
squeeze
performance out of the machine by bypassing memory-bus cycles. Again,
try it
sometime. It’s not easy to do, and I surmise that some of the
attractiveness
of the stack-based model comes from its simplicity. And also from the
fact
that every register-based piece of hardware is different, so you’re
leaking
multiple abstractions into VM-level code where it arguably doesn’t
belong.
Does this make stack-based VMs axiomatically better-suited for dynamic
languages as opposed to languages like Java? I have no idea how to even
approach answering that question.

Concurrency primitives: all of the actual intra-process concurrency
features
you mentioned can be implemented straightforwardly, given the
availability
of the atomic check-and-set primitive. You mention a lot of things that
don’t fall into this realm, and as a former language designer, I think
there
is a stylistic tradeoff to be made among them. It may not necessarily
make
sense to implement all of them.

[pat_eyler]

On 12/30/06, M. Edward (Ed) Borasky [email protected] wrote:

start chasing Cardinal again.

–Greg
enough to put some time into it?

Well … I’m not! Don’t you think jRuby, Rubinius, “Microsoft Ruby”, and
YARV are enough? jRuby and “Microsoft Ruby” have industrial support,
Rubinius and YARV have vibrant communities and core teams of excellent
hackers. The other two – Cardinal and the vmgen/Forth version, whose
name I’ve forgotten – have languished as half-person projects.

I guess it is very reasonable what you are saying and yet I`d wish to
have
a SmallRuby, something squeakish you see. First that might really make
the
difference for both languages and secondly it might as well turn out to
be
faster and more agile than YARV or JRuby (well JRuby for sure as the
used
language is just faster - Smalltalk just fits better to Ruby than Java).
If only I were (a) rich, (b) a genius and (c) three persons the project
would be rolling already

Actually it would attack the two most criticised points of Ruby “speed”
and
“IDE”

At one point I considered reviving the vmgen one because I’m a Forth

hacker (I know Forth better than I know C, in fact), but once I learned
that YARV had adopted direct threading and a stack machine – the two
core ideas behind vmgen – I abandoned that idea in a big hurry. Parrot
is a register machine because it caters to assembler programmers who
grew up on things like the Motorola 68000 and System\360, not because
that’s the “right way” to build a virtual machine for dynamic languages.

Hmmm be careful about that statement I guess you know you might be wrong

–

M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC(P)
http://borasky-research.blogspot.com/

If God had meant for carrots to be eaten cooked, He would have given
rabbits fire.

Cheers
Robert

–
“The real romance is out ahead and yet to come. The computer revolution
hasn’t started yet. Don’t be misled by the enormous flow of money into
bad
defacto standards for unsophisticated buyers using poor adaptations of
incomplete ideas.”

• Alan Kay

[pat_eyler]

On 12/31/06, Francis C. [email protected] wrote:

available, but observe that most mainstream hardware is register-based.

Doesn’t this mapping imply generating platform-specific machine code
directly from the code that targets your V-ISA?
To my knowledge, Parrot isn’t planning to do this. (Feel free to
correct me with a link I missed on Google, though.)

That is a big, big job requiring more machine-level expertise than has
yet arrived in the #rubinius IRC channel. Heh.

That’s the basic thrust of my argument against register-based VMs.
Conceptually, the idea of having ‘hard’ mappings between virtual
registers and architected registers is cool. Actually implementing it
means basically reinventing gcc inside your project. Also, given that
by far the largest target platform is x86, and it has a tiny number of
gprs, you’re going to be doing a lot of shuffling anyway. Why not let
a compiler handle that for you, since they spend all day, every day,
working on making it good at that task?

[pat_eyler]

Francis C. wrote:

Concurrency primitives: all of the actual intra-process concurrency
features
you mentioned can be implemented straightforwardly, given the
availability
of the atomic check-and-set primitive. You mention a lot of things that
don’t fall into this realm, and as a former language designer, I think
there
is a stylistic tradeoff to be made among them. It may not necessarily
make
sense to implement all of them.
Well, given that Ruby already has threads, monitors, drb, Rinda,
starfish and NArray, you’d have to de-implement those if it doesn’t make
sense to implement them. And yes, a language designer does need to be
able to say “No”. But I think what I really want to see is, given the
visibility of concurrency and multi-core processors and energy
efficiency right now, for Ruby to have some compelling “killer language
features” for exploiting this trend.

–
M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC(P)
http://borasky-research.blogspot.com/

If God had meant for carrots to be eaten cooked, He would have given
rabbits fire.

[pat_eyler]

On 12/31/06, Wilson B. [email protected] wrote:

Doesn’t this mapping imply generating platform-specific machine code
means basically reinventing gcc inside your project. Also, given that
by far the largest target platform is x86, and it has a tiny number of
gprs, you’re going to be doing a lot of shuffling anyway. Why not let
a compiler handle that for you, since they spend all day, every day,
working on making it good at that task?

Fair enough, but from the small amount of commentary I’ve seen, I
don’t think parrot is going to matter to anyone anyway. From what I
can tell, most people would be happy with a Ruby implementation that
had “better” performance (in most cases that means faster and more
linear with respect to working set size), more modern GC, and native
threads. Very few people are looking for a “better” version of the
language itself, and since that would constitute a fork, it’s not
likely to succeed anyway.

Intel chips: why do you say they have a tiny number of gprs’s? That
hasn’t been true for years, unless your idea of tiny is as big as,
say, the size of the register file on an ultrasparc chip.

[pat_eyler]

On 12/31/06, Francis C. [email protected] wrote:

Conceptually, the idea of having ‘hard’ mappings between virtual
Fair enough, but from the small amount of commentary I’ve seen, I
say, the size of the register file on an ultrasparc chip.

Tiny compared to the PowerPC, for example. x86 is characterized by a
small number of registers, assisted by some crazy-fast instructions
for flipping them around. I think that’s a fair statement still, yes?

re: concurrency. We’re implementing STM in Rubinius, so you’ll be able
to say:
atomic do
critical section of code here
end

I’m (personally) amused by being able to use the same ‘pseudo-code’
syntax as the papers that introduced the idea of transactional memory.
Heh.

[pat_eyler]

Wilson B. wrote:

Also, given that
by far the largest target platform is x86, and it has a tiny number of
gprs, you’re going to be doing a lot of shuffling anyway. Why not let
a compiler handle that for you, since they spend all day, every day,
working on making it good at that task?
Actually, though, if you have a look at Software optimization resources. C++ and assembly. Windows, Linux, BSD, Mac OS X,
you’ll see that not only is the compiler working hard to do that, so
are those bazillions of transistors in the chip! Just because an 8088
only had half a dozen registers, none of which was truly general
purpose, and needed an 8087 to do floating point computing, doesn’t mean
a Tulsa can’t have hundreds or thousands of threads’ worth of copies of
the 8087 and 8088.

So why not have a Ruby inner interpreter that exploits the massive
parallelism, concurrency and caching that’s on the chip? In short, why
should Sun, Microsoft and the open source community build the Ruby
interpreters? Intel and AMD build their own compilers and math
libraries, or contract them out – why don’t they build Ruby (and Perl
and Python and PHP) interpreters too?

There’s not a heck of a lot I can do about AMD, but I am in Intel’s
back yard.

–
M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC(P)
http://borasky-research.blogspot.com/

If God had meant for carrots to be eaten cooked, He would have given
rabbits fire.