I thought about tricks like this, but (a) a sufficiently smart compiler should
*not* be doing this automatically, as it makes certain common operations like
fetching the pointer more expensive as well as violating the principle of least
surprise when it comes to machine representation, and (b) does this sort of
hack really result in a cleaner design than having some simple language
extensions? Mind you, I'm all about ways to simplify Rust, but sometimes the
simplest solution is to build stuff into the language.
On March 11, 2014 7:39:30 PM PDT, Maciej Piechotka <uzytkown...@gmail.com>
wrote:
>On Tue, 2014-03-11 at 14:18 -0700, Patrick Walton wrote:
>> On 3/11/14 2:15 PM, Maciej Piechotka wrote:
>> > Could you elaborate on DOM? I saw it referred a few times but I
>haven't
>> > seen any details. I wrote simple bindings to libxml2 dom
>> > (https://github.com/uzytkownik/xml-rs - warning - I wrote it while
>I was
>> > learning ruby) and I don't think there was a problem of OO - main
>> > problem was mapping libxml memory management and rust's one [I gave
>up
>> > with namespaces but with native rust dom implementation it would be
>> > possible to solve in nicer way]. Of course - I might've been at too
>> > early stage.
>>
>> You need:
>>
>> 1. One-word pointers to each DOM node, not two. Every DOM node has 5
>> pointers inside (parent, first child, last child, next sibling,
>previous
>> sibling). Using trait objects would 10 words, not 5 words, and would
>> constitute a large memory regression over current browser engines.
>>
>> 2. Access to fields common to every instance of a trait without
>virtual
>> dispatch. Otherwise the browser will be at a significant performance
>> disadvantage relative to other engines.
>>
>> 3. Downcasting and upcasting.
>>
>> 4. Inheritance with the prefix property, to allow for (2).
>>
>> If anyone has alternative proposals that handle these constraints
>that
>> are more orthogonal and are pleasant to use, then I'm happy to hear
>> them. I'm just saying that dismissing the feature out of hand is not
>> productive.
>>
>> Patrick
>>
>>
>
>Ok. I see where my misunderstanding was - I was thinking about DOM
>implementation in Ruby for Ruby while you (Mozilla) were talking about
>implementation in Ruby for JavaScript.
>
>Please feel free to ignore next paragraph as I haven't given it much
>though but my guess would be that it would be possible to avoid the
>penalty by enum + alignment + smart compiler. As data have 6 words + in
>your scheme (5 described + vtable) the 4 bit alignment (assuming 32+
>bit
>platform) should not cause much memory waste. This allows for using the
>'wasted' bits for other purposes (the trick is used in, for example,
>lock-free structures) - for example:
>
>enum ElementChild<'r> {
> ElementChildElement(&'r Element),
> ElementChildComment(&'r Comment),
>}
>
>Could be represented as pointer with last bit specifying if it's
>element
>or comment - similar to Option<&T> optimization. The lookup should
>behave much nicer with respect to branch prediction (plus) but getting
>pointer is more complicated (minus) and possibly longer code instead of
>jump (minus). If data alignes the compiler should be able to optimize
>the jumps if it notices that all jumps lead to the same pointer
>arithmetic. I'm not sure about handles from JS but I don't think there
>is more then 16 choices for types of parent/child/sibling for any node
>so it should be achivable - on language side it would just be enum +
>pointer (+ specification of alignment as attribute?).
>
>That said a) I have done no measurements/benchmarks so my intuition is
>likely to be wrong b) should in above paragraph means 'it looks that it
>could work after 5s thought' and c) I'm not a Rust designer and I don't
>pay for nor contribute so I don't expect that I should have anything
>resembling last word.
>
>Best regards
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Rust-dev mailing list
>Rust-dev@mozilla.org
>https://mail.mozilla.org/listinfo/rust-dev
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity._______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
