Browse thread
Hash clash in polymorphic variants
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| From: | Jacques Garrigue <garrigue@m...> |
| Subject: | Re: [Caml-list] Re: Hash clash in polymorphic variants |
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