Re: why malloc/free instead of GC?

>>>>> "Fergus" == Fergus Henderson <[email protected]> writes:

    Fergus> On 18-Feb-2003, Basile STARYNKEVITCH
    Fergus> <[email protected]> wrote:
    >> For completeness and shameless plug I also hacked the same
    >> (useless) program to use my Qish generational copying GC - see
    >> http://freshmeat.net/projects/qish for details on Qish.

    Fergus> IIRC, qish depends on GCC's `-fvolatile' and
    Fergus> `-fvolatile-globals' options, right?

Not exactly (see below). The posted code was compiled with (assuming
Qish is in ../Qish):

gcc -O -I../Qish/include -DUSEQISH essm.c -o essm_qish -L../Qish/lib \
 -lqish -ldl

For information, gcc -O3 also works and gives user=7.352e-07
system=2.272e-07 seconds per iteration, while the binary compiled with
-O gives user=7.525e-07 system=2.384e-07 seconds per iteration and the
binary compiled with -O0 [no optimisation at all] gives
user=8.243e-07 system=2.249e-07 seconds per iteration.


    Fergus> Firstly, because of this, it's not really fair to compare
    Fergus> just GC times, since qish will have a significant overhead
    Fergus> on code which does not do any allocation at all. 

I agree with the comment, but Qish does not require actually
-fvolatile or -fvolatile-globals [even if I wrote that in the
documentation; but I checked since the ISO C99 spec about
volatile]. It does require that pointer arguments are declared
volatile, and that local pointer variables are (like in the example)
in a volatile structure initialized to 0:

	volatile struct	{
	  struct obj_st *ptr;
	}	_locals_ =	{0};

    Fergus>  So
    Fergus> benchmarks which do allocation but have little or no
    Fergus> computation (referencing global variables, dereferencing
    Fergus> pointers, etc.) will unfairly advantage qish.

I agree with the remark above. But since -fvolatile is not required,
there is no advantage to Qish here, and even a disadvantage to Qish
(because it requires some careful coding conventions, and because the
mandatory BEGIN_LOCAL_FRAME*/EXIT_FRAME macros cost a few machine
instructions each in every call involving pointers).

    Fergus> Secondly, you may be interested to know that these options
    Fergus> (or at least `-fvolatile-globals' -- I'm not 100% sure
    Fergus> about `-fvolatile') have been removed from the CVS sources
    Fergus> for GCC, because they were broken in GCC versions 3.0 and
    Fergus> beyond.  So this may cause trouble for Qish.

I don't need them. I just need a compiler respecting the volatile
keyword, and a coder which carefully use them:

A.  in pointer arguments:

    foo(struct yourstruct_st* volatile p)

B.  in local pointers, like above.
 
BTW I actually tested some qish code with TinyCC (see www.tinycc.org).

Actually, I wrote that Qish needed -fvolatile before understanding
exactly what the volatile keyword means in C99. This was my
mistake. Qish don't need -fvolatile, but do need careful use of
volatile keyword (see points A,B above) and requires some specific
coding style (notably frame entering & exiting macros, and write
barrier macros).


And yes, Qish does have an overhead, because even functions which only
passes GC-ed pointers [to allocating functions] need to follow coding
conventions (in particular the BEGIN_LOCAL_FRAME*/EXIT_FRAME macros)
even if they don't do allocation themselves. so if f(p) calls g(p,q)
which calls h(p,r) which allocate pointers [where p,q,r are GC-ed
pointers arguments declared volatile] , all the f, g, and h functions
need the BEGIN_LOCAL_FRAME*/EXIT_FRAME macros pairs even if only h
allocate pointers.

Above all, Hans is right to recall that Qish is not multithreaded and
won't run in a multithreaded application. 
-- 

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