|
From: | Jan Wedekind |
Subject: | Re: [Dotgnu-libjit] Arithmetic operations and type-coercions for byte, short int, ... |
Date: | Fri, 19 Sep 2008 18:38:43 +0100 (BST) |
User-agent: | Alpine 1.00 (DEB 882 2007-12-20) |
Sorry about that. I didn't realise that this may actually make things slower. I think at some point I will try to look at the assembler code generated by GNU C++ to see what makes it run faster. Probably it's just loop-unrolling or something which can easily be reproduced using libjit. If no major work is required to get the same performance, this is good news. On Fri, 19 Sep 2008, Klaus Treichel wrote:
Am Donnerstag, den 18.09.2008, 17:10 -0700 schrieb Kirill Kononenko:Also I do not think there is much sense have support of 16, 8 bit opcodes on a 32-bit processor. As it will operate on 32-bit data anyways. Actually I have read using 8-bit register can even slow down your program.At least operations on non native sizes add additional latencies because the cpu has to merge the 8/16 bit from the current result with the previous register contents. IMHO it makes more sense to expand the value during load from a register to the native size what should be done without extra costs and omit the expansion of the value with an extra instruction. (At least for the intel x86 family). This approach doesn't allow usage of the high 8bit registers but i doubt they are used anyways in libjit. KlausThanks, Kirill 2008/9/18 Jan Wedekind <address@hidden>:Thanks for your response. First of all the time for code generation seems to be negligible for my application. I am interested in libjit, because it is difficult to write a C++ library which provides all possible combinations of operators and element-types. Looks like I overlooked quite a bit though regarding adding special support for operations on 8- and 16-bit values. If I understand it correctly one needs to do the following things: * add functions supporting the additional types - and combination of types :( - to jit-intrinsic.c * add instruction sets to jit-rules-*.ins for each platform * update the jit_opcode_descr tables in jit-insn.c * optionally upgrade the backend to support register-register operation such as 2-byte addition [1]. If I understand it correctly the code is somewhere in jit-rules-x86.c. I'm not sure whether I will have the time (and a sufficient understanding of the code) to do this. Especially I don't know how to do this without breaking the other backends for Alpha and ARM. [1] http://home.comcast.net/~fbui/intel_a.html#add On Sat, 13 Sep 2008, Klaus Treichel wrote:Hi Jan, Am Sonntag, den 07.09.2008, 11:28 +0100 schrieb Jan Wedekind:5AHi, I'm developing a Ruby-extension for doing computer vision [1] with the Ruby programming language and I am thinking about replacing the current C++ template implementation with an implementation based on libjit and ruby-libjit [2]. I need to generate code to do element-wise unary operations (such as +,-) and binary (scalar-array,array-scalar,array-array) operations (such as +,-,*,/,**,minor,major). The element-types of the two arrays can be various combinations of char, unsigned char, unsigned short int, ... I noted that adding to 8-bit values with libjit results in a 32 bit integer. Since I don't want to overwrite succeeding elements in the array, I need to convert the result back to 8-bit. A performance comparison shows that this also has an impact on the performance (see below). I had a look at the methods "common_binary" and "apply_arith" and I am wondering whether one could extend the code to support coercions resulting in 8- or 16-bit values as well.We'll have to add all arithmetic opcodes for 8bit and 16bit values too which will about double the number of opcodes for integer arithmetics (and the corresponding intrinsics). The next step would be supporting backend specific addressing modes for arithmetic operations to be able to emit code like add 0x10(%ecx, %edx, 4), %eax on x86 instead of loading 0x10(%ecx, %edx, 4) to a register first.Please let me know what you think and tell me if I overlooked something. It would be really cool if I could get the same performance as a C/C++ implementation.Libjit is still a just in time compiler where the time needed for code generation has to be taken into account too. Any suggestions are welcome. Klaus_______________________________________________ Dotgnu-libjit mailing list address@hidden http://lists.gnu.org/mailman/listinfo/dotgnu-libjit_______________________________________________ Dotgnu-libjit mailing list address@hidden http://lists.gnu.org/mailman/listinfo/dotgnu-libjit
[Prev in Thread] | Current Thread | [Next in Thread] |