On 10 Jun 2014, at 07:02, Mark van Gulik <[email protected]> wrote:
> So... by my calculations that's 160 bytes for each optional. that’s too much bytes for me to like, but i appreciate your honest calculations! > But memory is cheap... at least main memory. My VIC-20 had 4KB of program > RAM. My current laptop has 4GB, or a million times as much, and cost about > 4× as much. The Consumer Price Index calculator says my laptop was only > about twice as expensive after inflation. A quick check shows 4GB DDR chips > for $25, so 160 bytes costs, let's see... carry the three... NOTHING. > That's not exactly true, but it's so close it can't *possibly* matter right > now. However, multiple indirections (two per object traversed due to the > Java Arrays), plus the extra load on L1/L2/L3 caches means the existing > mechanism really does have a cost that will matter to us at some point. your “moore’s law” arguments resonate with me personally. but the thing is that avail has to compete with other languages. a *fundamental* memory overhead factor of 2, one can overcome, but 3 times or more might shy people away from avail. > The near-term plan for the jitter already includes using escape analysis to > rewrite uses of int-sized integers, closures, and continuations. Extending > that to objects should be feasible. it’s good to know that avail doesn’t fundamentally prohibit such optimisations. >> 2) is possible to rewrite “optional” without using tuples, taking less >> memory? > > One could have "optional" be an explicit subclass of object, then introduce > "present" as an *implicit* subclass of optional, introducing a new field only > within "present" to hold the value. Is that what you're looking for? indeed, but such construct would still consume more memory than, say, the poj version of optional. > Monads might be possible this way as well, although having to use them feels > like an exercise in self-mutilation – chopping off all four limbs and half > your brain just so you can prove that it's possible to do imperative > programming, badly, inside functional programming... thereby trivially > invalidating almost every argument about functional programming being > strictly safer than imperative. monads, i also hate them passionately :) >> 4) can tuple strengthening strategies be re-used for other classes (such as >> “optional”) without incorporating the tuple as a field? > > A guillemet group can already be tied to an argument of type <cheese…|0..1>, > which can be accessed via "x[1] else [tofu]". Technically, the tuple still > has to be constructed, but when we start inlining non-primitives (hopefully > in a few months), the intermediate tuples will never actually have to get > built. But that's just transient objects. The storage doesn't really matter > for objects that'll only last a microsecond. If we really have a *lot* of > optional values that have to reside in memory simultaneously, they might best > be represented by tuple types like <cheese…|0..1>. Or some sort of explicit > optional primitive type with its own family of descriptors. now i wonder what’s the memory footprint of a single element tuple? don’t get me wrong: i like avail’s strong stance towards (runtime) types. because by doing so, avail blurs the difference between compile and runtime - which is very powerful. but what are the true benefits to keep hold of types at runtime? avail usually doesn’t erase types, but at what (memory) cost? my guess is: to enable the runtime reflection/introspection of objects, and their genuine types and thus intent. > Over the last few months Todd has proposed a reasonably safe version of the > null concept that’s very interesting. explicit null typing is the holy grail of safety, etc. >> my guess is that using a tuple as a field is (currently) wasteful, but that >> it is the only easy way to strengthen “optional” via tuple strengthening. > > The tuple type above should be sufficient. i ask again: what’s the memory footprint of a single element tuple? if it is too big, i would suggest adding an “optional” primitive to the vm, as a viable option :) cheers, Robbert.
