Yes that is correct.I did it for the sake of the test .The same loop was done also in the other cases.Now I don't try to blame your engine as I even haven't seen its internals.The only thing I noticed in the demo was the FPS that was not impressive.I hope you invest a lot in optimizations.I used to work with JigLib before the Molehill version and as you probably know its performance was pretty bad .I plan to find time to write a benchmark for your engine and JiglIb to see the differences. Regards, Michael
On Tue, Apr 26, 2011 at 10:08 PM, ringodotnl <[email protected]> wrote: > Hey Michael, > > I did look at your article and what I can see, correct me if I am > wrong, is that you are calling the function from as3 to alchemy > xxxxxxx times. > > while(i<1000000){ > > dd=lib.InvSqrt(1245); > ++i; > } > > That would explain why it is slow, that's something we try to avoid > with Bullet (a good example is to look how the transforms are done). > > > > > On Apr 26, 12:03 pm, Michael Iv <[email protected]> wrote: > > Sorry guys I am not sure I am right but I can't see any awesome > performance > > here.In my browser Firefox 4 it runs around 25-30 fps when I start firing > > the balls. > > Also would like to note that Alchemy bridge is not always faster contrary > to > > what people may think.I made a benchmark of square root algorithms > > calculations in Flash a couple of months ago.You can read about it here: > http://blog.alladvanced.net/2011/02/21/square-root-calculation-speed-... > > basically I tried the built in Math.sqrt ,Fast Inverse square root > > algorithm developed by ID for quake (in AS) and the same Fast Inverse > Square > > root but in C in Alchemy .To my great surprise the result was that the > > alchemy version was the slowest.Several times slower than the Native > Flash > > implementation. BTW the fastest was HaXE implementation of the FISR > > Would be happy to hear some thought on this > > Michael. > > > > > > > > > > > > > > > > > > > > On Tue, Apr 26, 2011 at 3:02 AM, Choons <[email protected]> wrote: > > > yeah Flash's garbage collector is the real Achilles' heel for > > > Molehill. I think the Flash developer's are quite aware of it, but any > > > kind of real 3D game needs better low level control of memory. This > > > looks like a great step in the right direction > > > > > On Apr 25, 4:53 pm, Jesse Nicholson <[email protected]> > > > wrote: > > > > That is pure awesome guys. I can't say how much I'll be able to > > > > contribute (because of time etc) but I'll check out the source, > build/ > > > > test etc and if I can do anything I'll let you know. This is great > > > > thanks for sharing! And Yes Choons alchemy CAN be faster as it uses > > > > LLVM to perform code optimization, which is extremely good at > > > > optimization because of the type of compilation it does. However > there > > > > can be times where the performance is actually slower or just plain > > > > equal to pure as3. The biggest benefit with alchemy code is that it > > > > gives you the ability to bypass the garbage collector in flash all > > > > together, which is automatic and sluggish, by providing you with an > > > > interface to the raw system memory via a ByteArray object. And yes it > > > > would use alchemy pretty much throughout because Bullet is a C++ > > > > library. Anyway very cool thanks a lot for sharing Ringo! > > > > -- > > Michael Ivanov ,Programmer > > Neurotech Solutions Ltd. > > Flex|Air |3D|Unity|www.neurotechresearch.comhttp://blog.alladvanced.net > > Tel:054-4962254 > > [email protected] > > [email protected] > -- Michael Ivanov ,Programmer Neurotech Solutions Ltd. Flex|Air |3D|Unity| www.neurotechresearch.com http://blog.alladvanced.net Tel:054-4962254 [email protected] [email protected]
