> You clearly understand what I was saying, Mark, but just a brief > reiteration: compiled ActionScript has to be interpreted by the VM, which is > _always_ slower than compiling directly to machine language.
Yes, I understand and am not even disagreeing. :) However, there have been benchmarks where Java was actually marginally /faster/ than C++ for some specific tests. This seems counterintuitive, but the JIT compiler knows more at runtime than the traditional compiler can know in advance, and I'm guessing that's why it can (not generally, but in some rare situations) do better optimizations. When you have ideal programmers then of course compiled languages will be faster, but that difference is getting less as technology evolves. But of course we're talking about the Flashplayer here, and size, portability and start-up time are more important design goals than execution speed, so we'll most definitely will always have to live with a very noticeable performance penalty. Then again, we don't have to manage memory ourselves, which is a big plus. (Btw memory allocation and optimization: recycling instances where possible is also a good idea.) If somebody knows a good explanation about the when and how of the AVM2 JIT compiler, I'd be curious. The same goes for a table that shows relative performance of stuff the renderer does -- like with alpha vs. without, if rendering time grows linear with the number of pixels, how much time is wasted on DisplayObjects outside of the visible Stage, stuff like that. Mark On Wed, Jul 30, 2008 at 9:05 PM, Kerry Thompson <[EMAIL PROTECTED]> wrote: > Mark Winterhalder wrote: > >> Nitpicking, but just as anything digital the SWF opcodes essentially >> are 1s and 0s, too. :) > > Fair enough. Following that to its logical conclusion, _everything_ on your > computer is 1s and 0s, including the text in this email ^_^ > > You clearly understand what I was saying, Mark, but just a brief > reiteration: compiled ActionScript has to be interpreted by the VM, which is > _always_ slower than compiling directly to machine language. > > When I was doing Director full time, I ran some tests that showed C++ to run > up to 400 times as fast as Lingo. I lobbied for years to get a true > machine-language compiler for Lingo, at least for desktop apps. I was struck > by how few developers understood the implications, and without other > developers clamoring for the need for speed, Macromedia never went there. > Director could have been a major player in the 3D game world. > > And don't tell me that Director 3D is "fast enough". Hard-core gamers buy > $8,000 machines to squeeze every last fps out of their games. With lights, > shaders, high-poly objects, multiple cameras, Director is just not fast > enough for a Quake or Doom LAN party. And, of course, neither is Flash. > >> Anyway, the new VM supports JIT compilation to native machine code. I >> must admit I don't know if /all/ code gets JIT compiled or only >> hotspots, and I don't know if it will be recompiled for each use to >> "hardcode" variables, but that would also have implications. > > One major implication would be in loops. The complier would have no way of > knowing if an array would change length in a loop, for example, so it > couldn't hard code the length. > > Cordially, > > Kerry Thompson > > _______________________________________________ > Flashcoders mailing list > Flashcoders@chattyfig.figleaf.com > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders > _______________________________________________ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
