On Thu, Jul 10, 2014 at 10:32 AM, Raoul Duke <[email protected]> wrote:
> How might/can/will Bit-C strive to prevent there being an inflection > point where the developer has to say, "ok, i can't get the performance > i need like this, now i have to start noodling over the weird details > and ripping up my nice abstractions to eke out the performance i need. > If you're trying to reduce stupidity, you should be looking for a geneticist, not a programmer. 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. BitC isn't going to hit the levels of C, because there *is* inherent overhead from type safety. Just for one example, consider array bounds checking. We're doing various things to mitigate that overhead. Some of that will work, some of it won't. The only way to really know is to try. Frankly, I'm much more concerned about compile speed than I am about generated code performance. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
