Re: [Caml-list] Re: Hash clash in polymorphic variants

[Jacques Garrigue <garrigue@math.nagoya-u.ac.jp>]

From: Jon Harrop <jon@ffconsultancy.com>
> On Tuesday 15 January 2008 03:36:21 Jacques Garrigue wrote:
> > Unfortunately, this would make marshalling between different programs
> > much more complicated...
> 
> Do people marshal polymorphic variants between different programs?

Do people marshal data between different programs (or different
versions of the same program)?

> For 3-16 tags on AMD64, jump tables (ordinary variants) are 2x slower than 
> decision trees (polymorphic variants) when branches are taken at random. 
> However, jump tables are consistently up to 2x faster when a single branch is 
> taken repeatedly. So caching jump tables is more effective at run-time 
> optimizing pattern matches over ordinary variants than branch prediction is 
> at optimizing decision trees for pattern matches over polymorphic variants.
> 
> So the advantage of a decision tree is probably insignificant on real code 
> because it will lie between these two extremes.

Since the goal was never to be faster than ordinary variants, but just
obtain comparable speed, this seems good :-)

> > Now concerning the risks of name conflicts. The main point of
> > polymorphic variants is that there is only a conflict if the two tags
> > appear in the same type. And logically the type should stay small.
> > If you want to put all GLenum's inside the same type, then you may
> > well end up with conflicts. But what LablGL shows is that in practice
> > only a small number of tags are used together.
> 
> Can LablGL's design support OpenGL extensions?

I'm not sure what this means.
Since LablGL was coded by hand, adding extensions would mean modifying
it.
One might want to add a way to detect whether an extension is
available or not, but making it static does not seem a good idea: one
wouldn't even be able to compile code using an extension that is not
available.
Also, one might want to make code generation automatic, particularly
for C wrappers, to allow adding cases to functions easily. This should
be doable, but there is no infrastructure for that currently
(using CPP macros was simpler to start with...)

Jacques Garrigue