Steven -- I agree and I find it very refreshing that you're willing to judge a language by more than just performance. Any given language can always be optimized better, so ideally you want to compare them by more robust criteria.
Obviously a particular system might have a well-tuned library routine that's faster than our equivalent. But think about it: is having a slow interpreter, and relying on code to spend all its time in pre-baked library kernels the *right* way to get performance? That's just the same boring design that has been used over and over again, in matlab, IDL, octave, R, etc. In those cases the language isn't bringing much to the table, except a pile of rules about how important code must still be written in C/Fortran, and how your code must be vectorized or shame on you. On Fri, May 1, 2015 at 11:48 AM, Tim Holy <[email protected]> wrote: > On Friday, May 01, 2015 08:03:31 AM Scott Jones wrote: >> Still, same issue as I described above... probably better to increase by 2x >> up to a point, and then by chunk sizes, where the chunk sizes might slowly >> get larger... > > I see your point, but it will also break the O(nlogn) scaling. We couldn't > hard-code the cutoff, because some people run julia on machines with 4GB of > RAM > and others with 1TB of RAM. So, we could query the amount of RAM available and > switch based on that result, but since all this would only make a difference > for operations that consume between 0.5x and 1x the user's RAM (which to me > seems like a very narrow window, on the log scale), is it really worth the > trouble? > > --Tim >
