My only concern is that handling these objects is putting both stress on the GC (stack allocation is not perfect yet) and on code verbosity (due to the lack of operator overloading). To me it feels like I’m forced to do ‘boxing and unboxing’ that angle every time I access it. I think that solely for that reason I’d stick to ‘float angle’ in most of the cases. In C++ it’d be a lot less of a burden to make the switch.
Yeap. A very real concern which is avoidable in C++: no GC (well by default), new abuse, custom allocators and…umm…oh yeah! structures! Golly wouldn’t that be nice. Of course the same holds for all small object allocations. But that’s really a different subject to my brain.
Yeap. A very real concern which is avoidable in C++: no GC (well by default), new abuse, custom allocators and…umm…oh yeah! structures! Golly wouldn’t that be nice. Of course the same holds for all small object allocations. But that’s really a different subject to my brain.
Well, you could switch to Scala. Then you have operator overloading. Also modern JVMs can optimize this kind of stuff really well. On the Java 7 server VM there is no performance difference between boxing the values in objects all over the place and keeping them unboxed as doubles. All the object allocations are optimized away where possible, Data is automatically put on the stack instead of the heap, etc.
Well, you could switch to Scala. Then you have operator overloading. Also modern JVMs can optimize this kind of stuff really well. On the Java 7 server VM there is no performance difference between boxing the values in objects all over the place and keeping them unboxed as doubles. All the object allocations are optimized away where possible, Data is automatically put on the stack instead of the heap, etc.
For the time being all JVM languages are in the same boat w/r to the GC/cache-coherency issue. The only choice to to flatten the state data into a container and perform code replication and/or create synthetically methods to eliminate the operations. So you either do that, or wait for the invokedynamic framework to evolve enough to give the equivalent of limited pointer manipulation…ala some stuff mentioned in that arrays 2.0 presentation.
For the time being all JVM languages are in the same boat w/r to the GC/cache-coherency issue. The only choice to to flatten the state data into a container and perform code replication and/or create synthetically methods to eliminate the operations. So you either do that, or wait for the invokedynamic framework to evolve enough to give the equivalent of limited pointer manipulation…ala some stuff mentioned in that arrays 2.0 presentation.