Loose Kazmath for GLKit about cocos2d-objc

[FramusRock]

This sounds like a very good idea but I would do some time profiling before replacing it to be absolutely certain.
Lile measure the time of the 1000 most used matrix operations with both libraries and find out which operation is faster with which library.
If I get the chance to do, I'll do it later.

[slembcke]

The biggest benefit of moving to GLKMath is that all of the functions take and return values. Kazmath is fairly frustrating to use since all of the functions work by passing references. You end up needing to manage your own temporary variables. I'd suspect GLKMath to be faster since passing by reference prevents compilers from inlining code effectively. On the other hand, GLKMath takes the address of it's arguments when mixing in NEON code anyway... Either way, Cocos2D spends very very little of it's total CPU time on matrix math right now anyway. At runtime, it's really only used to update the 4x4 transform matrix of the scene hierarchy when rendering.

[SiarheiFedartsou]

I've made fast test: https://gist.github.com/SiarheiFedartsou/7568295
Results(on Simulator, but on device, I think, it will be similar):

time GLKit: 0.081688
time kazmath: 0.148425

GLKit is 1.8 times faster!

[FramusRock]

Thanks for testing! I didn't get to do it, yet.
But please for anything never test on simulator - always do it on device.

I've run your test on an iPad 3:
time GLKit: 0.449398
time kazmath: 0.584463

GLKit does win, so I suggest using it.

Since cocos2d is also used to develop Mac games, you might want to give it a try on a Mac app, which I would assume will have very similar results to the iPhone simulator.

[FramusRock]

Results on my Mac:
time GLKit: 0.052906
time kazmath: 0.163864

Simulator:
time GLKit: 0.080110
time kazmath: 0.154107

The Mac power the iPhone Simulator but though the results are different (of course GLKit is still a lot faster). For the first test I would use an iDevice anyday since this is where I personally see cocos2d to be used like 90% of the time :)

[slembcke]

Be skeptical of the results you are seeing out of a micro benchmark like that. Compilers (and even CPUs) are often smart about that sort of thing, and you need to be careful if you are benchmarking the optimizer or the runtime performance of the code. Though in this case none of the functions are inlinable. (Run Product > Perform Action > Assemble if you are unsure)

Original test on an iPad 2:
2013-11-20 13:38:31.434 CCPhysicsTest[5957:907] time GLKit: 0.469212 (GLKit is quite a bit slower here)
2013-11-20 13:38:31.774 CCPhysicsTest[5957:907] time kazmath: 0.336407

In both cases, if you avoid the matrix stacks and use the inlinable functions it gets way faster. (Be especially skeptical of the first paragraph now!) I had to tweak the program to remove the compile time constants. The output assembly had optimized away the actual matrix computations otherwise. https://gist.github.com/slembcke/7569537

Stackless version:
2013-11-20 13:57:43.831 CCPhysicsTest[5992:907] time GLKit: 0.120254
2013-11-20 13:57:43.966 CCPhysicsTest[5992:907] time kazmath: 0.133423

If the results are to be trusted, avoiding the stacks is an even bigger gain than the choice of API. (At least in a microbenchmark) Either way, both libraries are pretty similar in performance, and the total amount of work they do in Cocos2D is pretty small according to the time profiler. Even in the best possible case we are talking about small single digit improvements.

I really dislike Kazmath's awkward reference based API. I'd be interested in taking this task on if we are going to go forward with it, but it might be a couple of weeks to get to it.

[Birkemose]

Kazmath is some old junk, with hard coded assembler code. Yuk I say. Got it working in 64 bit, but performance will suffer, as neon must be disabled. At the end of the day, I would be surprised if apples own implementation wasn't somewhat faster than an old c lib.

[Panajev]

I would not honestly. Apple gives me the impression of favoring ease of use and foolproof solutions to speed with gotchas that destroy either quality or performance... See PowerVR on chip MSAA resolve going essentially to waste, and the loss of bandwidth and memory this induces, to avoid accidental/misplaced flushes from introducing visual artifacts.

Still, GLKit might be more than good enough and reduce our external dependencies.

[web [iPhone msg]]

On 22/nov/2013, at 09:30, Birkemose [email protected] wrote:

Kazmath is some old junk, with hard coded assembler code. Yuk I say. Got it working in 64 bit, but performance will suffer, as neon must be disabled. At the end of the day, I would be surprised if apples own implementation wasn't somewhat faster than an old c lib.

—
Reply to this email directly or view it on GitHub.

[dissidently]

My impressions of GLKit are largely ignorant. However it seems to be the base of Apple's exploitation of their own hardware for performant and efficient positional handling in many levels of complexity... And simplicity. I'd strongly suggest taking a look at the video from the WWDC year it was released. They go into great detail about its efficiencies. And the reasons to use it. But I can't seem to find that video. I thinks it's one of the OpenGL or game based videos from 2011 or 2012.

It's being used here: http://doc.sparrow-framework.org/v2/Classes/SPMatrix.html

And walked through some parts here:

http://games.ianterrell.com/how-to-manipulate-objects-with-glkit/

And an intro here:

http://games.ianterrell.com/learn-the-basics-of-opengl-with-glkit-in-ios-5/

As I say... I'm ignorant. But much of that video from apple discussed the level of performance and optimisation to their hardware. And it was the first part of a very strategic push into the gaming SDK provisions we are now seeing. So I'd suggest it is probably pretty good. And easy to use.

Perhaps ask Daniel from Sparrow/Starling what he thinks of it as he is a fantastic mind with a truly wonderful personality.

On Nov 22, 2013, at 5:40 PM, Panajev [email protected] wrote:

I would not honestly. Apple gives me the impression of favoring ease of use and foolproof solutions to speed with gotchas that destroy either quality or performance... See PowerVR on chip MSAA resolve going essentially to waste, and the loss of bandwidth and memory this induces, to avoid accidental/misplaced flushes from introducing visual artifacts.

Still, GLKit might be more than good enough and reduce our external dependencies.

[web [iPhone msg]]

On 22/nov/2013, at 09:30, Birkemose [email protected] wrote:

Kazmath is some old junk, with hard coded assembler code. Yuk I say. Got it working in 64 bit, but performance will suffer, as neon must be disabled. At the end of the day, I would be surprised if apples own implementation wasn't somewhat faster than an old c lib.

�\
Reply to this email directly or view it on GitHub.
�
Reply to this email directly or view it on GitHub.

[slembcke]

I sort of dislike GLKView and GLKViewController. I started using them in my Chipmunk Showcase app because I figured "Why not?". When I wanted to add threaded rendering, I found out it was impossible since the GLK classes didn't expose the rendering loop at all. I ended up reimplementing method by method what I was using out of GLKit and it ended up being ~300 lines of code after I added the threading parts to it. It wasn't worth the closed source hassle in that case, and they were definitely targeting correctness and simplicity over performance or flexibility.

The GLKMath stuff seems quite good though. If the microbenchmarks above are any indication, it's certainly not much worse and possibly a little better. The format of the API is so much easier to use I almost don't care... (as somebody whose written Kazmath code in custom draw functions. Yuck!)

The texture loading stuff is also nice and pretty flexible even. Though it still replaces only a couple hundred lines of code I already know how to write. Nice, but it's not going to save me hours of work.

[cocojoe]

+1 GLKit, may not be much in it performance wise from Matt's benchmarking
however certainly easier to read and let's us drop some code :)

On 22 November 2013 15:36, slembcke [email protected] wrote:

I sort of dislike GLKView and GLKViewController. I started using them in
my Chipmunk Showcase app because I figured "Why not?". When I wanted to add
threaded rendering, I found out it was impossible since the GLK classes
didn't expose the rendering loop at all. I ended up reimplementing method
by method what I was using out of GLKit and it ended up being ~300 lines of
code after I added the threading parts to it. It wasn't worth the closed
source hassle in that case, and they were definitely targeting correctness
and simplicity over performance or flexibility.

The GLKMath stuff seems quite good though. If the microbenchmarks above
are any indication, it's certainly not much worse and possibly a little
better. The format of the API is so much easier to use I almost don't
care... (as somebody whose written Kazmath code in custom draw functions.
Yuck!)

The texture loading stuff is also nice and pretty flexible even. Though it
still replaces only a couple hundred lines of code I already know how to
write. Nice, but it's not going to save me hours of work.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/376#issuecomment-29081311
.

Martin

[dominik-hadl]

+1 Just Loose It (like this)

I really think kazmath is old and has a horrible API. GLKit could offer better performance, and if not, it definitely will be at least the same.

[vlidholt]

I'm taking the liberty of moving this to 3.1 (as we are breaking/redoing rendering stuff there anyway), and other issues are more pressing to get done for 3.0

[SiarheiFedartsou]

#557