I don't think that dynamic optimization can be so easily characterized as "advantaged" over static optimization. Both have their advantages. Microsoft recognizes this and implements both in their Vulcan project.
Definitely both types of optimization provide different benefits. I would never want a world without static optimizers. Dynamic optimization is relatively new and I think we have yet to see what it is really good at.
It is also not an apples to apples comparison when comparing an interpreted -> native code optimization (JIT) vs. a native code to native code optimization (FDPR).
This is true. The virtual machine oriented dynamic optimizers have farther to go on the optimization front, but are much better at thefeedback-loop aspects. I think eventually the two efforts will meet in the middle. C++ environments will become more "virtualized" with garbage collectors and runtime profilers, while existing virtual environments (like Java) will become more "static" with JITs and native compilers. The (oft abhorred) C# is a good example of this convergence.
Java, on the other hand, is new to the game and has certain language features (required array bounds checking) that trade performance for run-time safety which force it to find other ways to get performance improvements.
This is certainly the case. I (like many other heavy Java users) tend to think that for most cases the tradoff between performance and bug-reducing language features is a worthwhile trade. Of course it always depends on what problems your are trying to solve.
Anyway, I continue to think that any/most of the good stuff in Java has been in Lisp for ages and that Lisp tends to do it better, including performance.
Actually, I think that the best stuff from Lisp is conspicously absent from Java. Perl and Python seem to me to be the inheritors of the really good bits from Lisp.
Err - but you can do that with C++. Ever heard of Feedback Directed Program Restructuring (FDPR)? You run your code under whatever load you feel like optimizing and use the FDPR tools to rebuild the code, changing the ordering and ensuring that cache misses are minimized as much as possible.
There is one thing wrong with this process; rebuild. The latest generation of Java dynamic compilation/optimization does its work behind the scenes and happens automatically which I think is a huge advantage over FDPR. It allows the optimizer to adapt to unforseen changes in the production environment.
I think that Hotspot-style dynamic optimization is the future of Java and will eventually overtake statically compiled (or repeatedly compiled) options.
However, Hotspot has a lot to learn from FDPR, like how to keep track of performance metrics across VM sessions. The biggest drawback of current Java dynamic optimizers is that you only get their full potential for long-running processes. Once they get optimization profile management down, the dynamic optimizers like Hotspot are going to look much more appealing on the types of benchmarks like this article uses.
I do know that TV studios often include time compression rights in syndication contracts. So once a show has had its first run, they don't care if the stations cut it during reruns (as long as they keep getting those checks).
I don't know if losing one frame out of 44 can really alter our perception of a dramatic pause --
I can't say for sure that I can notice. It would be interesting to see footage before and after and try to find the microedits.
However, since the article mentions that the process works on duplicate frames, then it seems likely to me that more contiguous frames might be cut from a dramatic pause (with little movement) than from an action shot. If this is the case then the visual difference from a dramatic shot could easily be within the perception of an average viewer.
This is an interesting point that I also noticed. The reasons stated for not sharing seem to be oriented towards academic competition, not economic competition. I know that scientists are always jockying for funding and support, and publishing first will often secure such funding. However, the economics of science seem very different (in scale) from that of the big pharmacutical companies using patents to control the production of medicines.
I wonder how close the relationship is between the publishing scientists and the patent owners?
Does a scientist who publishes first usually get a patent (and presumably royalties)?
Or is the competition confined to the economics of science?
XP (eXtreme Programming) has some good insights for this kind of situation.
Instead of waiting for large releases to do integration testing or customer approval, you can "tighten the loop" and do faster iterations with the process you already have.
Once you have your use cases and UML and everything, then pick a couple of basic features and build them fast and release them (Don't forget to write automated tests). That way you get customer feedback and integration testing practice quickly and can fix things bit by bit instead of having to gut your system to add a trivial feature later in the process.
I have found the XP principles of rapid iteration and continuous integration to be life savers regardless of what other methodologies are being used.
I won't comment on the obviously volatile issue of licensing however, I would like to point out one way in which cyber cafe's are different from Arcades.
In a cyber cafe, the stations are multipurpose. This means that at any given time, there may be someone quietly researching on the web, reading/. or playing a stimulating game like half-life. When a large group of people are all crowded around playing a stimulating game, there is much more likelyhood of rowdiness or fighting just because of the group dynamic.
Arcades have the ability to control this group dynamic by placing the more stimulating games apart from each other or limiting the number of such games available.
Since cyber cafe's have multipurpose stations, they have much less control over this kind of volatility.
I say if cyber cafes want to avoid being tagged as violent places, they should start organizing their layout so that it is not "comfortable" for a group of excitable kids to feed on each others agression.
I am not saying that this will help reduce actual violence (that's what parents are for), but if people go into cyber cafes and see large groups of rowdy kids pushing and yelling, there will certainly be more of a perception that they are violent places.
The way for cyber cafes to gain a non-violent image is to keep the people who are playing exciting, stimulating games in smaller groups.
I think this is why Cooper advocates the Interaction Designer role. That person would spend time learning the needs and challenges of the customer, but wouldn't actually be the customer. They would be trained to visualize software solutions based on what they learned about the problem. In the kitchen example, somebody with a good eye for spatial relationships might have been able to spot the problem with the island before it got built. It is just a matter of asking which is cheaper, prototyping or having an expert visualizer. It is not quite a fair comparison since visualizing software is much more difficult than visualizing physical objects. On the other hand, prototyping software is much easier than prototyping physical objects.
I agree with Cooper that having Interaction Designers this would dramatically decrease the amount of time spent doing design work because you would get good design in fewer iterations.
I also agree with Beck that there is no substitute for rapid iterations and prototyping. If you give good prototyping tools to the Interaction Designers, then they would work their magic and show a prototype to the customer in the 1-2 week time frame of XP. Then hopefully, you would be able to start coding after you had a couple of prototypes that the customer agrees with.
Of course Sun didn't invent it. What I was trying to say is that they have been pushing the idea through Java for the last few years. I don't event claim that the Sun way or the Java way is the best one, just that it has been relatively successful compared to predecessor intermediate languages like p-code.
since that typically costs orders of magnitude in speed,
I think that Java has shown us that the overhead of using an intermediate architecture like a vm is not an order of magnitude. While there is overhead in both CLR and JVM, technologies like JIT and dynamic optimization have proven themselves effective over the past few years.
I think that the value of binary portability is greatly underestimated and M$ has finally caught on to what Sun has been trying to tell people for a while. That having binary portability is a signifigant improvement over source portability.
As developers it is easy to discount binary portability since recompiling is often considered as a trivial task. This is especially true in the open source community where not only access to the tools for compilation but access to the code is taken for granted.
As users however, most people don't care about what kind of portability software provides, they just want their spreadsheet to run on their pc, and on their handheld, and their phone, or whatever new device comes around. User's view recompilation as an obstruction rather than a convenience (like developers often do).
I think that as time goes on, we are going to see more an more pressure to develop based on CLR and JVM types of intermediate systems since users want it, and the close-source shops want it (so they don't have to deliver source).
Right now, I write all my code to the JVM, (even though I don't always use the Java language) because I have found that is the most convenient way to produce cross platform apps. I am very interested to see how CLR turns out as a truely cross-platform vm compared to JVM.
Sure, some libraries/RTL's take advantage of it (and the compiler may have switches to emit optimized code), but if the standard libraries/RTL's are re-compiled (or even re-written) to take advantage of it, then it's all for nothing.
I think this is one argument in favor of the dynamic compilation in the latest generation of Java VMs (Oracle 9i and Sun's HotSpot).
With this technology, you could swap out the optimization logic in the VM without recompiling the libraries (they are in bytecode). In theory (although I haven't heard about anyone offering this), you could load a processor-specific optimization package when you installed the VM and get all of the advantages of your processor without having to worry about what version of the libraries you were using.
These dynamic compilers are not without tradeoffs, but I do think it solves this type of hardware variability fairly well.
Slashdot Mirror
Definitely both types of optimization provide different benefits. I would never want a world without static optimizers. Dynamic optimization is relatively new and I think we have yet to see what it is really good at.
This is true. The virtual machine oriented dynamic optimizers have farther to go on the optimization front, but are much better at thefeedback-loop aspects. I think eventually the two efforts will meet in the middle. C++ environments will become more "virtualized" with garbage collectors and runtime profilers, while existing virtual environments (like Java) will become more "static" with JITs and native compilers. The (oft abhorred) C# is a good example of this convergence.
This is certainly the case. I (like many other heavy Java users) tend to think that for most cases the tradoff between performance and bug-reducing language features is a worthwhile trade. Of course it always depends on what problems your are trying to solve.
Actually, I think that the best stuff from Lisp is conspicously absent from Java. Perl and Python seem to me to be the inheritors of the really good bits from Lisp.
There is one thing wrong with this process; rebuild. The latest generation of Java dynamic compilation/optimization does its work behind the scenes and happens automatically which I think is a huge advantage over FDPR. It allows the optimizer to adapt to unforseen changes in the production environment.
I think that Hotspot-style dynamic optimization is the future of Java and will eventually overtake statically compiled (or repeatedly compiled) options.
However, Hotspot has a lot to learn from FDPR, like how to keep track of performance metrics across VM sessions. The biggest drawback of current Java dynamic optimizers is that you only get their full potential for long-running processes. Once they get optimization profile management down, the dynamic optimizers like Hotspot are going to look much more appealing on the types of benchmarks like this article uses.
I do know that TV studios often include time compression rights in syndication contracts. So once a show has had its first run, they don't care if the stations cut it during reruns (as long as they keep getting those checks).
I was going to respond to this, but I lost interest after the first sentence.
I can't say for sure that I can notice. It would be interesting to see footage before and after and try to find the microedits.
However, since the article mentions that the process works on duplicate frames, then it seems likely to me that more contiguous frames might be cut from a dramatic pause (with little movement) than from an action shot. If this is the case then the visual difference from a dramatic shot could easily be within the perception of an average viewer.
I wonder how close the relationship is between the publishing scientists and the patent owners?
Does a scientist who publishes first usually get a patent (and presumably royalties)?
Or is the competition confined to the economics of science?
Instead of waiting for large releases to do integration testing or customer approval, you can "tighten the loop" and do faster iterations with the process you already have.
Once you have your use cases and UML and everything, then pick a couple of basic features and build them fast and release them (Don't forget to write automated tests). That way you get customer feedback and integration testing practice quickly and can fix things bit by bit instead of having to gut your system to add a trivial feature later in the process.
I have found the XP principles of rapid iteration and continuous integration to be life savers regardless of what other methodologies are being used.
In a cyber cafe, the stations are multipurpose. This means that at any given time, there may be someone quietly researching on the web, reading /. or playing a stimulating game like half-life. When a large group of people are all crowded around playing a stimulating game, there is much more likelyhood of rowdiness or fighting just because of the group dynamic.
Arcades have the ability to control this group dynamic by placing the more stimulating games apart from each other or limiting the number of such games available.
Since cyber cafe's have multipurpose stations, they have much less control over this kind of volatility.
I say if cyber cafes want to avoid being tagged as violent places, they should start organizing their layout so that it is not "comfortable" for a group of excitable kids to feed on each others agression.
I am not saying that this will help reduce actual violence (that's what parents are for), but if people go into cyber cafes and see large groups of rowdy kids pushing and yelling, there will certainly be more of a perception that they are violent places.
The way for cyber cafes to gain a non-violent image is to keep the people who are playing exciting, stimulating games in smaller groups.
I agree with Cooper that having Interaction Designers this would dramatically decrease the amount of time spent doing design work because you would get good design in fewer iterations.
I also agree with Beck that there is no substitute for rapid iterations and prototyping. If you give good prototyping tools to the Interaction Designers, then they would work their magic and show a prototype to the customer in the 1-2 week time frame of XP. Then hopefully, you would be able to start coding after you had a couple of prototypes that the customer agrees with.
Of course Sun didn't invent it. What I was trying to say is that they have been pushing the idea through Java for the last few years. I don't event claim that the Sun way or the Java way is the best one, just that it has been relatively successful compared to predecessor intermediate languages like p-code.
I think that Java has shown us that the overhead of using an intermediate architecture like a vm is not an order of magnitude. While there is overhead in both CLR and JVM, technologies like JIT and dynamic optimization have proven themselves effective over the past few years.
I think that the value of binary portability is greatly underestimated and M$ has finally caught on to what Sun has been trying to tell people for a while. That having binary portability is a signifigant improvement over source portability.
As developers it is easy to discount binary portability since recompiling is often considered as a trivial task. This is especially true in the open source community where not only access to the tools for compilation but access to the code is taken for granted.
As users however, most people don't care about what kind of portability software provides, they just want their spreadsheet to run on their pc, and on their handheld, and their phone, or whatever new device comes around. User's view recompilation as an obstruction rather than a convenience (like developers often do).
I think that as time goes on, we are going to see more an more pressure to develop based on CLR and JVM types of intermediate systems since users want it, and the close-source shops want it (so they don't have to deliver source).
Right now, I write all my code to the JVM, (even though I don't always use the Java language) because I have found that is the most convenient way to produce cross platform apps. I am very interested to see how CLR turns out as a truely cross-platform vm compared to JVM.
I think this is one argument in favor of the dynamic compilation in the latest generation of Java VMs (Oracle 9i and Sun's HotSpot).
With this technology, you could swap out the optimization logic in the VM without recompiling the libraries (they are in bytecode). In theory (although I haven't heard about anyone offering this), you could load a processor-specific optimization package when you installed the VM and get all of the advantages of your processor without having to worry about what version of the libraries you were using.
These dynamic compilers are not without tradeoffs, but I do think it solves this type of hardware variability fairly well.