From: Kevin G. <ke...@co...> - 2009-09-21 08:42:31
|
How would you copy with array.length in Java if you're using primitive arrays in ObjC? Statically created arrays would work with sizeof, but don't you end up with dynamically allocated arrays during the conversion process? Kev 2009/9/21 Arno Puder <ar...@pu...> > > Jacob, > > it would be nice if you could contribute to XMLVM. As Sascha pointed > out, we have been thinking for quite some time to add a > stack-to-register machine transformation at the end of the processing > pipeline. > > You are right that we don't handle arrays very efficiently (this is > independent of the register machine). There are two byte code > instructions to create new arrays: newarray and anewarray. The latter is > for object references and the former for primitive types. Currently > XMLVM treats those two byte code instructions the same (i.e., we use a > NSMutableArray to store an array of primitive types). I think you would > already get a lot of performance boost if we handled this in a better way. > > Would you be interested to give this a try? You basically would need to > change the xmlvm2objc.xsl stylesheet and modify all array related byte > codes. newarray would create an efficient Objective-C array and the > accessor instructions such as iastore directly access the array without > a NSMutableArray. > > Arno > > > Jacob Nordfalk wrote: > > Hello Sascha, > > > > thanks for your quick reply. > > > > In our case the hope was to use 170 hours on preparing and porting our > > Java code, withing one calendar month. > > We have now changed that estimate to the double - 340 hours, within 1 > > 1/2 calendar month. > > > > We are proficient Java coders (Objective-C is new, but for array > > manopulations it probably wouldnt seem to give too much headache :-) and > > one (I) has understanding of XML, bytecode and virtual machines. I could > > allocate up to 60 hours for improving XMLVM during the next month if > > that could solve our problems. > > > > I know 60 hours isnt much, but as economy is a concern here must weight > > it against finding another way of porting the application (eventually by > > hand). > > If you, within these time contraint, would recommend spending some time > > improving XMLVM and your'e willing to guide me and engage yourselves in > > the project too, then lets consider it. > > > > However, it seems to me that there is another performance problem here, > > and that is the usage of NSMutableArray of objects instead of a byte[] > > array ? > > > > I would be very thankfull if you could comment with your best guess on, > > whether the factor 20 somes from the stack-based model used for > > generating Objective-C code, or from the usage of NSMutableArray of > > objects instead of byte[] arrays? > > > > Another important questions is then: How much effort would be required > > to make a version of XMLVM that generated code using arrays of simple > > type instead of arrays ? > > > > Thank you, > > Jacob > > > > 2009/9/21 Sascha Haeberling <sa...@xm... <mailto:sa...@xm...>> > > > > Hello Jacob, > > > > thank you for your great analysis and question. > > > > You are absolutely right. As you can see, we are trying to mimic a > > JVM as close as possible. While we think that the performance is > > fine for most use cases, some use cases (like yours) can actually > > perform much worse when being cross-compiled with XMLVM. Therefore, > > one of our current tasks is to look at converting our stack-bases > > model to a register-based one, so that languages like Objective-C > > can benefit. > > > > However, we are still in the planning stage of this and I cannot > > give you any deadlines. Would this be something you are interested > > in contributing to or do you have any other ideas? > > > > Thank you > > // Sascha > > > > On Sun, Sep 20, 2009 at 11:29 PM, Jacob Nordfalk > > <jac...@gm... <mailto:jac...@gm...>> wrote: > > > > Hi, > > > > I am considering porting an image manipulation program in Java > > to iPhone using XMLVM. > > > > However, code such as > > > > public byte[] xxx(byte[] rgb) { > > > > for (int i = 0; i<rgb.length; i+=3) { > > rgb[i] += 1; > > rgb[i+1]/=2; > > rgb[i+2]/=2; > > } > > > > return rgb; > > } > > > > seems to run 20 times slower than JIT-enabled Java when > > compiling xmlvm generated objective-C. > > > > When I looked at the code I understood why - the generated > > objective-C is something like 26 lines > > per line of Java (here below is for the line: rgb[i+1]/=2). > > > > > > - (NSMutableArray*) optimize___byte_ARRAYTYPE > :(NSMutableArray*)n1 > > { > > XMLVMElem _stack[4]; > > XMLVMElem _locals[5]; > > int _sp = 0; > > XMLVMElem _op1, _op2, _op3; > > ... > > > > *// rgb[i+1]/=2;* > > _stack[_sp++].o = _locals[1].o; > > _op1.i = _locals[4].i; > > _stack[_sp++].i = _op1.i; > > _stack[_sp++].i = 1; > > _op2.i = _stack[--_sp].i; > > _op1.i = _stack[--_sp].i; > > _stack[_sp++].i = _op1.i + _op2.i; > > _op1 = _stack[_sp - 2]; > > _op2 = _stack[_sp - 1]; > > _stack[_sp++] = _op1; > > _stack[_sp++] = _op2; > > _op1.i = _stack[--_sp].i; > > _op2.o = _stack[--_sp].o; > > _stack[_sp++].i = [[_op2.o objectAtIndex: _op1.i] intValue]; > > _stack[_sp++].i = 2; > > _op2.i = _stack[--_sp].i; > > _op1.i = _stack[--_sp].i; > > _stack[_sp++].i = _op1.i / _op2.i; > > _op1.i = _stack[--_sp].i; > > _stack[_sp++].i = (int) (_op1.i & 0xFF); > > _op1.i = _stack[--_sp].i; > > _op2.i = _stack[--_sp].i; > > _op3.o = _stack[--_sp].o; > > [_op3.o replaceObjectAtIndex: _op2.i withObject: [NSNumber > > numberWithInt: _op1.i]]; > > > > > > Now, I understand that the speed factor 20 is becaurse XMLVM is > > emulating the stack-based JVM in Objective-C, > > but I as I have really LOT of array manipulation code I am > > asking you: > > > > > > Do you have any advice or ideas on how to make Java code using > > simple array manipulations run relatively fast on the iPhone ? > > > > > > > > Thanks you, > > Jacob Nordfalk > > > > -- > > Jacob Nordfalk > > एस्पेरान्तो के हो? http://www.esperanto.org.np/. > > Memoraĵoj de KEF -. http://kef.saluton.dk/memorajoj/ > > > > > ------------------------------------------------------------------------------ > > Come build with us! The BlackBerry® Developer Conference in > > SF, CA > > is the only developer event you need to attend this year. > > Jumpstart your > > developing skills, take BlackBerry mobile applications to market > > and stay > > ahead of the curve. Join us from November 9-12, 2009. > > Register now! > > http://p.sf.net/sfu/devconf > > _______________________________________________ > > xmlvm-users mailing list > > xml...@li... > > <mailto:xml...@li...> > > https://lists.sourceforge.net/lists/listinfo/xmlvm-users > > > > > > > > > > > > -- > > Jacob Nordfalk > > एस्पेरान्तो के हो? http://www.esperanto.org.np/. > > Memoraĵoj de KEF -. http://kef.saluton.dk/memorajoj/ > > > > > > ------------------------------------------------------------------------ > > > > > ------------------------------------------------------------------------------ > > Come build with us! The BlackBerry® Developer Conference in SF, CA > > is the only developer event you need to attend this year. Jumpstart your > > developing skills, take BlackBerry mobile applications to market and stay > > ahead of the curve. Join us from November 9-12, 2009. Register > now! > > http://p.sf.net/sfu/devconf > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > xmlvm-users mailing list > > xml...@li... > > https://lists.sourceforge.net/lists/listinfo/xmlvm-users > > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry® Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9-12, 2009. Register now! > http://p.sf.net/sfu/devconf > _______________________________________________ > xmlvm-users mailing list > xml...@li... > https://lists.sourceforge.net/lists/listinfo/xmlvm-users > |