Comments on: Flat Packing, the ultimate code optimization? http://webr3.org/blog/optimization/flat-packing-the-ultimate-code-optimization/ brain's on fire! Fri, 22 Apr 2011 00:44:37 +0100 http://wordpress.org/?v=2.9.2 hourly 1 By: nathan http://webr3.org/blog/optimization/flat-packing-the-ultimate-code-optimization/comment-page-1/#comment-120 nathan Thu, 24 Sep 2009 14:33:22 +0000 http://webr3.org/blog/?p=147#comment-120 we have 4 scenarios here: the way things currently work (afaik) - take the language syntax, turn it in to vm opcodes (mxmlc) the way things work better - take the language syntax, turn it in to vm opcodes and optimize on the way (haxe) the bloated way - take the language syntax, inline everything, turn it in to vm opcodes the proposed way - take the language syntax, inline everything, turn it in to vm opcodes, optimize, identify repeat code and factor in to functions, optimize again thus your not making syntax work on a vm, your effectively using the compiler to rewrite your application perfectly for the target vm. follow? we have 4 scenarios here:

the way things currently work (afaik) - take the language syntax, turn it in to vm opcodes (mxmlc)

the way things work better - take the language syntax, turn it in to vm opcodes and optimize on the way (haxe)

the bloated way - take the language syntax, inline everything, turn it in to vm opcodes

the proposed way - take the language syntax, inline everything, turn it in to vm opcodes, optimize, identify repeat code and factor in to functions, optimize again

thus your not making syntax work on a vm, your effectively using the compiler to rewrite your application perfectly for the target vm.

follow?

]]> By: Huge http://webr3.org/blog/optimization/flat-packing-the-ultimate-code-optimization/comment-page-1/#comment-119 Huge Thu, 24 Sep 2009 14:12:58 +0000 http://webr3.org/blog/?p=147#comment-119 I agree this is interesting. I think one advantage haxe has over TAAS is that is has more information to begin with, and it has some extra type info - eg Int vs Float, and typed arrays. One thing with functions is that the can be virtual - ie, the runtime does not know exactly which function will be called at runtime so it must leave it in as a symbolic reference. Obviously the code bloat could be done on the client end, keeping the swfs a constant size - but cpu cache issues make make small code run faster than large code. I think a good way of thinking about this is factorizing in mathematics. First you multiply out the brackets, then you group like terms, and cancel some out, and then extract factors to form a new, simpler, expression. We all lurve smarter compilers - well worth thinking about. I agree this is interesting. I think one advantage haxe has over TAAS is that is has more information to begin with, and it has some extra type info - eg Int vs Float, and typed arrays.
One thing with functions is that the can be virtual - ie, the runtime does not know exactly which function will be called at runtime so it must leave it in as a symbolic reference.
Obviously the code bloat could be done on the client end, keeping the swfs a constant size - but cpu cache issues make make small code run faster than large code.
I think a good way of thinking about this is factorizing in mathematics. First you multiply out the brackets, then you group like terms, and cancel some out, and then extract factors to form a new, simpler, expression.
We all lurve smarter compilers - well worth thinking about.

]]> By: Dykam http://webr3.org/blog/optimization/flat-packing-the-ultimate-code-optimization/comment-page-1/#comment-118 Dykam Thu, 24 Sep 2009 14:12:18 +0000 http://webr3.org/blog/?p=147#comment-118 There are two big BUT's, maybe another one related to the flash player: 1. Recursion is very, very hard to handle. This would become, or some bunch of jumps, or some methods still apart. 2. Your swf becomes big. Very big. And the loading time too. This is a common know trade-off for optimization by caching. But with big, I mean very very big. OO-projects contain many, many links between functions, causing problem 1 too. (3.) Can flash handle such a long code run... There are two big BUT's, maybe another one related to the flash player:
1. Recursion is very, very hard to handle. This would become, or some bunch of jumps, or some methods still apart.
2. Your swf becomes big. Very big. And the loading time too. This is a common know trade-off for optimization by caching. But with big, I mean very very big. OO-projects contain many, many links between functions, causing problem 1 too.
(3.) Can flash handle such a long code run...

]]> By: Ben Garney http://webr3.org/blog/optimization/flat-packing-the-ultimate-code-optimization/comment-page-1/#comment-110 Ben Garney Thu, 24 Sep 2009 04:19:38 +0000 http://webr3.org/blog/?p=147#comment-110 Inlining has diminishing returns (assuming your call performance isn't painfully bad) due to issues like memory caching, instruction decoding, etc. What you want is to inline your inner loops as much as possible, maximizing opportunities for instruction level parallelism, and not sweat the rest. In addition because AS3 is dynamic, there are a lot of situations where the compiler lacks the knowledge needed to inline, even if you are using strict typing. TBH I think the biggest bottleneck for AS3 right now is memory - cost of allocation - and the conflict between convenient syntax and what helps the compiler. In general, AS3 is a young language. It needs years of serious work to mature. Languages like C# and Java are a lot more mature and have addressed these problems in pretty powerful ways. Inlining has diminishing returns (assuming your call performance isn't painfully bad) due to issues like memory caching, instruction decoding, etc.

What you want is to inline your inner loops as much as possible, maximizing opportunities for instruction level parallelism, and not sweat the rest.

In addition because AS3 is dynamic, there are a lot of situations where the compiler lacks the knowledge needed to inline, even if you are using strict typing.

TBH I think the biggest bottleneck for AS3 right now is memory - cost of allocation - and the conflict between convenient syntax and what helps the compiler.

In general, AS3 is a young language. It needs years of serious work to mature. Languages like C# and Java are a lot more mature and have addressed these problems in pretty powerful ways.

]]> By: nathan http://webr3.org/blog/optimization/flat-packing-the-ultimate-code-optimization/comment-page-1/#comment-109 nathan Thu, 24 Sep 2009 01:50:40 +0000 http://webr3.org/blog/?p=147#comment-109 I fully comprehend the code bloat issue, in all honesty i think that only 20% of the original code would cause the bloat - further i think this approach would lead to better results, rather than optimizing what the programmer has done (which is always inherintly flawed) monolith the entire app by inlining everything, then un-inline the bloat - quite sure this approach would lead to improved results; when used with opcode reduction and optimization techniques such as taas and in-part haxe :) I fully comprehend the code bloat issue, in all honesty i think that only 20% of the original code would cause the bloat - further i think this approach would lead to better results, rather than optimizing what the programmer has done (which is always inherintly flawed) monolith the entire app by inlining everything, then un-inline the bloat - quite sure this approach would lead to improved results; when used with opcode reduction and optimization techniques such as taas and in-part haxe :)

]]> By: Troy Gilbert http://webr3.org/blog/optimization/flat-packing-the-ultimate-code-optimization/comment-page-1/#comment-108 Troy Gilbert Thu, 24 Sep 2009 01:15:34 +0000 http://webr3.org/blog/?p=147#comment-108 That's definitely the *theoretically* fastest way to do things. I remember back in the day when folks would "compile" bitmaps down to explicit instructions instead of copying data into memory. The problem, beyond the one you mention of interoperability between SWFs, is code bloat. Inlining everything would generate a *huge* amount of extra code. I would expect your SWF to be 10x or even 100x bigger, and not significantly faster. Remember the 80/20 rule and how it would apply: you'll bloat out 80% of your code to 10x or 100x its size without any noticeable difference. The brilliance of what TAAS does (and any really good compiler) is doing what you describe selectively and smartly, making trade-offs that yield actual benefits as opposed to dumbly inlining everything. That's definitely the *theoretically* fastest way to do things. I remember back in the day when folks would "compile" bitmaps down to explicit instructions instead of copying data into memory.

The problem, beyond the one you mention of interoperability between SWFs, is code bloat. Inlining everything would generate a *huge* amount of extra code. I would expect your SWF to be 10x or even 100x bigger, and not significantly faster. Remember the 80/20 rule and how it would apply: you'll bloat out 80% of your code to 10x or 100x its size without any noticeable difference.

The brilliance of what TAAS does (and any really good compiler) is doing what you describe selectively and smartly, making trade-offs that yield actual benefits as opposed to dumbly inlining everything.

]]>