On Thu, Jul 10, 2014 at 3:26 PM, David Jeske <[email protected]> wrote:
> On Thu, Jul 10, 2014 at 12:51 PM, Jonathan S. Shapiro <[email protected]> > wrote: > >> More serious answer: the fact is that most programmer-driven optimization >> is completely irrelevant to program performance. The reason it's such an >> issue in Scala and Java is that the foundational data structures are so >> inherently inefficient. The JVM incurs such a commitment to memory >> indirection that you can't run it at any sensible speed *without* resorting >> to something as complicated as the hotspot technology. >> > > Agreed... and hotspot doesn't even come close to making up for the memory > indirection follies. Java that handles big data seems to inevitibly resort > to horrible muckery with messy "coordinated arrays" of primitive types to > get around the fact that there are no struts / struct arrays. Things like > storing an array of 3d (x,y,z) vectors as a single float array and using > mod-offsets for x,y.and z. > I agree. And one of the things that concerns me about BitC following v0 is that we may not be able to adopt the approach to boxed/unboxed types that we did there. In v0, you could deference a boxed type to arrive at an unboxed type. This turns out not to interact well with the read-only concept. We're going to have to deal with that in v1.
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
