Latest thoughts on the issue:

https://github.com/JuliaLang/julia/issues/524#issuecomment-49914439


On Wed, Jul 23, 2014 at 10:48 AM, Stefan Karpinski <[email protected]>
wrote:

> I definitely agree that the current status is suboptimal. Lord only knows
> I've spent a lot of time thinking about ways to fix the slow global scope
> issue. Many but by no means all of these thoughts are in the issues Jacob
> linked to. If we figure out a solution that seems to be the right way to do
> it, it will be a really good day. Until then, it seems to me that the point
> of view that it's a bad thing to get a 32x speedup with very little effort
> or change is a lousy way to look at things. A lot of effort has been put
> into allowing that 32x speedup. Not coincidentally, 32x is about how much
> slower Python is for this kind of code; Matlab, R and Octave are slower.
>
> I may have woken up on the wrong side of bed this morning (actually, I'm
> sure of that – I should probably stop answering emails), and I do apologize
> for being sarcastic or snarky about this. It's frustrating when so much
> work has been put into making it *possible* for a high-level dynamic
> language to run this fast and then the main commentary is about how it's
> not always that fast. It is possible to write slow code in any language –
> figuring out how to make your code fast is a learning process in every
> language except the ones where it can't be done.
>
>
> On Wed, Jul 23, 2014 at 10:18 AM, Kevin Squire <[email protected]>
> wrote:
>
>> On Wed, Jul 23, 2014 at 9:38 AM, Arnaud Amiel <[email protected]> wrote:
>>
>>> As suggested by a few of you, I put everything in a function and now it
>>> runs in 1/4 s, that is nearly 32 x improvement for 'no change' that is one
>>> of the aspects I don't like in julia.
>>>
>>
>> I've used Julia for a couple of years now, and am quite used to it, but I
>> very much agree with this sentiment.  I recently introduced Julia to a
>> colleague, and he ran into exactly this issue--that timing direct commands
>> vs. the same commands in a function produce the same results with very
>> different timings.
>>
>> Having used and contributed to Julia for a while, I have a reasonably
>> good understanding of why this is the case and why it hasn't been fixed
>> (and might not be for a while). But I've often found it challenging to
>> convey this to others (especially those coming from languages where types
>> are often hidden, like Matlab).
>>
>> While I know this is on the radar of the main developers, a search didn't
>> yield an issue for better optimization of REPL inputs.  Is there one that I
>> missed?  Should there be?
>>
>>  Cheers,
>>    Kevin
>>
>
>

Reply via email to