On Monday, September 8, 2014 12:37:16 PM UTC-4, Tony Kelman wrote: > > Calm down. It's very easy to match Octave here, by writing the standard > library in C. Julia chose not to go that route. Of course everyone would > like the concise vectorized syntax to be as fast as the for-loop syntax. If > it were easy to do that *without* writing the standard library in C, it > would've been done already. In the meantime it isn't easy and hasn't been > done yet, so when someone asks how to write code that's faster than Octave, > this is the answer. >
Haha, why do I come across as combative??? HUH? Oh wait that's kind of combative. But, wait,from above I think it's been illustrated that a C-based rewrite is not necessary, but the current form is no good. > > There have been various LLVM bugs regarding automatic optimizations of > converting small integer powers to multiplications. "if y == 2" code really > shouldn't be necessary here, LLVM is smarter than that but sometimes fickle > and buggy under the demands Julia puts on it. > Apparently. For some additional info. Check this out if you change the Octave example to this: >> tic;y=x.^2.1;toc Elapsed time is 1.80085 seconds. Now it's slower than Julia. Like you said, you can't trust LLVM on everything, so the question is what to do about it? > > And in this case the answer is clearly a reduction for which Julia has a > very good set of tools to express efficiently. If your output is much less > data than your input, who cares how fast you can calculate temporaries that > you don't need to save? > I think this is missing the point and concentrating on optimizing the wrong thing or possibly I'm missing your point. Here's my point Everyone coming from Octave/Matlab will expect and should expect that X.^2 is usable and just as fast.
