Tachyon-list Mars 2011

tachyon-list@iro.umontreal.ca

4 participants
45 discussions

Démarrer une nNouvelle discussion

List of ECMAScript engines
by Marc Feeley 10 Mar '11

10 Mar '11

http://en.wikipedia.org/wiki/List_of_ECMAScript_engines Someone should add Tachyon to the list... Marc

2 1

Boostrap 32 bits on baro
by Erick Lavoie 05 Mar '11

05 Mar '11

The librairies to compile d8 have been added by Claude (I would not have expected this to be done on a saturday afternoon ;-) ). The bootstrap can be done in 8m 54s on baro, compared to 12m 26s on my machine. Erick

1 0

Bootstrapping on 64 bits
by Erick Lavoie 05 Mar '11

05 Mar '11

Bootstrapping on 64 bits won't be trivial as I've found two issues today: 1. It is not possible to do a call/jump with a 64 bits relative offset. It breaks the way we implemented static calls so far (by computing an offset between the destination address and the call site at linking time). We need this to call malloc/free/exit/puts because they are mapped too far in the address space of the process. Maxime suggested that we always do a move in a register before the call/jump. This way we can move a 64 bits absolute address into a 64 bits register, avoiding the relative offset problem. The function call protocol needs to be changed to support this. 2. We assumed sizeof(int) == sizeof(void *) in the d8 extensions we wrote and in the Tachyon C proxy generation. We will need to change it to adequately support 64 bits. At this point, I don't know if those are the only issues we will encounter to allow bootstrapping on 64 bits in addition to debugging latent bugs. It might be faster to go the GC way and come back after for 64 bits support. What do you guys think? Erick

4 5

Compiling v8 on baro
by Erick Lavoie 04 Mar '11

04 Mar '11

Has someone been able to compile v8 on baro? While building from source I get: In file included from /usr/include/features.h:359, from /usr/include/stdio.h:28, from src/../include/v8stdint.h:33, from src/../include/v8.h:41, from src/v8.h:55, from src/accessors.cc:28: /usr/include/gnu/stubs.h:7:27: error: gnu/stubs-32.h: No such file or directory Do we have permissions to add missing packages on baro? Erick

2 2

GC Object Headers, Field Alignment
by chevalma＠iro.umontreal.ca 03 Mar '11

03 Mar '11

I have been wondering if we could save a little space by only including object headers on some objects but not all. If we can refactor to eliminate the ref type, then all object references will be boxed. Right now, some heap-allocated objects have reserved tag bits (eg: floats, strings, objects, functions, arrays), and others do not (e.g.: the hash consing table). The objects that don't have tags of their own all share the "other" tag. If all we need a header for is for the GC to identify what kind of object it's dealing with, then perhaps we only need a header for the objects that share the "other" tag. Other object kinds could be identifier through the tag bits. This would allow small objects like floats to be heap-allocated without requiring a tag. Marc, you mentioned the need for a size field in objects as well. I think we may be able to only require objects that have a variable size to have such a field. Strings, for example, can have a variable length, and contain a field to say how many characters they contain, from which the total object size in bytes can be computed. Objects like heap-allocated floats, however, have a fixed size determined solely by the object type. So, the real question is, do we need a header for any other purpose besides identifying the object type? If we need a certain amount of status bits on all objects, for example, then we may want to include the header on all objects, but if not, then this optimization could be implemented without much difficulty. A last issue I would like to know your opinion about is the alignment of fields within objects. Do you think that fields within objects should be aligned to pointer size boundaries? I believe on 32 bit MIPS you can only load at 4 byte boundaries. Does this matter on x86 32-64? For example, if an object header on a 64 bit machine is 32 bits, should there be 32 bits of padding between it and the next field, assuming that next field is 64 bits in size? - Maxime

2 2

New time and space profile
by Marc Feeley 03 Mar '11

03 Mar '11

I have improved the reporting of the time and space profile to display the information hierarchically and with the percentage of the total time and space used. Here is the report. According to this new report, the "IR to ASM translation" and "IR lowering" each account for 1/4 of the total memory allocations. Please look into optimizing these phases first. Note that even if these two are improved to take *no* space, then it would only cut down total memory usage by a factor of 2 (which would be good, but we would still be in the same order of magnitude of memory use). Execution time is another story... it should be easier to get more than a factor of 2 acceleration. Marc ******************** Performance report Compiling runtime: 4.98013916015625 s, 335.53583908081055 MB allocated time=68% alloc=63% -- Machine code generation time=19% alloc=25% -- IR to ASM translation time=18% alloc=9% -- Linear scan time=13% alloc=5% -- Resolution time=5% alloc=7% -- Computing live intervals time=4% alloc=4% -- Assembly time=1% alloc=2% -- Operand assignment time=1% alloc=3% -- Number instructions time=0% alloc=1% -- Computing fixed intervals time=0% alloc=0% -- Order blocks time=21% alloc=25% -- IR lowering time=5% alloc=6% -- IR generation time=3% alloc=2% -- Parsing time=1% alloc=1% -- Machine code linking Compiling stdlib: 6.415508056640625 s, 335.77566146850586 MB allocated time=79% alloc=70% -- Machine code generation time=27% alloc=10% -- Linear scan time=20% alloc=6% -- Resolution time=15% alloc=28% -- IR to ASM translation time=4% alloc=7% -- Computing live intervals time=4% alloc=5% -- Assembly time=2% alloc=3% -- Number instructions time=2% alloc=2% -- Operand assignment time=0% alloc=1% -- Computing fixed intervals time=0% alloc=0% -- Order blocks time=16% alloc=23% -- IR lowering time=2% alloc=3% -- IR generation time=1% alloc=2% -- Machine code linking time=0% alloc=0% -- Parsing Compiling Tachyon: 533.329 s, 10945.522819519043 MB allocated time=88% alloc=67% -- Machine code generation time=53% alloc=11% -- Linear scan time=17% alloc=4% -- Resolution time=8% alloc=28% -- IR to ASM translation time=3% alloc=5% -- Assembly time=2% alloc=7% -- Computing live intervals time=1% alloc=2% -- Operand assignment time=0% alloc=1% -- Computing fixed intervals time=0% alloc=2% -- Number instructions time=0% alloc=0% -- Order blocks time=9% alloc=23% -- IR lowering time=1% alloc=5% -- IR generation time=0% alloc=2% -- Machine code linking time=0% alloc=0% -- Parsing ********************

3 7

ASCII Art
by Marc Feeley 03 Mar '11

03 Mar '11

Nice ASCII Art Erick! Marc in ir-to-asm.js... // FIXME: ugly code below to temporarily deal with x86 gayness // without help from the register allocator // ______ ________ // ___ ___/ __ \ / _____/ ________ _____ ___ // \ \/ /> </ __ \ / ___/ | \ \/ / // > </ -- \ |__\ \ \___ \| | /> < // /__/\_ \______ /\_____ / /____ >____//__/\_ \ // \/ \/ \/ \/ \/

2 1

Bootstrapping Gambit on baro
by Marc Feeley 03 Mar '11

03 Mar '11

For kicks, and as a benchmark for the eventual bootstrap of Tachyon, I bootstrapped Gambit-C v4.6.0 on baro. Here are the details... I used a "make -j 10" (10-way parallel make). It took 72 seconds in all to compile 45 KLOC (C code of the runtime), 83 KLOC (Scheme code of the library, interpreter and compiler) and the C code generated by Gambit when compiling the Scheme code (676 KLOC of C). A simple "make" (just one processor used) took 296 seconds, about a factor of 4 greater. Most of the time is spent in the C compilation by gcc (195 seconds, or 66%). It would be nice to get Tachyon to compile in less than a minute on a single processor. This seems to be a reasonable target for the amount of JavaScript code in Tachyon. Marc

1 0

Time and space usage
by Marc Feeley 03 Mar '11

03 Mar '11

I modified V8 (specifically src/heap.cc) to keep track of the total memory allocation, and added JS callable primitives to get the current time and space usage. Here's the time and space taken by each compilation phase, for compiling the runtime, stdlib, and Tachyon itself: runtime: ========== Parsing (0.14 s, 8.98 MB allocated) ========== IR generation (0.24 s, 22.95 MB allocated) ========== IR lowering (1.02 s, 84.80 MB allocated) ========== Machine code generation (3.33 s, 213.03 MB allocated) ========== Machine code linking (0.05 s, 5.19 MB allocated) stdlib: ========== Parsing (0.08 s, 2.94 MB allocated) ========== IR generation (0.10 s, 13.05 MB allocated) ========== IR lowering (1.02 s, 77.43 MB allocated) ========== Machine code generation (5.02 s, 233.63 MB allocated) ========== Machine code linking (0.09 s, 7.38 MB allocated) Tachyon compiler: ========== Parsing (1.04 s, 88.50 MB allocated) ========== IR generation (6.18 s, 571.99 MB allocated) ========== IR lowering (47.01 s, 2585.86 MB allocated) ========== Machine code generation (460.40 s, 7372.72 MB allocated) ========== Machine code linking (5.01 s, 251.20 MB allocated) The percentage breakdown for the Tachyon compiler is: Time: 0% Parsing 1% IR generation 9% IR lowering 89% Machine code generation 1% Machine code linking Memory allocation: 1% Parsing 5% IR generation 24% IR lowering 68% Machine code generation 2% Machine code linking We can see that the machine code generation is the part of the compiler taking up most of the time and space. In terms of space, the IR lowering is also a heavy consumer. So we should focus our code improvement efforts on those parts. Should I also break down the machine code generation phase into subphases to see which part is causing the greatest performance problem? If so which? Marc

2 2

Simple GC
by Marc Feeley 02 Mar '11

02 Mar '11

Here's a simple runtime system in C, including a stop-and-copy GC, which I wrote some time ago for a compiler course I was teaching. A lot of the code is reusable for our simple GC. Of course it will have to be modified for our object representation, but at least the core algorithm can be kept. Marc

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Tachyon-list Mars 2011