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
Afficher les réponses par date
Thanks Marc, this information is really useful. I would be interested in knowing the time spent and memory allocated for the following phases in the machine code generation parts:
Register allocation (file: backend/linearscan.js) Block ordering (allocator.orderBlocks) Instruction numbering (allocator.numberInstrs) Interval construction (allocator.liveIntervals) Fixed interval construction (allocator.fixedIntervals) Linear Scan (allocator.linearScan) Operand assignation (allocator.assign) Resolution (allocator.resolution)
Machine code generation Translation (translator.prototype.genFunc) Assembly (asm.CodeBlock.prototype.assemble)
Those functions are all called in sequence in 'backend/backend.js' in function backend.compileIRToCB.
Erick
Le 11-03-02 23:47 , Marc Feeley a écrit :
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
Tachyon-list mailing list Tachyon-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/tachyon-list
On 2011-03-03, at 12:13 AM, Erick Lavoie wrote:
Thanks Marc, this information is really useful. I would be interested in knowing the time spent and memory allocated for the following phases in the machine code generation parts:
Register allocation (file: backend/linearscan.js) Block ordering (allocator.orderBlocks) Instruction numbering (allocator.numberInstrs) Interval construction (allocator.liveIntervals) Fixed interval construction (allocator.fixedIntervals) Linear Scan (allocator.linearScan) Operand assignation (allocator.assign) Resolution (allocator.resolution)
Machine code generation Translation (translator.prototype.genFunc) Assembly (asm.CodeBlock.prototype.assemble)
Those functions are all called in sequence in 'backend/backend.js' in function backend.compileIRToCB.
Erick
Here's what I get for the compilation of one of the bigger functions in parser/scanner.js:
===== Order blocks (0.001 s, 0.263 MB allocated) ===== Number instructions (0.021 s, 3.487 MB allocated) ===== Computing live intervals (0.141 s, 8.648 MB allocated) ===== Computing fixed intervals (0.016 s, 1.613 MB allocated) ===== Linear scan (4.633 s, 11.355 MB allocated) ===== Operand assignment (0.134 s, 2.246 MB allocated) ===== Resolution (4.626 s, 5.383 MB allocated) ===== IR to ASM translation (0.289 s, 29.091 MB allocated)
So "IR to ASM" takes the most space, followed by "linear scan" (about 1/3 of "IR to ASM").
The assembly also takes considerable time and space, but because it is done once for the whole file, it is hard to compare with the other times (which are per function).
Marc
-
Erick Lavoie -
Marc Feeley