Tachyon-list Mai 2011

tachyon-list@iro.umontreal.ca

5 participants
9 discussions

Démarrer une nNouvelle discussion

Javascript x86 emulator
by Erick Lavoie 18 Mai '11

18 Mai '11

Might be another interesting benchmark: http://bellard.org/jslinux/tech.html As suggested by Francisco. Erick

1 0

proto2 beats V8
by Marc Feeley 17 Mai '11

17 Mai '11

This weekend I improved my prototype compiler which compiles JS to x86, using the global property jump optimization. The compiler is rather minimal and handles just enough to compile fib and similar simple code. This prototype is mainly useful to explore various implementation approaches quickly, without the burden of the complete Tachyon compiler. It allowed me to test the performance of the global property jump optimization I proposed. Two versions were tested: proto1 = optimization of global property calls keeping the argument count setup and check in all cases proto2 = optimization of global property calls without the argument count setup and check when the number of parameters matches the number of arguments The results are very good. On fib(40), proto2 generate faster code than V8 (1.5x) and SpiderMonkey (2.3x), and Tachyon (18x). There is a 1.2x difference between proto1 and proto2 (in other words, there is a 20% overhead to setup and check argument counts). Here are the detailed running times: relative time to proto2 Tachyon 29.613 (18.3) SM 3.700 ( 2.3) V8 2.397 ( 1.5) proto1 2.000 ( 1.2) proto2 1.614 ( 1.0) Please examine the x86 code generated by proto2. Note that it performs all the expected dynamic type checks, and also the stack overflow checks. The optimization in proto2 will replace the code of the global property jump: call jump_global_prop_handler # perform jump to global property .long 3 # fib .byte 1,0 # number of arguments and filler with the direct jump: jmp fib_7 The details are in the attached file. If you have any questions please let me know. Here's a question for Maxime and Erick... can you estimate the work needed to get Tachyon to generate similar x86 code? Marc # notes: # # %ecx = context register # %eax = argument 1 of function and return value of function # %edi = return address # %ebp = stack pointer # # function fib(x) # { # if (x < 2) # return x; # else # return fib(x-1) + fib(x-2); # } fib_7: # main entry point of "fib" subb $1,%cl # check that arg_count = 1 jne _13 _14: testb $3,%al # check that x is a fixnum jne _17 cmpl $8,%eax # compare it to 2 jge else_16 then_15: jmp *%edi # return x (which is already in %eax) when x<2 _13: addb $1,%cl # handle arg_count != param_count pushl %ecx xorb %cl,%cl call *16(%ecx) jmp _14 _17: pushl %eax # handle generic "x < 2" pushl $8 call *28(%ecx) jl then_15 jmp else_16 else_16: movl %eax,-4(%ebp) # save x for later testb $3,%al # check that x is a fixnum jne _19 subl $8,%eax # "x - 2" jo _20 # check for overflow _21: # no overflow movl %edi,-8(%ebp) # save return address on stack addl $-8,%ebp # allocate frame on stack cmpl %ebp,(%ecx) # check for stack overflow ja _22 _23: # jump to global property "fib" movl $_18,%edi # setup return address movl 4(%ecx),%esi # setup "this" argument (= global object) call jump_global_prop_handler # perform jump to global property .long 3 # fib .byte 1,0 # number of arguments and filler _20: addl $8,%eax # undo subtraction that overflowed _19: pushl %eax # handle generic "x - 2" pushl $8 call *28(%ecx) jmp _21 _22: call *12(%ecx) # handle stack overflow jmp _23 ALIGN_RET_POINT FRAME_DESCR .long RET_POINT_TYPE RET_POINT_HEADER_END _18: # return point of call fib(x-2) movl 4(%ebp),%ebx # get x testb $3,%bl # check that x is a fixnum jne _25 subl $4,%ebx # "x - 1" jo _26 # check for overflow _27: movl %eax,-4(%ebp) # save result of call fib(x-2) movl %ebx,%eax # prepare argument of call fib(x-1) addl $-4,%ebp # grow frame on stack cmpl %ebp,(%ecx) # check for stack overflow ja _28 _29: # jump to global property "fib" movl $_24,%edi # setup return address movl 4(%ecx),%esi # setup "this" argument (= global object) call jump_global_prop_handler # perform jump to global property .long 3 # fib .byte 1,0 # number of arguments and filler _26: addl $4,%ebx # undo subtraction that overflowed _25: pushl %ebx # handle generic "x - 1" pushl $4 call *28(%ecx) jmp _27 _28: call *12(%ecx) # handle stack overflow jmp _29 ALIGN_RET_POINT FRAME_DESCR .long RET_POINT_TYPE RET_POINT_HEADER_END _24: # return point of call fib(x-1) testb $3,%al # check that result of call fib(x-1) is a fixnum jne _30 testb $3,(%ebp) # check that result of call fib(x-2) is a fixnum jne _30 addl (%ebp),%eax # add result of calls fib(x-1) and fib(x-2) jo _31 # check for overflow _32: addl $12,%ebp # remove stack frame jmp *-8(%ebp) # jump to return address _31: subl (%ebp),%eax # undo addition that overflowed _30: pushl %eax # handle generic "fib(x-1) + fib(x-2)" pushl -12(%ebp) call *28(%ecx) jmp _32

3 5

ptlsim
by Marc Feeley 17 Mai '11

17 Mai '11

Bruno, have you tried or know anything about the ptlsim x86 cycle accurate simulator? http://www.ptlsim.org/ It might be a valuable tool to understand the performance of specific x86 code sequences. Are there other similar tools? Ptlsim does not seem to be in active development (last commit in 2009). But I did get it to work... but I don't know how to analyze the results! Is anyone interested in getting it to work, and to understand the output of ptlstats (the program that analyses the statistics gathered during execution)? Bruno, perhaps this could be integrated to your profiling work. Marc

2 4

x86 code optimization references
by Marc Feeley 14 Mai '11

14 Mai '11

At one of our meetings Erick asked for guidelines for x86 assembly coding for best performance. I just found a set of references which address that question in depth. http://www.agner.org/optimize/ In particular I suggest that people read the following manual: http://www.agner.org/optimize/optimizing_assembly.pdf which is specifically about x86 assembly coding and contains very up to date information (for example, the nehalem and sandy bridge processors). Here's an interesting passage which supports my view that the code size is an important issue because it affects the efficiency of the caches and BTB (branch target buffer): 18.2 The pitfalls of unit-testing If you want to find out which version of a function performs best then it is not sufficient to measure clock cycles in a small test program that calls the function many times. Such a test is unlikely to give a realistic measure of cache misses because the test program may use less memory than the cache size. For example, an isolated test may show that it is advantageous to roll out a loop while a test where the function is inserted in the final program shows a large amount of cache misses when the loop is rolled out. Therefore, it is important not only to count clock cycles when evaluating the performance of a function, but also to consider ***how much space it uses in the code cache, data cache and branch target buffer.*** In other words, the code compactness of fib is probably not much of an issue when fib is run by itself, but it may be a problem if it is part of a larger program which also does other calculations. The manual contains many more guidelines. Please read it, if not in detail, at least browse it to know what the issues are. Marc

1 0

Code patching of call to global property
by Marc Feeley 13 Mai '11

13 Mai '11

I have completed a prototype implementation of the code patching mechanism that I have been thinking of these past few days. I won't explain it in this email because it is best to use a drawing to understand how it works. I'm attaching the source code and assembly code for 2 tests I tried. I compared the execution time against spidermonkey and the code is about 2.6 times faster than spidermonkey. It is roughly 30 times faster than Tachyon. Surprisingly, test2 is 20 times faster than V8. Maxime and Erick, we can talk about it this afternoon. Marc

1 1

Rescheduling meeting
by Marc Feeley 10 Mai '11

10 Mai '11

I have a conflict for this Wednesday afternoon. Can we reschedule for Thursday 2PM? Marc

3 4

Calling global functions
by Marc Feeley 09 Mai '11

09 Mai '11

At the last meeting I mentioned that I was worried about the performance of the getprop operation when calling global functions (such as in fib). Probably the biggest performance "mountain" at this point. So I wrote a simple benchmark to test how Tachyon performs when calling global functions: function f0() { } function f1() { f0(); f0(); f0(); f0(); } function f2() { f1(); f1(); f1(); f1(); } function f3() { f2(); f2(); f2(); f2(); } function f4() { f3(); f3(); f3(); f3(); } function f5() { f4(); f4(); f4(); f4(); } function f6() { f5(); f5(); f5(); f5(); } function f7() { f6(); f6(); f6(); f6(); } function f8() { f7(); f7(); f7(); f7(); } function f9() { f8(); f8(); f8(); f8(); } function f10() { f9(); f9(); f9(); f9(); } function f11() { f10(); f10(); f10(); f10(); } function f12() { f11(); f11(); f11(); f11(); } function f13() { f12(); f12(); f12(); f12(); } function f14() { f13(); f13(); f13(); f13(); } function f15() { f14(); f14(); f14(); f14(); } f15(); That code only does function calls, there is no arithmetic or loops. So the performance should be directly linked to the cost of calling global functions. Here are the running times for Tachyon and other JS VMs (relative times in parentheses): V8 1.700s ( 1.0) Safari (WebKit) 8.753s ( 5.1) Firefox (SpiderMonkey) 10.354s ( 6.1) Tachyon 111.240s (65.4) Two things come to mind: - V8 is really doing well compared to the other commercial JS VMs - Tachyon is doing really poorly, it is an order of magnitude slower than commercial JS VMs and almost two orders of magnitude slower than V8 This is surprising because on large JS benchmarks (such as the Tachyon compiler), the performance difference is not so great (Tachyon is "only" 10 times slower than V8), and on fib, Tachyon is 4 times slower than V8. In any case, I think this shows clearly that Tachyon's mechanism for calling global functions is particularly inefficient. We need to fix that! Marc

2 11

If Instruction Refactoring
by chevalma＠iro.umontreal.ca 05 Mai '11

05 Mai '11

I just completed the refactoring of the if instruction and verified that all unit tests pass in 32 bits. This is now committed. Erick, you should be able to merge without too much difficulty. The difference in the back-end is that the new if instruction code generation replaces the old if instruction and the comparison instructions. The code for fib is as predicted, except for a boxToBool that has been inserted. I will look tomorrow into optimizing the code generation to make it a bit faster and avoid inserting useless boxToBools and phi nodes when possible. I also want to look into having an support for (x & y === z) in the if instruction, but I believe it might be best to wait until the new register allocator interface is ready, as this might take more than one scratch register to implement. On this topic, Erick, I'd like to discuss the new register allocator interface with you (and Marc?) when you have time. I think that we may want our register constraints to be specified by a function, rather than fixed ahead of time... Because, for example, some instructions may need a varying number of scratch registers depending on how many operands they have, or on their type. In any case, it would be worth it to brainstorm about such issues. In the end, this new interface should make the code generation simpler and more robust, while generating higher-quality code. Next week I will probably look into using graphviz to visualize CFGs. This might help discover some potential CFG optimization patterns and/or generate pretty graphs for future publications. - Maxime

1 0

Q&A about Mozilla's Upcoming JIT
by chevalma＠iro.umontreal.ca 02 Mai '11

02 Mai '11

http://www.infoq.com/news/2011/05/ionmonkey

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Tachyon-list Mai 2011