Nicolas, If they have optimized around a just-in time strategy, the opcodes are really not that relevant because they are converting to machine code. Of course I strongly suspect the opcodes are radically different. Why bother changing them if you are not going to change them radically. I just don't believe that Gary Grossman is an idiot, and that even if he is, that a 4 billion dollar corp couldn't find a smart compiler guy. Of course the proof is in the pudding, but it sounds a little like you think "they aren't smart enough to do this".
As far as the 5-10x thing, You are right that that doesn't seem fast enough. But in the real world, tests are often reveal performance that is different from the theoretical limit. Part of the question is what were they testing and what are the gating factors for that testing. All the actionscript team was optimizing was *actionscript*, and not the flash engine. So if they were, for example, drawing a movie clip and rotating it, then the comparison would be the entire system, and obviously changing actionscript isn't going to improve the speed of the flash rendering engine. Comparing to Python, which does no rendering, or to Java, which is so slow at drawing that no one takes it seriously in that arena, is really not appropriate for applications that do drawing. However, a fair comparison would be some looping pure math or pure logic algorithm without any use of the DOM. There are people that spend their lives doing benchmarks of algorithms and that is where the comparisons get interesting. But I seriously doubt the person who said there is a 5-10x improvement was doing some serious benchmark that could be applied across multiple technologies. I bet it included doing regular Flash things that *do* use the DOM. If this is the case then it is likely that the actionscript part of that test is much faster than the 5-10x. I guess it is just inconceivable to me that in 2 years of work, that a 4 billion dollar company would not be able to apply state of the art compiler techniques such as those in Java that have been around for 5+ years, to their flagship product. To fail in that challenge would be a failure of herculean proportion. I guess anything is possible but that seems like not such a good bet. If you can do nekoVM, I think you should consider the possibility that there is someone at MM who is at least as knowledgeable or nearly as knowledgeable as you about such things. And with the benefit of JIT technology, I think the likilhood of vast speed improvements is even greater. Of course, once again, the proof is in the pudding. (An english cliche for all of you (EASL (english as second language)) people. Regards Hank On 10/9/05, Nicolas Cannasse <[EMAIL PROTECTED]> wrote: > I'm also really waiting to see this new technology running , but I'm a > little concerned about speed. I read on some MM blog that the new VM is > having a 5-10x speed improvment. That's already great, but it's still far > from Java bytecode speed for exemple. I know pretty well ASVM1 bytecode so I > can tell that unless they radicaly changed the design of opcodes, they'll > not be able to get "state of the art" performances. For instance Python is > bytecode-interpreted and is already around 5-10 times faster than > ActionScript. And Python design is known to be difficult (read slow) to > execute. > > But I think it's great that MM is taking VM performances seriously, and I > hope they will keep on improving it. > > ----- Original Message ----- > From: "Jim Kremens" <[EMAIL PROTECTED]> > To: "Flashcoders mailing list" <[email protected]> > Sent: Sunday, October 09, 2005 1:48 AM > Subject: Re: [Flashcoders] Flash player 8.5 and ActionScript 3.0 > > > "with a Just in time compiler it should be in the ball park of java or > the .net VM. Compiler technology is pretty well understood. If they > have been working on this for 2 years there is no reason they shouldnt > be state of the art in this area." > > That's crazy. I can't wait... > > Jim Kremens > > On 10/8/05, hank williams <[EMAIL PROTECTED]> wrote: > > Of course there is no way to know without trying it but... > > > > with a Just in time compiler it should be in the ball park of java or > > the .net VM. Compiler technology is pretty well understood. If they > > have been working on this for 2 years there is no reason they shouldnt > > be state of the art in this area. > > > > Hank > > > > On 10/8/05, Jim Kremens <[EMAIL PROTECTED]> wrote: > > > The discussion of JVM and .NET runtimes makes me wonder whether Flash > > > will ever really compete with them. > > > > > > How much faster is the new Virtual Machine? Whatever the increase, > > > does it put us in the realm of, say, Java regarding speed? If not, > > > how far off? > > > > > > Jim Kremens > > > > > > On 10/8/05, Weyert de Boer <[EMAIL PROTECTED]> wrote: > > > > Isaac Rivera wrote: > > > > > > > > > I know that MS has stated that they would port .NET to ALL > platforms. > > > > > Let's see. > > > > > > > > > > Until there is an official, up to date, fully capable, Darwin port, > > > > > there is an even better alternative than mono... JVM can be > developed > > > > > and deployed everywhere with community-approved products. > > > > > > > > Too bad you need to use Java for JVM at the moment. :=) Of course > Cocoa > > > > is a good option too and just drop Windows etc. <g> > > > > _______________________________________________ > > > > Flashcoders mailing list > > > > [email protected] > > > > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders > > > > > > > _______________________________________________ > > > Flashcoders mailing list > > > [email protected] > > > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders > > > > > _______________________________________________ > > Flashcoders mailing list > > [email protected] > > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders > > > _______________________________________________ > Flashcoders mailing list > [email protected] > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders > > > _______________________________________________ > Flashcoders mailing list > [email protected] > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders > _______________________________________________ Flashcoders mailing list [email protected] http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
