(Making an attempt at going back somewhat on topic...)
I think some of the frustration here is also that it's not entirely obvious
even from the performance tips
http://docs.julialang.org/en/latest/manual/performance-tips/ that putting
your code in a function will make such a huge difference.
Exactly my problem here, stuggling to understand what global variables
are in the context of what I see as a script which I assumed was running in
its own context.
I am new to Julia and hardly ever used dynamic languages before so lots of
strange and magic behaviour here for me. Some of my
So, question would be: Is it possible to have an include like command that
puts everthing into its own scope (using let?)?
Am Donnerstag, 24. Juli 2014 15:48:26 UTC+2 schrieb Arnaud Amiel:
Exactly my problem here, stuggling to understand what global variables
are in the context of what I see
I believe this would solve my problem
On Thursday, 24 July 2014 15:02:26 UTC+1, Tobias Knopp wrote:
So, question would be: Is it possible to have an include like command that
puts everthing into its own scope (using let?)
I believe the main problem with the global scope isn't that it's called the
global scope (rather than the scope of a let block), but that the scope is
never terminated during a REPL session, preventing end-to-end analysis of types.
-- John
On Jul 24, 2014, at 7:14 AM, Arnaud Amiel
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.
Anyway, lesson learnt I will now put everything inside functions and will
learn how to use the profiler
Well spotted, not quite right, when not paying attention I regularly get
confused with in and = although in this case it does not really matter.
On Tuesday, 22 July 2014 23:45:21 UTC+1, J Luis wrote:
Hmmm, is this right?
for j in 1:f[i]
Why not view this as a learning opportunity to discover that changes you
perceive to be minor are, in fact, not minor -- but are instead substantive
changes to the semantics of your program?
-- John
On Jul 23, 2014, at 9:38 AM, Arnaud Amiel aam...@gmail.com wrote:
As suggested by a few of
I can see that but it was not directly obvious to me. I guess that is why I
am playing with Julia. Now onto Euler 26 should not be too hard...
On Wednesday, 23 July 2014 17:40:07 UTC+1, John Myles White wrote:
Why not view this as a learning opportunity to discover that changes you
perceive
You don't like getting 32x speed improvements with almost no changes? There are
plenty of languages where things are slow in both global and local scope, in
which case you won't have that problem. I suspect, however, that is not
actually preferable.
On Jul 23, 2014, at 9:38 AM, Arnaud Amiel
On Wed, Jul 23, 2014 at 9:38 AM, Arnaud Amiel aam...@gmail.com 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
There's
https://github.com/JuliaLang/julia/issues/524
https://github.com/JuliaLang/julia/issues/964
And Jeff has mentioned it in his compiler list:
https://github.com/JuliaLang/julia/issues/3440
-Jacob
On Wed, Jul 23, 2014 at 1:18 PM, Kevin Squire kevin.squ...@gmail.com
wrote:
On Wed, Jul
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
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 ste...@karpinski.org
wrote:
I definitely agree that the current status is suboptimal. Lord only knows
I've spent a lot of time thinking about
Admit that you really want to program in OCaml ;-)
On Jul 23, 2014, at 11:39 AM, John Myles White johnmyleswh...@gmail.com
wrote:
I think the difficulty here is that the people who are worst affected by
these kinds of performance changes may be people who also might not know that
they
I for one am thrilled to be able to program every day in such a beautiful,
flexible, clean language with generally good performance and in which
sparkling performance is possible. By comparison, performance instability
is a minor matter.
There, I have thoroughly discredited myself by banal
My inclination is to include type checking and linting in base Julia,
automatically invoked by a paranoid mode that also ignores inbounds
annotations and such. Then the testing infrastructure should run tests in
paranoid mode, linting and type checking the code to be tested. This seems like
a
Live editor/IDE integration of linting (and type-checking) a la Matlab
would be quite nice to have one of these days. Julia seems to self-select
for the type of people who actually listen to suggestions and are willing
to experiment with refactoring and profiling, but I still fear the piles of
I suspect you might find the profiler helpful:
http://julia.readthedocs.org/en/latest/stdlib/profile/
(And the ProfileView.jl package provides a nice visualization of profiler
results--you should check it out too!)
On Tuesday, July 22, 2014 4:47:09 PM UTC-5, Arnaud Amiel wrote:
To learn how
For what its worth, I put everything from
abundantNumbers=Array(Int,1)
to
result
in a function, and ran that function with @time. I got
elapsed time: 0.074687051 seconds
elapsed time: 0.258023294 seconds (22897960 bytes allocated, 4.74% gc time)
which seems right.
On Tuesday, July 22, 2014
I just put all your top-level statements (except for the two helper
functions) into a function of its own:
julia @time main()
elapsed time: 0.162065867 seconds (14434040 bytes allocated)
4179871
I don't think my 5 year old laptop could be *that* much faster than your
computer. Take a look at
21 matches
Mail list logo
