Which is faster?

classic Classic list List threaded Threaded
44 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Which is faster?

Thiago Bastos-3
Hi,

When getting null-terminated strings from Lua, does lua_strlen() offer any speed advantage over regular strlen() calls?

I imagine Lua stores string lengths in its objects, but am not sure if going through Lua's internal structures will really eat less cpu cycles than doing a strlen().

Does anyone here know that for sure?

Thanks!
Thiago Bastos


Reply | Threaded
Open this post in threaded view
|

Which is faster?

Thiago Bastos-3
Hi,

When getting null-terminated strings from Lua, does lua_strlen() offer any speed advantage over regular strlen() calls?

I imagine Lua stores string lengths in its objects, but am not sure if going through Lua's internal structures will really eat less cpu cycles than doing a strlen().

Does anyone here know that for sure?

Thanks!
Thiago Bastos


Reply | Threaded
Open this post in threaded view
|

Re: Which is faster?

RLak-2
In reply to this post by Thiago Bastos-3
> When getting null-terminated strings from Lua, does lua_strlen() offer
any
> speed advantage over regular strlen() calls?

> I imagine Lua stores string lengths in its objects, but am not sure if
going
> through Lua's internal structures will really eat less cpu cycles than
doing a strlen().

> Does anyone here know that for sure?

I guess it depends how long your strings are and what C compiler you are
using. Call lua_strlen() costs you a function call, a
stack-index-to-address conversoin, a couple of sanity checks, and a field
lookup -- perhaps 20 instructions at the outside. If you use a
highly-optimising C compiler which open codes strlen(), and your strings
are all just a few characters long, then strlen() might be a couple of
instructions less. If, on the other hand, strlen() itself does a subroutine
call, it is very unlikely that it will be faster. (And with lua_strlen()
you don't have to worry about whether the string has internal NULs).

On the other hand, if you are importing a string into Lua, you should be
aware that strlen() will be called unless you explicitly specify a length.
So there is certainly no value in exporting a string from C into Lua in
order to call lua_strlen().

Hope that helps.

Rici




Reply | Threaded
Open this post in threaded view
|

Re: Which is faster?

Luiz Henrique de Figueiredo
>When getting null-terminated strings from Lua, does lua_strlen() offer any speed advantage over regular strlen() calls?

If you mean strlen from the C standard library, then yes.
Moreover, the C strlen does not apply to Lua strings because
Lua strings can have embedded zeros.

If you mean strlen from the Lua string library, now called string.len, then
string.len written on top of lua_strlen.

>Does anyone here know that for sure?

By all means, use lua_strlen.
--lhf

Reply | Threaded
Open this post in threaded view
|

garbage collection thoughts... again?!

Thatcher Ulrich
In reply to this post by RLak-2
In case anyone is interested, I've written down my current thoughts
about garbage collection (not necessarily specific to Lua), including
a nice succinct quote by Ken Thompson.  Executive summary:
ref-counting is good.  Here's the longer version:

http://tulrich.com/geekstuff/ref-counting-is-good.txt

I know the Lua authors have said they're working on incremental +
generational collection.  I don't know how far along that work is, but
I'm throwing this into the pot in case it's interesting or helpful.

-Thatcher


Reply | Threaded
Open this post in threaded view
|

garbage collection thoughts... again?!

Basile STARYNKEVITCH
>>>>> "Thatcher" == Thatcher Ulrich <[hidden email]> writes:

    Thatcher> In case anyone is interested, I've written down my
    Thatcher> current thoughts about garbage collection (not
    Thatcher> necessarily specific to Lua), including a nice succinct
    Thatcher> quote by Ken Thompson.  Executive summary: ref-counting
    Thatcher> is good.  Here's the longer version:

    Thatcher> http://tulrich.com/geekstuff/ref-counting-is-good.txt


I didn't found your arguments convincing in the general case (even if
I agree that they are some applications - perhaps some games? - where
refcounting is acceptable, and that coding with refcounting is
*apparently* easy in C). You might also want to study some good
reference books on GC (like Jones&Lins')

The major point against reference counting is circular
references. They are quite common, and actually can appear during
coding (in the sense that you might need them even if at the design
stage you thought that your reference graph is a DAG). Of course,
there are some dirty hacks to refcount circular graphs, but these
remain only dirty hacks which are very difficult to maintain.

I don't think that the Lua mailing list is the good place to discuss
garbage collection in general. There is a mailing list dedicated to
garbage collection which is IMHO a better place to discuss this.

You can glance at the GC list archive on
   http://lists.tunes.org/mailman/listinfo/gclist
and you can subscribe to it by email to gclist-request at
lists.iecc.com

In addition, if you decide, at the design stage, to use a generational
copying GC in C, it is doable, provided you follow some strict coding
guidelines. For example, you could use my Qish runtime (opensource,
LGPL-ed) for that. See http://freshmeat.net/projects/qish or
http://starynkevitch.net/Basile/qishintro.html for more
(unfortunately, Qish is not multi-threaded yet, in the sense that it
does not support several posix thread doing garbage-collected
allocation at once)

I do agree that switching to any moving or copying collector in C once
you have several thousand lines of C code is a nightmare, because such
GC requires by definition strong cooperation with the coder. 

Regards.
-- 

Basile STARYNKEVITCH         http://starynkevitch.net/Basile/ 
email: basile<at>starynkevitch<dot>net 
aliases: basile<at>tunes<dot>org = bstarynk<at>nerim<dot>net
8, rue de la Faïencerie, 92340 Bourg La Reine, France

Reply | Threaded
Open this post in threaded view
|

Re: garbage collection thoughts... again?!

Mark Hamburg-4
In reply to this post by Thatcher Ulrich
I agree that reference counting can work well. I've used it extensively in
some C++ projects and I'm using it while doing Cocoa development. On the
other hand...

* Cycles are more common than you might think. Imagine a view system with
pointers from parents to their children and pointers from children to their
parents. The work around in many systems is to sacrifice safety by choosing
not to count some references. Other safe work arounds increase the
complexity of the implementation.

* The overhead of doing reference counting gets expensive for parameter
passing on the stack. A lot of time can be wasted incrementing and
decrementing reference counts. There are work arounds for this but they are
generally more complicated than simple implementations of reference counting
or they sacrifice safety.

Mark-and-sweep is simple and reliable. Its downside is that it is slow to
collect garbage and it is tricky to make incremental.

That being said, I could see a case being made for investigating reference
counting for Lua as an alternative to an incremental, generational, fully
buzzword compliant garbage collector.

Mark

on 5/28/03 10:47 PM, Thatcher Ulrich at [hidden email] wrote:

> In case anyone is interested, I've written down my current thoughts
> about garbage collection (not necessarily specific to Lua), including
> a nice succinct quote by Ken Thompson.  Executive summary:
> ref-counting is good.  Here's the longer version:
> 
> http://tulrich.com/geekstuff/ref-counting-is-good.txt
> 
> I know the Lua authors have said they're working on incremental +
> generational collection.  I don't know how far along that work is, but
> I'm throwing this into the pot in case it's interesting or helpful.
> 
> -Thatcher
> 


Reply | Threaded
Open this post in threaded view
|

Re: garbage collection thoughts... again?!

Mark Hamburg-4
I agree with the suggestion that a detailed discussion of this is more
appropriate for the GC list. Having chimed in once, however, I'll finish off
my earlier comments by sinning again.

I just went and skimmed Jones & Lins on reference counting. My reaction is
that an implementation of deferred reference counting -- i.e., no counting
references from the stack and use a periodically reconciled zero-count table
-- backed up by a basic mark-and-sweep algorithm could be a good alternative
to incremental garbage collection for Lua provided that cycles are either
rare enough or are mostly confined to long-lasting data structures (i.e, if
one can assume that the objects in cyclic structures probably aren't garbage
anyway).

Mark


pau
Reply | Threaded
Open this post in threaded view
|

Re: garbage collection thoughts... again?!

pau
In reply to this post by Mark Hamburg-4
Well... this may seem redundant but anyway, I am going to repeat
that I've posted a incremental hack on to Lua 4.0 a year ago.

But it wasn't fully successful even though it works to some
extent. some smart people out there could just help to nail
down the final bug!!

Back to the topic of Lua's mark & sweep, my other quick (and 
successful) hack after the above mentioned (unsuccessful) 
incremental GC attempt is to do "mark & sweep + incremental
collect".

The basic idea is that object destruction is usually the most 
expensive part if it involves many GC callback. So what I
did was to chain up garbages instead of destructing them during
the sweep step, and then incrementally clean them up. This
later proved to work very well, and solved all my previous
issues with Lua's long GC halt. 

Interested parties can get the above mentioned two packages 
from http://www.gime.org/twiki/bin/view/Gime/WebDownload

Regards,
.paul.

On Wed, May 28, 2003 at 11:19:23PM -0700, Mark Hamburg wrote:
> I agree that reference counting can work well. I've used it extensively in
> some C++ projects and I'm using it while doing Cocoa development. On the
> other hand...
> 
> * Cycles are more common than you might think. Imagine a view system with
> pointers from parents to their children and pointers from children to their
> parents. The work around in many systems is to sacrifice safety by choosing
> not to count some references. Other safe work arounds increase the
> complexity of the implementation.
> 
> * The overhead of doing reference counting gets expensive for parameter
> passing on the stack. A lot of time can be wasted incrementing and
> decrementing reference counts. There are work arounds for this but they are
> generally more complicated than simple implementations of reference counting
> or they sacrifice safety.
> 
> Mark-and-sweep is simple and reliable. Its downside is that it is slow to
> collect garbage and it is tricky to make incremental.
> 
> That being said, I could see a case being made for investigating reference
> counting for Lua as an alternative to an incremental, generational, fully
> buzzword compliant garbage collector.
> 
> Mark
> 
> on 5/28/03 10:47 PM, Thatcher Ulrich at [hidden email] wrote:
> 
> > In case anyone is interested, I've written down my current thoughts
> > about garbage collection (not necessarily specific to Lua), including
> > a nice succinct quote by Ken Thompson.  Executive summary:
> > ref-counting is good.  Here's the longer version:
> > 
> > http://tulrich.com/geekstuff/ref-counting-is-good.txt
> > 
> > I know the Lua authors have said they're working on incremental +
> > generational collection.  I don't know how far along that work is, but
> > I'm throwing this into the pot in case it's interesting or helpful.
> > 
> > -Thatcher
> > 
> 

Reply | Threaded
Open this post in threaded view
|

Re: garbage collection thoughts... again?!

Peter Hill-2
In reply to this post by Basile STARYNKEVITCH
Basile STARYNKEVITCH:
> I don't think that the Lua mailing list is the good place to discuss
> garbage collection in general.

But a good place where it relates to Lua. Especially since Lua5.1 is planned
to have (so I have heard) incremental, possibly generational GCing.

One thing I think is worth specifying is the goals.

For example: should the GC be completely transparent to the coder (a nice
ideal), or is the coder required to know the process (eg: with reference
counting the programmer can act to minimise circular references).

Despite the recent non-shrinking-table oddity (the programmer having to be
aware of implementation so that they can poke a dummy value into a table to
free up its excess memory) I get the *impression* that Lua is designed to be
quite high level and as independent of internal implementation methods as
possible. If this is so then it weakens the desirabiliy of reference counts
for Lua.

*cheers*
Peter Hill



Reply | Threaded
Open this post in threaded view
|

Re: garbage collection thoughts... again?!

James McCartney
In reply to this post by Mark Hamburg-4

On Wednesday, May 28, 2003, at 11:19 PM, Mark Hamburg wrote:

* Cycles are more common than you might think. Imagine a view system with pointers from parents to their children and pointers from children to their
parents.

or just imagine a doubly linked list.

--
--- james mccartney


Reply | Threaded
Open this post in threaded view
|

Re: garbage collection thoughts... again?!

David Olofson
In reply to this post by Thatcher Ulrich
On Thursday 29 May 2003 07.47, Thatcher Ulrich wrote:
> In case anyone is interested, I've written down my current thoughts
> about garbage collection (not necessarily specific to Lua),
> including a nice succinct quote by Ken Thompson.  Executive
> summary: ref-counting is good.  Here's the longer version:
>
> http://tulrich.com/geekstuff/ref-counting-is-good.txt
>
> I know the Lua authors have said they're working on incremental +
> generational collection.  I don't know how far along that work is,
> but I'm throwing this into the pot in case it's interesting or
> helpful.

Well, I used to think reference counting was the easiest way, but the 
more I think about it, the less interesting it looks, at least for 
hard real time environment.

For example, consider an algorithm that builds big structures (lists, 
trees or whatever), and then throws them away every now and then, as 
they're no longer needed. With plain refcounting, this would result 
in major stalls whenever a large structure is released. So, the 
recursive part that finds all "children" of a dereferenced node has 
to be incremental.

And then there's the circular reference problem, of course.

I'm suspecting that fixing the issues with ref counting results in a 
more complex solution than an incremental GC with similar 
performance.


//David Olofson - Programmer, Composer, Open Source Advocate

.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`-----------------------------------> http://audiality.org -'
   --- http://olofson.net --- http://www.reologica.se ---


Reply | Threaded
Open this post in threaded view
|

Re: garbage collection thoughts... again?!

Thatcher Ulrich
In reply to this post by Mark Hamburg-4
On Wed, 28 May 2003, Mark Hamburg wrote:

> I agree that reference counting can work well. I've used it extensively in
> some C++ projects and I'm using it while doing Cocoa development. On the
> other hand...
>
> * Cycles are more common than you might think. Imagine a view system with
> pointers from parents to their children and pointers from children to their
> parents. The work around in many systems is to sacrifice safety by choosing
> not to count some references. Other safe work arounds increase the
> complexity of the implementation.

Yeah, good points.  At work, with a C++ game engine, we use
ref-counting.  I have done a lot of thinking and reading about how to
do an incremental collector, but haven't come up with anything at all
practical (or cost-effective to write, for that matter).  So we
continue to use ref-counting.  We use the following strategies to deal
with the cycles problem.

* use a weak pointer when you don't "own" the other object.  E.g. a
  child node would have a weak pointer to its parent.  This requires
  some awareness on the part of the programmer of when to use a weak
  pointer, but at least is safe.

* use raw pointers when you don't "own" the object and are sure
  someone else does.  This works OK with many common game-programming
  patterns.  It requires awareness on the part of the programmer, and
  is not very safe.

* instrumentation to detect illegal cycles.  This greatly reduces the
  effort of maintaining the above strategies.

To go out on a limb a bit, to some extent I take issue with the idea
that cycles are very prevalent.  I'm not sure if this is true of
typical Lua programs.  I mean, there are the Perl and Python existence
proofs; two very popular languages that have lots of similarities with
Lua.  It would be interesting to know how big a problem cycles are
perceived to be by the Perl and Python communities.

> * The overhead of doing reference counting gets expensive for parameter
> passing on the stack. A lot of time can be wasted incrementing and
> decrementing reference counts. There are work arounds for this but they are
> generally more complicated than simple implementations of reference counting
> or they sacrifice safety.

We generally do this:

void SomeFunction(const SPtr<SomeObject>& ptr)
{
	// ptr is a reference to an already-existing SPtr<>, so there's
	// no ref inc/dec overhead in the function call binding.
}

This is safe and easy, in my experience.  In any case, most
incremental collectors will need a write-barrier, which in practice is
probably worse than inc/dec of a ref count.

> Mark-and-sweep is simple and reliable. Its downside is that it is slow to
> collect garbage and it is tricky to make incremental.

I think one of the biggest practical benefits of ref-counting, which
none of the other approaches offer, is determinism & predictability.
It's my impression that 90% of the GC questions that show up on the
list are due to problems with the GC not being predictable.  These
questions come from ordinary programmers with straightforward
practical problems and concerns, but the answers, unfortunately, tend
to be pretty subtle and not very comforting.  At least in my opinion.

On the other hand, reference counting is relatively easy to explain
and reason about.  I think that's a tremendous advantage by itself.

For example (using made-up library functions):

    do
      local write_handle = open_file_for_write("somename")
      -- dump some info into write_handle
    end
    -- using ref-counting, we can be 100% confident that the
    -- contents of write_handle have been collected here.  I.e.
    -- that the write buffer has been flushed and the file
    -- handle has been closed.  So now it's safe to do:
    local read_handle = open_file_for_read("somename")
    -- pull in data from read_handle

> That being said, I could see a case being made for investigating reference
> counting for Lua as an alternative to an incremental, generational, fully
> buzzword compliant garbage collector.

Yeah...  I guess if the Lua authors are far along with the
buzzword-compliant collector, then I'm happy.  Otherwise, I think it's
an interesting topic.  Unfortunately I don't have time to experiment
by writing code, but apparently I do have time to rant :)

-Thatcher


Reply | Threaded
Open this post in threaded view
|

Re: garbage collection thoughts... again?!

Thatcher Ulrich
In reply to this post by Peter Hill-2
On Thu, 29 May 2003, Peter Hill wrote:
>
> One thing I think is worth specifying is the goals.
>
> For example: should the GC be completely transparent to the coder (a nice
> ideal), or is the coder required to know the process (eg: with reference
> counting the programmer can act to minimise circular references).
>
> Despite the recent non-shrinking-table oddity (the programmer having to be
> aware of implementation so that they can poke a dummy value into a table to
> free up its excess memory) I get the *impression* that Lua is designed to be
> quite high level and as independent of internal implementation methods as
> possible. If this is so then it weakens the desirabiliy of reference counts
> for Lua.

Yes, I think this is probably the best argument against ref-counting
for Lua.  One of the big advantages of ref-counting is the
predictability, which means programmers may tend to rely on its
behavior, making it impossible to change the GC implementation without
breaking programs.  Likewise ref-counting does sometimes require some
explicit management, which further ties programs to the
implementation.

-Thatcher


Reply | Threaded
Open this post in threaded view
|

Re: garbage collection thoughts... again?!

Thatcher Ulrich
In reply to this post by Basile STARYNKEVITCH
On Thu, 29 May 2003, Basile STARYNKEVITCH wrote:

> >>>>> "Thatcher" == Thatcher Ulrich <[hidden email]> writes:
>
>     Thatcher> In case anyone is interested, I've written down my
>     Thatcher> current thoughts about garbage collection (not
>     Thatcher> necessarily specific to Lua), including a nice succinct
>     Thatcher> quote by Ken Thompson.  Executive summary: ref-counting
>     Thatcher> is good.  Here's the longer version:
>
>     Thatcher> http://tulrich.com/geekstuff/ref-counting-is-good.txt
>
> I didn't found your arguments convincing in the general case (even if
> I agree that they are some applications - perhaps some games? - where
> refcounting is acceptable, and that coding with refcounting is
> *apparently* easy in C). You might also want to study some good
> reference books on GC (like Jones&Lins')

Yes, I've studied that book carefully, and implemented some of the
algorithms in it.

> The major point against reference counting is circular
> references. They are quite common, and actually can appear during
> coding (in the sense that you might need them even if at the design
> stage you thought that your reference graph is a DAG). Of course,
> there are some dirty hacks to refcount circular graphs, but these
> remain only dirty hacks which are very difficult to maintain.

Well -- to some extent I see mark-and-sweep as one such dirty hack.
IMO the *ideal* GC would always collect objects, in a well-defined and
"intuitive" order, the moment they become unreachable.

> You can glance at the GC list archive on
>    http://lists.tunes.org/mailman/listinfo/gclist
> and you can subscribe to it by email to gclist-request at
> lists.iecc.com

Thanks for the reference, I will have a look at the list.

-Thatcher


Reply | Threaded
Open this post in threaded view
|

Re: garbage collection thoughts... again?!

Enrico Colombini
In reply to this post by Thatcher Ulrich
On Thursday 29 May 2003 19:07, Thatcher Ulrich wrote:
> * use a weak pointer when you don't "own" the other object.  E.g. a
>   child node would have a weak pointer to its parent.  This requires
>   some awareness on the part of the programmer of when to use a weak
>   pointer, but at least is safe.

How do you apply this principle to a doubly-linked list, that could be kept in 
existance by a single reference to an unpredictable item (e.g. a reference 
either to the head or to the tail)?

By the way, how does Python fare with doubly-linked lists?

  Enrico

Reply | Threaded
Open this post in threaded view
|

Re: garbage collection thoughts... again?!

James McCartney
In reply to this post by Thatcher Ulrich


On Thursday, May 29, 2003, at 10:30 AM, Thatcher Ulrich wrote:

IMO the *ideal* GC would always collect objects, in a well-defined and
"intuitive" order, the moment they become unreachable.


I've often wondered if it were possible to design a memory such that pointers are not a number but an open circuit. Close the circuit and the power to the objects' "live" bits turns off and they cease to exist. More of a metaphor than something that could be implemented directly. But some way of using hardware circuits to do your pointer tracing at the speed of light.

--
--- james mccartney


Reply | Threaded
Open this post in threaded view
|

Re: garbage collection thoughts... again?!

RLak-2
In reply to this post by Thatcher Ulrich
> I've often wondered if it were possible to design a memory such that
> pointers are not a number but an open circuit. Close the circuit and
> the power to the objects' "live" bits turns off and they cease to
> exist. More of a metaphor than something that could be implemented
> directly. But some way of using hardware circuits to do your pointer
> tracing at the speed of light.

It is certainly possible to design a memory which helps with garbage
collection. It doesn't require much magic: the main thing is to have
a bit which distinguishes pointers from other data; a nice addition
is to be able to do writer barriers (or even read barriers, which are
practical in hardware). Given a hardware write barrier and a little
bit of smarts, you could do most of mark-sweep without touching the
CPU; mass produced "smart memory" would not cost more than 10% more
than existing memory, and possibly less.

If you look at progress in video cards, and think about memory which
would support garbage collection, you would probably rapidly realise
that the only reason we don't have smart memory is that so many
mainstream programmers rile up at the idea of garbage collection.
Or in other words, if most programmers used garbage collection
(with its consequent improvement on stability and resource consumption
to say nothing of reduced buffer overflow errors and general program
simplicity) then the market would be brimming with garbage collection
hardware accelerators; we would have two or three competing "Open"
standards on garbage collection acceleration, and there would be
religious wars about whether Microsoft or GNU had the more open
garbage collection standard.

Unfortunately, that is not the world we live in. But it could be.

How's that for a rant, Thatcher?

Rici

Reply | Threaded
Open this post in threaded view
|

Re: garbage collection thoughts... again?!

Thatcher Ulrich
In reply to this post by Enrico Colombini
On Thu, 29 May 2003, Enrico Colombini wrote:

> On Thursday 29 May 2003 19:07, Thatcher Ulrich wrote:
> > * use a weak pointer when you don't "own" the other object.  E.g. a
> >   child node would have a weak pointer to its parent.  This requires
> >   some awareness on the part of the programmer of when to use a weak
> >   pointer, but at least is safe.
>
> How do you apply this principle to a doubly-linked list, that could
> be kept in existance by a single reference to an unpredictable item
> (e.g. a reference either to the head or to the tail)?

I guess it might look like this:

struct element {
	// some data
	smart_ptr<element>	next;
	weak_ptr<element>	prev;
};

And, the list itself must be terminated by NULL, or be explicitly
broken when you want to collect it.

(In practice, we also use a lot of raw pointers in cases where we care
about the efficiency and we know it's safe.)

> By the way, how does Python fare with doubly-linked lists?

Not sure.  I did discover that the mailing list Basile suggested has a
good thread on reference-counting, starting with this post:

http://lists.tunes.org/archives/gclist/2002-August/002341.html

I also discovered this amusing and typically opinionated posting by
Linus Torvalds on the gcc mailing list:

http://gcc.gnu.org/ml/gcc/2002-08/msg00544.html

I haven't mined the Python or Perl lists for relevant threads, but if
somebody else has, please post links.

-Thatcher


Reply | Threaded
Open this post in threaded view
|

Re: garbage collection thoughts... again?!

Thatcher Ulrich
In reply to this post by RLak-2
On Thu, 29 May 2003 [hidden email] wrote:
>
> It is certainly possible to design a memory which helps with garbage
> collection. It doesn't require much magic: the main thing is to have
> a bit which distinguishes pointers from other data; a nice addition
> is to be able to do writer barriers (or even read barriers, which are
> practical in hardware). Given a hardware write barrier and a little
> bit of smarts, you could do most of mark-sweep without touching the
> CPU; mass produced "smart memory" would not cost more than 10% more
> than existing memory, and possibly less.
>
> If you look at progress in video cards, and think about memory which
> would support garbage collection, you would probably rapidly realise
> that the only reason we don't have smart memory is that so many
> mainstream programmers rile up at the idea of garbage collection.
> Or in other words, if most programmers used garbage collection
> (with its consequent improvement on stability and resource consumption
> to say nothing of reduced buffer overflow errors and general program
> simplicity) then the market would be brimming with garbage collection
> hardware accelerators; we would have two or three competing "Open"
> standards on garbage collection acceleration, and there would be
> religious wars about whether Microsoft or GNU had the more open
> garbage collection standard.
>
> Unfortunately, that is not the world we live in. But it could be.
>
> How's that for a rant, Thatcher?

Very nice :)

I think the big difference between video cards and GC memory is that
there is a relatively easy 10x+ *overall* application performance gain
from using 3D rasterization hardware, while the overall app
performance gains from GC hardware would be 2x or less.  I.e. even if
special GC memory made mem management totally free, most apps don't
spend 90+% of their time doing mem management.  Whereas in the days
when we used software rendering in 3D games, we *did* spend 90+% of
our time pushing pixels.

-Thatcher


123