From: Mark H Weaver <mhw@netris.org>
To: Andy Wingo <wingo@pobox.com>
Cc: "Ludovic Courtès" <ludo@gnu.org>, guile-devel@gnu.org
Subject: Re: Register VM WIP
Date: Wed, 16 May 2012 09:44:28 -0400 [thread overview]
Message-ID: <87sjf09r5v.fsf@netris.org> (raw)
In-Reply-To: <87fwb0k35g.fsf@pobox.com> (Andy Wingo's message of "Wed, 16 May 2012 09:15:23 +0200")
Hi Andy!
Andy Wingo <wingo@pobox.com> writes:
> On Wed 16 May 2012 06:23, Mark H Weaver <mhw@netris.org> writes:
>
>> It's surprising to me for another reason: in order to make the
>> instructions reasonably compact, only a limited number of bits are
>> available in each instruction to specify which registers to use.
>
> It turns out that being reasonably compact isn't terribly important --
> more important is the number of opcodes it takes to get something done,
> which translates to the number of dispatches. Have you seen the "direct
> threading" VM implementation strategy? In that case the opcode is not
> an index into a jump table, it's a word that encodes the pointer
> directly. So it's a word wide, just for the opcode. That's what
> JavaScriptCore does, for example. The opcode is a word wide, and each
> operand is a word as well.
>
> The design of the wip-rtl VM is to allow 16M registers (24-bit
> addressing). However many instructions can just address 2**8 registers
> (8-bit addressing) or 2**12 registers (12-bit addressing). We will
> reserve registers 253 to 255 as temporaries. If you have so many
> registers as to need more than that, then you have to shuffle operands
> down into the temporaries. That's the plan, anyway.
I'm very concerned about this design, for the same reason that I was
concerned about NaN-boxing on 32-bit platforms. Efficient use of memory
is extremely important on modern architectures, because of the vast (and
increasing) disparity between cache speed and RAM speed. If you can fit
the active set into the cache, that often makes a profound difference in
the speed of a program.
I agree that with VMs, minimizing the number of dispatches is crucial,
but beyond a certain point, having more registers is not going to save
you any dispatches, because they will almost never be used anyway.
2^12 registers is _far_ beyond that point.
As I wrote before concerning NaN-boxing, I suspect that the reason these
memory-bloated designs are so successful in the JavaScript world is that
they are specifically optimized for use within a modern web browser,
which is already a memory hog anyway. Therefore, if the language
implementation wastes yet more memory it will hardly be noticed.
If I were designing this VM, I'd work hard to allow as many loops as
possible to run completely in the cache. That means that three things
have to fit into the cache together: the VM itself, the user loop code,
and the user data. IMO, the sum of these three things should be made as
small as possible.
I certainly agree that we should have a generous number of registers,
but I suspect that the sweet spot for a VM is 256, because it enables
more compact dispatching code in the VM, and yet is more than enough to
allow a decent register allocator to generate good code.
That's my educated guess anyway. Feel free to prove me wrong :)
Regards,
Mark
next prev parent reply other threads:[~2012-05-16 13:44 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-11 16:19 Register VM WIP Andy Wingo
2012-05-11 20:29 ` Stefan Israelsson Tampe
2012-05-16 15:01 ` Andy Wingo
2012-05-14 21:09 ` Ludovic Courtès
2012-05-14 21:28 ` Andrew Gwozdziewycz
2012-05-15 18:45 ` Andy Wingo
2012-05-16 0:39 ` Noah Lavine
2012-05-16 4:23 ` Mark H Weaver
2012-05-16 7:15 ` Andy Wingo
2012-05-16 13:44 ` Mark H Weaver [this message]
2012-05-16 14:00 ` David Kastrup
2012-05-16 14:54 ` Noah Lavine
2012-05-16 15:05 ` Andy Wingo
2012-05-16 20:39 ` Ludovic Courtès
2012-05-16 14:58 ` Andy Wingo
2012-05-16 16:27 ` Mark H Weaver
2012-05-16 16:39 ` Andy Wingo
2012-05-16 18:23 ` Noah Lavine
2012-05-16 7:10 ` Andy Wingo
2012-05-15 18:49 ` Andy Wingo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87sjf09r5v.fsf@netris.org \
--to=mhw@netris.org \
--cc=guile-devel@gnu.org \
--cc=ludo@gnu.org \
--cc=wingo@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).