On 11-Aug-2000, Manuel M. T. Chakravarty <[EMAIL PROTECTED]> wrote:
> Ketil Malde <[EMAIL PROTECTED]> wrote,
>
> > "Manuel M. T. Chakravarty" <[EMAIL PROTECTED]> writes:
> >
> > > A good analysis of were C# fits re Java and C++ is at
> > >
> > > http://slashdot.org/article.pl?sid=00/08/09/1612254&mode=thread
> >
> > Wherein we read:
> >
> > > One new feature that I mentioned already was that of copy-by-value
> > > objects. This seemingly small improvement is a potentially huge
> > > performance saver!
This analysis actually misses the main point.
Performance is not the main reason for wanting value types.
The main reason for wanting value types is that there are many
types which are better modelled as values rather than as objects.
Of all people, functional programmers should surely be well aware of this!
Note that Eiffel, which certainly tends towards purism in its OOP zeal,
originally did without value types, but the Eiffel community found that
this did cause problems and so since Eiffel 3.0, Eiffel has had value
types (though they call them "Expanded Objects" -- I guess so that they
can still call the language "purely" object oriented ;-).
For similar reasons, Sather also distinguishes between value types
and object types. Likewise I believe that a request for value types
is high up on the Java extensions list. Complex numbers, for instance,
are an example of a type which is much better modelled as a value type
than as an object type.
>From a modelling perspective, the most important difference between
a value type and an object type is not that an object type is allocated
on the heap, but that an object type has an identity.
However, that said, there are cases where value types can give
significant performance improvements over object types.
> > > With C++, one is regularly tempted to describe the
> > > simplest constructs as classes, and in so doing make it safer and
> > > simpler to use them. For example, a phone directory program might
> > > define a phone record as a class, and would maintain one PhoneRecord
> > > object per actual record. In Java, each and every one of those objects
> > > would be garbage collected!
> >
> > Now, is this really such a big problem? Is it a problem because of
> > Java's mark-and-sweep, and if so, couldn't you apply a better GC?
>
> That's exactly what I thought. I mean why don't they read a
> couple of research papers?
Using a better garbage collector is certainly a good idea.
However, there is a limit to how good you can make the garbage collector.
Often it is much more cost effective to put work into reducing the
program's allocation rate rather than trying to make the garbage
collector faster.
>From what I have heard, it sounds like MS have put quite a bit of work
into their garbage collector. They use a generational mark-compact
collector, with I think three generations, the first of which is sized
to fit in the L0 (or was it L1?) cache, and they have several
different versions for different situations, including a concurrent
one for interactive use. They claim that in situations where you are
frequently allocating small objects, the overhead of allocation is
about 6 cycles per object (this of course does not include the
collection cost), and they claim that in such situations the amortized
overall cost of allocation plus collection is less than 50 cycles per
object. These claims have not (to my knowledge) been independently
verified, and personally I am somewhat sceptical, particular about
the extent to which these figures, which are no doubt the best case
figures, will extrapolate to real programs. However, I think it is
fair to say that Microsoft have done their homework on this issue.
I have not yet done any benchmarking of their GC yet. The reason for
that is that currently the Mercury to IL code generator generates code
which does many unnecessary allocations which we know how to eliminate,
so benchmarking things at this point would give us very little in the way
of of useful comparisons.
--
Fergus Henderson <[EMAIL PROTECTED]> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger [EMAIL PROTECTED] | -- the last words of T. S. Garp.
