(22/10)[08:36:11] <prunedtree> also, something that I didn't mention

(22/10)[08:39:07] <prunedtree> for subjective dispatch, I think a good way to optimize is to customize any sufficiently low level method (even non-generic ones) to the 'VM sealed' access

(22/10)[08:39:31] <prunedtree> If you remember the concept, it's very similar to sealing in dylan, but with dynamic extent

(22/10)[08:39:59] <prunedtree> so we can seal any low level stuff even if it use any generic library (like sequences) without the need to seal the library itself

(22/10)[08:40:48] jeffz` is now known as jeffz

(22/10)[08:42:03] <prunedtree> in essence, I don't think it would require much complexity (to optimize the most generic case, that is the 'VM sealed' and 'unrestricted' access controls)

(22/10)[08:43:11] <prunedtree> it would allow anyone to add subjective dispatch on, say, +, so that in a dynamic context all additions are logged

(22/10)[08:43:31] <prunedtree> without hurting the performance of any method that is in the two most common cases

(22/10)[08:45:30] <prunedtree> In essence it doesn't matter if access control is quite expensive when you use it. it's a very very usefull semantic for hacks (like trying to make stuff work together quickly), debugging and sandboxing

(22/10)[08:46:28] <prunedtree> of course in the 'VM sealed' case we would expect it to be extremely fast. but that would be a very large subset of the 'unrestricted' case (all primitives and base datastructures would be available)

(22/10)[08:47:26] <prunedtree> in fact, the 'sealed' mode might be applicable to more areas than metacircularity, like speed critical sections

(22/10)[08:48:28] <prunedtree> I believe dynamic extent gives you a much more pratical sealing than class/word sealing

(22/10)[08:48:30] <slava> so klein was written in a subset of self?

(22/10)[08:48:39] <prunedtree> nope. full self lol

(22/10)[08:48:47] <slava> how did that work

(22/10)[08:49:05] <prunedtree> how would it not work ? any system can be made metacircular

(22/10)[08:49:42] <prunedtree> the only reason I want sealing with dynamic extent is for performance (in order to make a metacircular Factor VM something practical, not academic) not correctness

(22/10)[08:50:31] <prunedtree> the additional bonus is that it's a great help to avoid unintended performance regressions or bugs

(22/10)[08:52:05] <prunedtree> slava : one you have a metacircular compiler to native code you have the most important part of the puzzle

(22/10)[08:52:16] <prunedtree> in fact most of Klein was a Self compiler in Self

(22/10)[08:53:22] <prunedtree> the most tricky part for HLLs is the 'runtime'

(22/10)[08:53:48] <prunedtree> for Self, there are three parts: primitives, dispatch, GC (tell me if I forget something)

(22/10)[08:54:27] <prunedtree> the most low level primitives (intrinsics) produce native code in the compiler. all other ones can be written in the HLL

(22/10)[08:55:14] <prunedtree> dispatch simply needs to be written in a way that doesn't do any dispatching (to avoid infinite recursion)

(22/10)[08:55:44] <prunedtree> ironically, metacircularity is all about breaking the cycle :)

(22/10)[08:56:29] <prunedtree> dispatch is probably the least HLL piece of code of the system (in Self). but it's very very short so it's not really a problem

(22/10)[08:57:45] <prunedtree> in GC you have two issues: reclaiming more garbage that you create (for correctness, scavenging trivially solves this - it leaves you with potentially horrible performance though)

(22/10)[08:59:05] <prunedtree> and be carefull when you GC the stuff the GC touches. this is actually trivial when you write a concurrent GC, as you have to be carefull about anything you touch (the GC thread can be considered a mutator like all others)

(22/10)[09:01:11] <prunedtree> what is interressing (to me at least) is that it's clear that it's not as difficult to write a high performance metacircular VM. I will admit it doesn't give you suddenly immense comfort vs C:

(22/10)[09:01:28] <slava> prunedtree: you should put this type of stuff in the wiki

This revision created on Wed, 22 Oct 2008 07:12:51 by prunedtree