Guillermo Adrián Molina writes: > Hi to all, I am a Smalltak VM enthusiast. I found this list an interesting > reading. But I was wandering a few things. If you could rewrite the > Squeak's object memory from scratch, in order to simplify and accelerate > exupery, what would you do?
My list would be: * Integer tags as 0. * Use a card marking memory barrier * Get rid of short classes to simplify type checking. * Store the size of variable objects in a word at a known position not in one of 2 locations. This is to simplify range checking. * A much faster GC which may be needed once Exupery starts providing a good general speed improvement. But Exupery works with Squeak's current object memory, any changes to the object memory would involve making similar changes to Exupery. I'm not sure how much value changing integer tagging would bring. "a := a + 1" is now compiled to the same instruction sequence as a 0 tag would use. There is a single instruction overhead for tagging with 1 not 0 in most cases. The trick is to realise that if you don't detag one of your arguments you will not need to retag the result and that constants can be tag manipulated at compile time. I'm happy with boxed floats. Personally I think tagged floats are likely to be slower than a good optimizing boxed float solution. I'd rather have floats stored in float arrays then optimism away the boxing and deboxing. The problem with tagged floats is you need to detag them and that's much more expensive than tag manipulation on integers which is annoying as modern hardware has about the same floating point bandwidth as integer bandwidth. Booleans as proper objects is fine. There is one true object and one false object so there's no need to create an object which is the expensive part. And again, it's easy to remove intermediate boolean values from the code. I wrote an article for my Smalltalk Solutions presentation that covers what Exupery currently does and analyses the code it produces which should be worthwhile reading if you want to figure out out expensive the operations are. http://goran.krampe.se/exuperyDesign.pdf May I ask what you're trying to do? Practically, it's hard to evaluate how important any object memory changes will be to Exupery because often it's possible to optimism away the overhead in many cases. Until Exupery has a high quality optimizer it's impossible to do experiments to see what overhead is left. Bryce _______________________________________________ Exupery mailing list [email protected] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery
