Menu
▾
▴
Re: [xmlvm-users] Arrays manipulation on iPhone
|
From: Kevin G. <ke...@co...> - 2009-09-21 08:59:40
|
In that case the buffer stuff contributed as part of the OpenGL patch might
be a good starting place. The IntBuffer/FloatBuffer etc are essentially
wrapped arrays as it stands.
Kev
2009/9/21 Arno Puder <ar...@pu...>
>
> certainly a good question. There is even one other problem: who
> deallocates the array? The nice effect of using an NSMutableArray is
> that it ends up on the autorelease pool, so it will eventually be
> released. This is not the case if you allocate something that is not
> derived from NSObject.
>
> I think the solution to both problems is to create a new class
> XMLVMPrimitiveArray that acts as a wrapper to an efficiently maintained
> array. This way you can store the size of the array and you can also
> properly dealloc it. This should still be more efficient than using
> NSMutableArray.
>
> Arno
>
>
> Kevin Glass wrote:
> > 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... <mailto: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...> <mailto: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...>
> > <mailto: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...>
> > > <mailto: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...
> > <mailto: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...
> > <mailto: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
>
|
