>
> 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.
That wasn't what I was saying. I like the philosophy behind julia. But in
practice (as of now) even in julia you still have to code in a certain
style if you want very good performance and that's no different than in any
other language. Ideally of course the compiler should be able to optimize
the code so that different styles (e.g. functional/vectorized style vs
imperative/loops style) gives the same performance and the programmer
doesn't have to think about it and maybe one day it will be like that in
julia but we're not quite there yet AFAIK.
Having said that, I like Julia and hopefully it will keep on getting
better/faster. So good job and keep up the good work.
>
>
> On Fri, May 1, 2015 at 11:48 AM, Tim Holy <[email protected] <javascript:>>
> 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
> >
>
