caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Brian Hurt <bhurt@spnz.org>
To: "Bauer, Christoph" <Christoph.Bauer@lms-gmbh.de>
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] The tag bit
Date: Thu, 12 Aug 2004 10:30:18 -0500 (CDT)	[thread overview]
Message-ID: <Pine.LNX.4.44.0408121023230.4282-100000@localhost.localdomain> (raw)
In-Reply-To: <D981925B4F2CD611870300E0184CEE9B0157F25F@mail.lms-gmbh.de>

On Thu, 12 Aug 2004, Bauer, Christoph wrote:

> Hello Caml-list,
> 
> why is the tag bit for a int/pointer is stored in and not next to a
> int/pointer.  Isn't it possible to divide the memory in blocks of 33 (65
> on 64 bit machines)  Words and the first Word contains all the tag bits?
> Then we can enjoy an extra bit, some arithmetic operations could be done
> faster and all floats could be unboxed.
> 
> Of couse this is just a naive idea, but please tell me why ;-)

My understanding:

1) The "extra overhead" of the tag bit is less than you might think in 
most code.  Yeah, you have to do an instruction or two to adjust for the 
tag bit in some cases- but Ocaml is pretty good at omitting them when 
they're not needed (when a variable is stored in a register, for example).  
And the cost of these extra instructions is not great- especially compared 
to other costs you might hit without knowing it.  They cost one, maybe 
two, clock cycles (assuming they aren't executed in parallel with other 
stuff, in which case they cost less than one clock cycle).  A mispredicted 
branch costs 12-30 clock cycles.  An L2 cache *hit* costs 20-30 clock 
cycles, and a cache *miss* that has to go to main memory 100-300 clock 
cycles.  You can no longer even vaguely predict performance by counting 
instructions with modern CPUs.

2) Moving the tag bit out of the word slows down the garbage collector, 
according to experiments the maintainers did.  It slows down the garbage 
collector by more than omitting the tag bit handling instructions speeds 
up the rest of the code.

3) Moving the tag bit out of word complicates handling variables of 
unknown type.  Currently, Ocaml can just move whole words, and be sure the 
type information (int vr.s pointer) the GC needs moves with the word.  
With the tag bits stored elsewhere, moving a value of unknown type becomes 
a lot more complicated, as you have to move the tag bits seperately.

-- 
"Usenet is like a herd of performing elephants with diarrhea -- massive,
difficult to redirect, awe-inspiring, entertaining, and a source of
mind-boggling amounts of excrement when you least expect it."
                                - Gene Spafford 
Brian

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners


      parent reply	other threads:[~2004-08-12 15:22 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-12 14:31 Bauer, Christoph
2004-08-12 14:55 ` Florian Hars
2004-08-12 14:56 ` Marcin 'Qrczak' Kowalczyk
2004-08-12 15:10 ` Olivier Pérès
2004-08-12 15:30 ` Brian Hurt [this message]

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.44.0408121023230.4282-100000@localhost.localdomain \
    --to=bhurt@spnz.org \
    --cc=Christoph.Bauer@lms-gmbh.de \
    --cc=caml-list@inria.fr \
    /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 NNTP newsgroup(s).