Re: [julia-users] Re: Help needed, running slow
(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. The mechanisms that are responsible for making it so are explained in detail in the very first section (Avoid global variables) but I can understand why especially people new to Julia don't immediately associate this to putting code in a function when measuring performance. Perhaps renaming the section to Avoid global variables, and put your code in functions would help straighten some of these question marks out? //T On Thursday, July 24, 2014 6:29:59 AM UTC+2, Tony Kelman wrote: 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 awful Matlab code I've dealt with over the years with every single line covered in orange underlines (I think we've all been there). Tough balance to strike with if you ignore these, your code will run slowly in a way that doesn't lead to new users just tuning out all advice. On Wednesday, July 23, 2014 3:27:24 PM UTC-7, Stefan Karpinski wrote: 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 good point to have that kind of check automatically since you're already asking for that kind of feedback. Since packages should always have tests, this will also serve to make sure that packages pass type check and lint inspection. On Jul 23, 2014, at 2:05 PM, Sam L sam.l...@gmail.com wrote: I'd be strongly in favor of that, but it would make Julia feel more like one of those static languages for which compilers readily warn you about your bad habits. Maybe Lint and TypeCheck should display their message with a `suggest(blah)` or `hint(blah)` that is printed in purple instead of a red warning. :) On Wednesday, July 23, 2014 12:39:11 PM UTC-7, Bradley Alpert wrote: 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 chatter!
Re: [julia-users] Re: Help needed, running slow
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 problems might be obvious for people here but for not me as the only real programming I have done was device drivers in C and assembly more than 10 years ago. So don't take any of my comments as criticism of the work done on Julia but rather as complete lack of understanding of what is going on and a willingness to learn. I hope no one was offended here and keep up the good work On Thursday, 24 July 2014 12:42:32 UTC+1, Tomas Lycken wrote: (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. The mechanisms that are responsible for making it so are explained in detail in the very first section (Avoid global variables) but I can understand why especially people new to Julia don't immediately associate this to putting code in a function when measuring performance. Perhaps renaming the section to Avoid global variables, and put your code in functions would help straighten some of these question marks out? //T On Thursday, July 24, 2014 6:29:59 AM UTC+2, Tony Kelman wrote: 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 awful Matlab code I've dealt with over the years with every single line covered in orange underlines (I think we've all been there). Tough balance to strike with if you ignore these, your code will run slowly in a way that doesn't lead to new users just tuning out all advice. On Wednesday, July 23, 2014 3:27:24 PM UTC-7, Stefan Karpinski wrote: 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 good point to have that kind of check automatically since you're already asking for that kind of feedback. Since packages should always have tests, this will also serve to make sure that packages pass type check and lint inspection. On Jul 23, 2014, at 2:05 PM, Sam L sam.l...@gmail.com wrote: I'd be strongly in favor of that, but it would make Julia feel more like one of those static languages for which compilers readily warn you about your bad habits. Maybe Lint and TypeCheck should display their message with a `suggest(blah)` or `hint(blah)` that is printed in purple instead of a red warning. :) On Wednesday, July 23, 2014 12:39:11 PM UTC-7, Bradley Alpert wrote: 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 chatter!
Re: [julia-users] Re: Help needed, running slow
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 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 problems might be obvious for people here but for not me as the only real programming I have done was device drivers in C and assembly more than 10 years ago. So don't take any of my comments as criticism of the work done on Julia but rather as complete lack of understanding of what is going on and a willingness to learn. I hope no one was offended here and keep up the good work On Thursday, 24 July 2014 12:42:32 UTC+1, Tomas Lycken wrote: (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. The mechanisms that are responsible for making it so are explained in detail in the very first section (Avoid global variables) but I can understand why especially people new to Julia don't immediately associate this to putting code in a function when measuring performance. Perhaps renaming the section to Avoid global variables, and put your code in functions would help straighten some of these question marks out? //T On Thursday, July 24, 2014 6:29:59 AM UTC+2, Tony Kelman wrote: 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 awful Matlab code I've dealt with over the years with every single line covered in orange underlines (I think we've all been there). Tough balance to strike with if you ignore these, your code will run slowly in a way that doesn't lead to new users just tuning out all advice. On Wednesday, July 23, 2014 3:27:24 PM UTC-7, Stefan Karpinski wrote: 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 good point to have that kind of check automatically since you're already asking for that kind of feedback. Since packages should always have tests, this will also serve to make sure that packages pass type check and lint inspection. On Jul 23, 2014, at 2:05 PM, Sam L sam.l...@gmail.com wrote: I'd be strongly in favor of that, but it would make Julia feel more like one of those static languages for which compilers readily warn you about your bad habits. Maybe Lint and TypeCheck should display their message with a `suggest(blah)` or `hint(blah)` that is printed in purple instead of a red warning. :) On Wednesday, July 23, 2014 12:39:11 PM UTC-7, Bradley Alpert wrote: 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 chatter!
Re: [julia-users] Re: Help needed, running slow
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?)
Re: [julia-users] Re: Help needed, running slow
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 aam...@gmail.com wrote: 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?)
[julia-users] Re: Help needed, running slow
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
[julia-users] Re: Help needed, running slow
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]
Re: [julia-users] Re: Help needed, running slow
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 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
Re: [julia-users] Re: Help needed, running slow
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 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 javascript: 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. Anyway, lesson learnt I will now put everything inside functions and will learn how to use the profiler
Re: [julia-users] Re: Help needed, running slow
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 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. Anyway, lesson learnt I will now put everything inside functions and will learn how to use the profiler
Re: [julia-users] Re: Help needed, running slow
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 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
Re: [julia-users] Re: Help needed, running slow
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 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 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
Re: [julia-users] Re: Help needed, running slow
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 kevin.squ...@gmail.com wrote: 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 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
Re: [julia-users] Re: Help needed, running slow
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 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 kevin.squ...@gmail.com wrote: 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 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
Re: [julia-users] Re: Help needed, running slow
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 should opt in to using Lint/TypeCheck. To get the proper effect from those tools, you probably need to impose them from above by default rather than allow them to be available if asked for. I'd be strongly in favor of that, but it would make Julia feel more like one of those static languages for which compilers readily warn you about your bad habits. -- John On Jul 23, 2014, at 11:35 AM, Patrick O'Leary patrick.ole...@gmail.com wrote: On Wednesday, July 23, 2014 12:49:28 PM UTC-5, Stefan Karpinski 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 suspect some of the reaction amounts to what appears to be performance instability--if small changes can have such large effects, and you don't yet understand why, it can be unsettling because it feels like you're on a knife edge you could fall off of at any moment with one errant keystroke. And you don't know what keystroke that is. A value of developing tools like Lint and TypeCheck are that they can help make the effects of these small changes more transparent.
Re: [julia-users] Re: Help needed, running slow
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 chatter!
Re: [julia-users] Re: Help needed, running slow
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 good point to have that kind of check automatically since you're already asking for that kind of feedback. Since packages should always have tests, this will also serve to make sure that packages pass type check and lint inspection. On Jul 23, 2014, at 2:05 PM, Sam L sam.len...@gmail.com wrote: I'd be strongly in favor of that, but it would make Julia feel more like one of those static languages for which compilers readily warn you about your bad habits. Maybe Lint and TypeCheck should display their message with a `suggest(blah)` or `hint(blah)` that is printed in purple instead of a red warning. :) On Wednesday, July 23, 2014 12:39:11 PM UTC-7, Bradley Alpert wrote: 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 chatter!
Re: [julia-users] Re: Help needed, running slow
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 awful Matlab code I've dealt with over the years with every single line covered in orange underlines (I think we've all been there). Tough balance to strike with if you ignore these, your code will run slowly in a way that doesn't lead to new users just tuning out all advice. On Wednesday, July 23, 2014 3:27:24 PM UTC-7, Stefan Karpinski wrote: 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 good point to have that kind of check automatically since you're already asking for that kind of feedback. Since packages should always have tests, this will also serve to make sure that packages pass type check and lint inspection. On Jul 23, 2014, at 2:05 PM, Sam L sam.l...@gmail.com javascript: wrote: I'd be strongly in favor of that, but it would make Julia feel more like one of those static languages for which compilers readily warn you about your bad habits. Maybe Lint and TypeCheck should display their message with a `suggest(blah)` or `hint(blah)` that is printed in purple instead of a red warning. :) On Wednesday, July 23, 2014 12:39:11 PM UTC-7, Bradley Alpert wrote: 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 chatter!
[julia-users] Re: Help needed, running slow
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 to use Julia, I am running through the project Euler problems (I had already solved most of them using other languages) and up to now, they have all comfortably been solved under 1s without any clever algorithm, even sometimes purposely brute forced. However I am stuck on problem 23 (Find the sum of all the positive integers which cannot be written as the sum of two abundant numbers.) which solves in 8 s. The surprising thing to me is that what I assume to be the hard part is solved in 0.1 s. I have been struggling on and off for the last week but have gone nowhere. I thought a fresh pair of eyes may see something. Here is my code: const maxAbundant = 28123 function sumOfDivisors(n::Int) f = factor(n) counter = 1 for i in keys(f) count = 1 for j in 1:f[i] count += i^j end counter *= count end counter-n end function isAbundant(n::Int) sumOfDivisors(n) n ? true : false end abundantNumbers=Array(Int,1) abundantNumbers[1]=12 sizehint(abundantNumbers, maxAbundant) for i = 13:maxAbundant if isAbundant(i) push!(abundantNumbers, i) end end isSumOfAbundant=falses(1,maxAbundant) tic() for i = 1:length(abundantNumbers) for j = i:length(abundantNumbers) SumOfAbundant = abundantNumbers[i] + abundantNumbers[j] if SumOfAbundant = maxAbundant isSumOfAbundant[SumOfAbundant]=true else break end end end toc() result=0 for i = 1:maxAbundant if !isSumOfAbundant[i] result += i end end result When run with @time I get: elapsed time: 7.967364175 seconds elapsed time: 8.06121492 seconds (1359946448 bytes allocated, 18.32% gc time) So I am convinced the bit between tic() and toc() is not right and gc time may be a clue but I really can't find why. Any help will be greatly appreciated. One thing I find annoying with Julia is that sometimes what seems to me a very insignificant change in the code has dramatic effect in the execution time. It is anyway a great tool to try things and find solutions quickly. I wish I had had Julia when I started on Project Euler. Thanks, Arnaud
[julia-users] Re: Help needed, running slow
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 6:13:40 PM UTC-4, Patrick O'Leary wrote: 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 to use Julia, I am running through the project Euler problems (I had already solved most of them using other languages) and up to now, they have all comfortably been solved under 1s without any clever algorithm, even sometimes purposely brute forced. However I am stuck on problem 23 (Find the sum of all the positive integers which cannot be written as the sum of two abundant numbers.) which solves in 8 s. The surprising thing to me is that what I assume to be the hard part is solved in 0.1 s. I have been struggling on and off for the last week but have gone nowhere. I thought a fresh pair of eyes may see something. Here is my code: const maxAbundant = 28123 function sumOfDivisors(n::Int) f = factor(n) counter = 1 for i in keys(f) count = 1 for j in 1:f[i] count += i^j end counter *= count end counter-n end function isAbundant(n::Int) sumOfDivisors(n) n ? true : false end abundantNumbers=Array(Int,1) abundantNumbers[1]=12 sizehint(abundantNumbers, maxAbundant) for i = 13:maxAbundant if isAbundant(i) push!(abundantNumbers, i) end end isSumOfAbundant=falses(1,maxAbundant) tic() for i = 1:length(abundantNumbers) for j = i:length(abundantNumbers) SumOfAbundant = abundantNumbers[i] + abundantNumbers[j] if SumOfAbundant = maxAbundant isSumOfAbundant[SumOfAbundant]=true else break end end end toc() result=0 for i = 1:maxAbundant if !isSumOfAbundant[i] result += i end end result When run with @time I get: elapsed time: 7.967364175 seconds elapsed time: 8.06121492 seconds (1359946448 bytes allocated, 18.32% gc time) So I am convinced the bit between tic() and toc() is not right and gc time may be a clue but I really can't find why. Any help will be greatly appreciated. One thing I find annoying with Julia is that sometimes what seems to me a very insignificant change in the code has dramatic effect in the execution time. It is anyway a great tool to try things and find solutions quickly. I wish I had had Julia when I started on Project Euler. Thanks, Arnaud
[julia-users] Re: Help needed, running slow
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 the performance tips section for more advice along these lines: http://docs.julialang.org/en/latest/manual/performance-tips/ On Tuesday, July 22, 2014 6:13:40 PM UTC-4, Patrick O'Leary wrote: 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 to use Julia, I am running through the project Euler problems (I had already solved most of them using other languages) and up to now, they have all comfortably been solved under 1s without any clever algorithm, even sometimes purposely brute forced. However I am stuck on problem 23 (Find the sum of all the positive integers which cannot be written as the sum of two abundant numbers.) which solves in 8 s. The surprising thing to me is that what I assume to be the hard part is solved in 0.1 s. I have been struggling on and off for the last week but have gone nowhere. I thought a fresh pair of eyes may see something. Here is my code: const maxAbundant = 28123 function sumOfDivisors(n::Int) f = factor(n) counter = 1 for i in keys(f) count = 1 for j in 1:f[i] count += i^j end counter *= count end counter-n end function isAbundant(n::Int) sumOfDivisors(n) n ? true : false end abundantNumbers=Array(Int,1) abundantNumbers[1]=12 sizehint(abundantNumbers, maxAbundant) for i = 13:maxAbundant if isAbundant(i) push!(abundantNumbers, i) end end isSumOfAbundant=falses(1,maxAbundant) tic() for i = 1:length(abundantNumbers) for j = i:length(abundantNumbers) SumOfAbundant = abundantNumbers[i] + abundantNumbers[j] if SumOfAbundant = maxAbundant isSumOfAbundant[SumOfAbundant]=true else break end end end toc() result=0 for i = 1:maxAbundant if !isSumOfAbundant[i] result += i end end result When run with @time I get: elapsed time: 7.967364175 seconds elapsed time: 8.06121492 seconds (1359946448 bytes allocated, 18.32% gc time) So I am convinced the bit between tic() and toc() is not right and gc time may be a clue but I really can't find why. Any help will be greatly appreciated. One thing I find annoying with Julia is that sometimes what seems to me a very insignificant change in the code has dramatic effect in the execution time. It is anyway a great tool to try things and find solutions quickly. I wish I had had Julia when I started on Project Euler. Thanks, Arnaud
