I've been working on filling the missing pieces of the object
representation. I would like to clarify with you the following points: 1. Optimizations supported by the baseline compiler (constant propagation, function inlining, etc.)
I would suggest not focusing on optimizations for the first version of our compiler. However, eventually, our baseline compiler should support constant propagation as well as peephole optimizations of x86 code. Probably not inlining of user functions though, as that is non-trivial in JavaScript and requires sophisticated analyses. We should, however, be able to inline some of our code, which we can guarantee will be called.
Boundary between Javascript and C code for the manipulation of the
object representation
I would like it if we could do all manipulations of the object representation using the inline IR, eventually. For the moment being, if we have a GC written in C, however, it will need to understand some aspects of the representation.
Performance and Extensibility (especially for an eventual
specialization of object representations)
If we have a good reified API for interacting with object representations, this makes it easier to have multiple representations and switch between them later. If this is done using the inline IR, it could actually improve the performance.
Would we have time to meet tomorrow to discuss it? I am available anytime during the day. Meeting at 2166 could be fun!
I would be available in the afternoon tomorrow, but are we not meeting on Wednesday anyway?
- Maxime
Erick Lavoie wrote:
I've been working on filling the missing pieces of the object representation. I would like to clarify with you the following points:
- Optimizations supported by the baseline compiler (constant
propagation, function inlining, etc.) 2. Performance and Extensibility (especially for an eventual specialization of object representations) 3. Boundary between Javascript and C code for the manipulation of the object representation
Would we have time to meet tomorrow to discuss it? I am available anytime during the day. Meeting at 2166 could be fun!
Erick
Le 10-06-21 17:06 , Maxime Chevalier-Boisvert a écrit :
My intuition is that objects with few properties are accessed often.
Can we verify this with our tracing framework?
Sure. I might have time to look at that tomorrow.
Initially a linear search would be done, and when there are greater
than "Pmax" properties, then a hash-table would be used. We just have to arrange for the inlined "linear search" algorithm to immediately fail, and fallback to the hash-table lookup done in the out-of-line handler.
I have my doubts that it's worth it to try very hard to optimize this, as hidden classes would probably be faster... But consider this:
If objects contain an "inline" table with a small, constant number of slots, say K = 7 or K = 11, we could use this for objects with few properties, either for linear search or as a hash table. Furthermore, if we used it as a hash table, the actual index after hashing of the property name could be pre-computed in most cases (startIndex = hash(propName) % K). Meaning the lookup would always hopefully begin at the "right" place.
- Maxime
Tachyon-list mailing list Tachyon-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/tachyon-list
Tachyon-list mailing list Tachyon-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/tachyon-list