data was measured (for example if the original Quake II executable compiled in 1997 was used, which may be considered bad as current C compilers may achieve better optimizations for Quake), it notes how the same Java source code can have a huge speed boost just by updating the VM, something impossible to achieve with a 100% static approach. For other programs, the C++ counterpart can, and usually does, run significantly faster than the Java equivalent. A benchmark performed by Google in 2011 showed a factor 10 between C++ and Java. At the other extreme, an academic benchmark performed in 2012 with a 3D modelling algorithm showed the Java 6 JVM being from 1.09 to 1.91 times slower than C++ under Windows. Some optimizations that are possible in Java and similar languages may not be possible in certain circumstances in C++: C-style pointer use can hinder optimizing in languages that support pointers, The use of escape analysis methods is limited in C++, for example, because a C++ compiler does not always know if an object will be modified in a given block of code due to pointers, Java can access derived instance methods faster than C++ can access derived virtual methods due to C++'s extra virtual-table look-up. However, non-virtual methods in C++ do not suffer from v-table performance bottlenecks, and thus exhibit performance similar to Java. The JVM is also able to perform processor specific optimizations or inline expansion. And, the ability to deoptimize code already compiled or inlined sometimes allows it to perform more aggressive optimizations than those performed by statically typed languages when external library functions are involved. Results for microbenchmarks between Java and C++ highly depend on which operations are compared. For example, when comparing with Java 5.0: 32 and 64 bit arithmetic operations, File I/O and Exception handling, have a similar performance to comparable C++ programs Arrays operations performance are better in C. Trigonometric functions performance is much better in C. Notes Multi-core performance The scalability and performance of Java applications on multi-core systems is limited by the object allocation rate. This effect is sometimes called an "allocation wall". However, in practice, modern garbage collector algorithms use multiple cores to perform garbage collection, which to some degree alleviates this problem. Some garbage collectors are reported to sustain allocation rates of over a gigabyte per second, and there exist Java-based systems that have no problems scaling to