Re: [julia-users] Re: Help to optimize a loop through a list
Hi Kevin, Thanks! I will add this to my ToDo lists :) Regards, Ronan Em domingo, 3 de maio de 2015 19:14:00 UTC-3, Kevin Squire escreveu: > > Hi Ronan, > > Looks like an interesting package! > > One minor suggestion: if you ever plan to make this an actual Julia > package, it would be good to name it MGEO.jl. All Julia packages use this > naming convention, and it has the additional benefit of making such > packages easily searchable. > > Cheers! >Kevin > > On Sun, May 3, 2015 at 1:33 PM, Ronan Chagas > wrote: > >> Hi guys! >> >> Finally I had time to upload MGEOjulia. >> >> You can see it here: >> >> https://github.com/ronisbr/MGEOjulia >> >> It is available under BSD 3-clause license. >> You can see some test cases under test/mgeojulia_testcases.jl >> >> I would appreciate any suggestion to optimize it :) >> >> Thank you, >> Ronan >> > >
Re: [julia-users] Re: Help to optimize a loop through a list
Hi Ronan, Looks like an interesting package! One minor suggestion: if you ever plan to make this an actual Julia package, it would be good to name it MGEO.jl. All Julia packages use this naming convention, and it has the additional benefit of making such packages easily searchable. Cheers! Kevin On Sun, May 3, 2015 at 1:33 PM, Ronan Chagas wrote: > Hi guys! > > Finally I had time to upload MGEOjulia. > > You can see it here: > > https://github.com/ronisbr/MGEOjulia > > It is available under BSD 3-clause license. > You can see some test cases under test/mgeojulia_testcases.jl > > I would appreciate any suggestion to optimize it :) > > Thank you, > Ronan >
[julia-users] Re: Help to optimize a loop through a list
Hi guys! Finally I had time to upload MGEOjulia. You can see it here: https://github.com/ronisbr/MGEOjulia It is available under BSD 3-clause license. You can see some test cases under test/mgeojulia_testcases.jl I would appreciate any suggestion to optimize it :) Thank you, Ronan
[julia-users] Re: Help to optimize a loop through a list
Integer is an abstract type and thus kills performance if you use it in a type and need to access it frequently. There was discussion somewhere about renaming abstract types like Integer and FloatingPoint to include the name Abstract in them to avoid accidents like this. I guess this shows that it might not be a bad idea. If you see surprising allocations in your program it is likely a type stability issue and if you are on 0.4 the @code_warntype macro is your friend. On Tuesday, April 28, 2015 at 6:17:55 PM UTC+2, Ronan Chagas wrote: > > Sorry, my mistake. Every problem is gone when I change > > nf::Integer > > to > > nf::Int64 > > in type MGEOStructure. > > I didn't know that such thing would affect the performance this much... > > Sorry about that, > Ronan >
[julia-users] Re: Help to optimize a loop through a list
On Tuesday, April 28, 2015 at 11:17:55 AM UTC-5, Ronan Chagas wrote: > > Sorry, my mistake. Every problem is gone when I change > > nf::Integer > > to > > nf::Int64 > > in type MGEOStructure. > > I didn't know that such thing would affect the performance this much... > > Sorry about that, > Ronan > No problem. For future reference (or others coming to this thread in the future): http://julia.readthedocs.org/en/latest/manual/performance-tips/#avoid-containers-with-abstract-type-parameters It is somewhat confusing that Integer is an abstract type. If you're not sure, you can check with the `isleaftype()` method. help?> isleaftype search: isleaftype Base.isleaftype(T) Determine whether "T" is a concrete type that can have instances, meaning its only subtypes are itself and "None" (but "T" itself is not "None"). julia> isleaftype(Integer) false julia> isleaftype(Int) true
[julia-users] Re: Help to optimize a loop through a list
Sorry, my mistake. Every problem is gone when I change nf::Integer to nf::Int64 in type MGEOStructure. I didn't know that such thing would affect the performance this much... Sorry about that, Ronan
[julia-users] Re: Help to optimize a loop through a list
Thank you very much Duane! It will help me a lot.
Right now, I found something that was really slowing down my algorithm.
The original function checkDominance has the following signature:
function checkDominance(mgeoData::MGEOStructure,
candidatePoint::ParetoPoint, paretoFrontier::Array{ParetoPoint,1})
in which
type MGEOStructure
# Number of objective functions.
nf::Integer
# Parameter to set the search determinism.
tau::Float64
# Maximum number of generations.
ngenMax::Float64
# Maximum number of independent runs (reinitializations).
runMax::Float64
# Structure that store the configuration for each design variable.
designVars::Array{DesignVariable,1}
# Epsilon to compare objective functions.
mgeoEps::Float64
end
type DesignVariable
# Number of bits.
bits::Uint32
# Minimum allowed value for the design variable.
min::Float64
# Maximum allowed value for the design variable.
max::Float64
# Full scale of the design variable.
fullScale::Uint64
# Index in the string.
index::Uint64
# Name of the variable.
name::String
end
type ParetoPoint
# Design variables.
vars::Array{Float64,1}
# Objective functions.
f::Array{Float64, 1}
end
In this case, it took almost 62s to find the Pareto Frontier for the
problem mentioned before in which this function is called almost 128,000
times.
After some tests, I decided to change the function signature to:
function checkDominance(nf::Int, eps::Float64, candidatePoint::ParetoPoint,
paretoFrontier::Array{ParetoPoint,1})
Now the code takes now only 2s to optimize the same problem (it is 30x
faster). Just for comparison, optimized (-O3) C++ version takes 0.6s.
Question: Is it expected such slow down when a structure is passed to a
function? I can easily provide a working example if it helps julia devs.
Thanks very much,
Ronan
P.S.: I will upload the entire algorithm this week, I promise :)
Em segunda-feira, 27 de abril de 2015 22:19:21 UTC-3, Duane Wilson escreveu:
>
> Hi Ronan,
>
> Please ignore my last post. I misunderstood (got a little mixed up when
> you were talking about bits) what the issue was, but after reading a little
> more carefully I see where your challenge is. Some of the points in the
> algorithm I showed you before will still be valid but in general here are a
> few points.
>
> From an algorithmic standpoint, you don't actually have to check all
> points against the all points on the frontier to determine if it is on the
> frontier or not. The key to doing this is to make sure your current
> frontier is sorted lexicographically (from best to worst) on
> each objective. After that only you will need to take your current point
> and find where it falls within the sorted frontier. Only points that are
> "above" it can actually dominate the point you're looking to add. So you
> only need to check the points above it in the current Pareto frontier. You
> should check the points above it in reverse order as those are the points
> that most likely to dominate your current point first. Of course if any one
> of those points points dominates your current point you can stop, as that
> point is not on the Pareto frontier.
>
> If you find that no point above the point you're looking at dominates it,
> then you know that point is a part of the Pareto frontier. What you need to
> do now is start to look at the points "below" the point you're adding to
> see if they are dominated by your current point. You can early exit from
> this as soon as you find a point that is not dominated by your new point,
> because all points following it will also not be dominated by it. Then you
> can remove all points your new point dominates from the Pareto frontier.
> The result is a new Pareto frontier with only non-dominated points on it.
>
> That is a lot to say, but the pseudo steps look a little bit like this:
>
> 1) Find position for the new point where it would be placed if sorted into
> the current front. (I'd use a binary search for this at first thought)
> 2) For each point "above" it in the frontier, from last to first, check to
> see if it is dominated. If a point dominates the new point exit.
>
> 3) If the new point is not dominated, check to see which points below it
> that are dominated by the new point. Remove them from the pareto frontier.
> If you find a point that is not dominated by the new point exit.
>
> As an example, I updated the gist with code that does exactly the above
> and added in your example:
>
> f = [ x^2; (x-2)^2 ]
>
> given that -10 < x < 10
>
> 6000 points on the current frontier and determining if 16,000 new points
> should be added to it or not.
>
>
> That part of the code is done in cell 3.
>
> http://nbviewer.ipython.org/gist/dwil/5cc31d1fea141740cf96
>
> Hope this helps you out a bit more.
>
> On Friday, April 24, 2015 at 6:01:31 PM UTC-3, Duane Wilson wrote:
>>
>> Ah I see. Yeah this probab
[julia-users] Re: Help to optimize a loop through a list
Hi Ronan,
Please ignore my last post. I misunderstood (got a little mixed up when you
were talking about bits) what the issue was, but after reading a little
more carefully I see where your challenge is. Some of the points in the
algorithm I showed you before will still be valid but in general here are a
few points.
>From an algorithmic standpoint, you don't actually have to check all points
against the all points on the frontier to determine if it is on the
frontier or not. The key to doing this is to make sure your current
frontier is sorted lexicographically (from best to worst) on
each objective. After that only you will need to take your current point
and find where it falls within the sorted frontier. Only points that are
"above" it can actually dominate the point you're looking to add. So you
only need to check the points above it in the current Pareto frontier. You
should check the points above it in reverse order as those are the points
that most likely to dominate your current point first. Of course if any one
of those points points dominates your current point you can stop, as that
point is not on the Pareto frontier.
If you find that no point above the point you're looking at dominates it,
then you know that point is a part of the Pareto frontier. What you need to
do now is start to look at the points "below" the point you're adding to
see if they are dominated by your current point. You can early exit from
this as soon as you find a point that is not dominated by your new point,
because all points following it will also not be dominated by it. Then you
can remove all points your new point dominates from the Pareto frontier.
The result is a new Pareto frontier with only non-dominated points on it.
That is a lot to say, but the pseudo steps look a little bit like this:
1) Find position for the new point where it would be placed if sorted into
the current front. (I'd use a binary search for this at first thought)
2) For each point "above" it in the frontier, from last to first, check to
see if it is dominated. If a point dominates the new point exit.
3) If the new point is not dominated, check to see which points below it
that are dominated by the new point. Remove them from the pareto frontier.
If you find a point that is not dominated by the new point exit.
As an example, I updated the gist with code that does exactly the above and
added in your example:
f = [ x^2; (x-2)^2 ]
given that -10 < x < 10
6000 points on the current frontier and determining if 16,000 new points
should be added to it or not.
That part of the code is done in cell 3.
http://nbviewer.ipython.org/gist/dwil/5cc31d1fea141740cf96
Hope this helps you out a bit more.
On Friday, April 24, 2015 at 6:01:31 PM UTC-3, Duane Wilson wrote:
>
> Ah I see. Yeah this probably depends a lot on the way you are representing
> the bits and how you split the objectives. If each objective is an
> ASCIIString of bits and they're held separately (i.e. objectives is a
> Vector{ASCIIString}) what I have provided should work because the isless
> function works on strings. It probably isn't the most efficient way to
> compare them however.
>
> On Friday, April 24, 2015 at 1:34:25 PM UTC-3, Ronan Chagas wrote:
>>
>> Hi Duane Wilson,
>>
>> Em sexta-feira, 24 de abril de 2015 11:52:08 UTC-3, Duane Wilson escreveu:
>>>
>>> Actually I was able to get the go ahead from my boss to create a gist of
>>> the code I've produced. I've modified it a little bit, as some of the
>>> things in there are really relevant.
>>>
>>> http://nbviewer.ipython.org/gist/dwil/5cc31d1fea141740cf96
>>>
>>> Any comments for optimizing this a little be more would be appreciated :)
>>>
>>>
>> Thanks very much, it will help me and, if I can contribute, I will tell
>> you :)
>>
>> The problem is that for each generation of this evolutionary algorithm I
>> will need to check if n candidate points belong to the Pareto frontier,
>> where n is the number of bits in the string.
>> Thus, I need a really fast algorithm for this kind of operation. As I am
>> doing now (I will post the code in github), it works fine until the
>> frontier has a large number of elements.
>> Just one example, suppose that I'm using n = 16 and I have 6,000 elements
>> in the frontier. If I generate 1000 generations, then I will need to check
>> if 16,000 points are in the frontier.
>> It will lead to 96,000,000 comparisons considering that no point will be
>> added to the frontier.
>>
>> Thanks,
>> Ronan
>>
>>
[julia-users] Re: Help to optimize a loop through a list
Hi Ronan,
Please ignore my last post. I miss understood (got a little mixed up when
you were talking about bits) what the issue was, but after reading a little
more carefully I see where your challenge is. Some of the points in the
algorithm I showed you before will still be valid but in general here are a
few points.
>From an algorithmic standpoint, you don't actually have to check all points
against the all points on the frontier to determine if it is on the
frontier or not. The key to doing this is to make sure your current
frontier is sorted lexicographically (from best to worst) on
each objective. After that only you will need to take your current point
and find where it falls within the sorted frontier. Only points that are
"above" it can actually dominate the point you're looking to add. So you
only need to check the points above it in the current Pareto frontier. You
should check the points above it in reverse order as those are the points
that most likely to dominate your current point first. Of course if any one
of those points points dominates your current point you can stop, as that
point is not on the Pareto frontier.
If you find that no point above the point you're looking at dominates it,
then you know that point is a part of the Pareto frontier. What you need to
do now is start to look at the points "below" the point you're adding to
see if they are dominated by your current point. You can early exit from
this as soon as you find a point that is not dominated by your new point,
because all points following it will also not be dominated by it. Then you
can remove all points your new point dominates from the Pareto frontier.
The result is a new Pareto frontier with only non-dominated points on it.
That is a lot to say, but the pseudo steps look a little bit like this:
1) Find position for the new point where it would be placed if sorted into
the current front. (I'd use a binary search for this at first thought)
2) For each point "above" it in the frontier, from last to first, check to
see if it is dominated. If a point dominates the new point exit.
3) If the new point is not dominated, check to see which points below it
that are dominated by the new point. Remove them from the pareto frontier.
If you find a point that is not dominated by the new point exit.
As an example, I updated the gist with code that does exactly the above and
added in your example:
f = [ x^2; (x-2)^2 ]
given that -10 < x < 10
6000 points on the current frontier and determining if 16,000 new points
should be added to it or not.
That part of the code is done in cell 3.
http://nbviewer.ipython.org/gist/dwil/5cc31d1fea141740cf96
Hope this helps you out a bit more.
On Friday, April 24, 2015 at 6:01:31 PM UTC-3, Duane Wilson wrote:
> Ah I see. Yeah this probably depends a lot on the way you are representing
> the bits and how you split the objectives. If each objective is an
> ASCIIString of bits and they're held separately (i.e. objectives is a
> Vector{ASCIIString}) what I have provided should work because the isless
> function works on strings. It probably isn't the most efficient way to
> compare them however.
>
> On Friday, April 24, 2015 at 1:34:25 PM UTC-3, Ronan Chagas wrote:
>>
>> Hi Duane Wilson,
>>
>> Em sexta-feira, 24 de abril de 2015 11:52:08 UTC-3, Duane Wilson escreveu:
>>>
>>> Actually I was able to get the go ahead from my boss to create a gist of
>>> the code I've produced. I've modified it a little bit, as some of the
>>> things in there are really relevant.
>>>
>>> http://nbviewer.ipython.org/gist/dwil/5cc31d1fea141740cf96
>>>
>>> Any comments for optimizing this a little be more would be appreciated :)
>>>
>>>
>> Thanks very much, it will help me and, if I can contribute, I will tell
>> you :)
>>
>> The problem is that for each generation of this evolutionary algorithm I
>> will need to check if n candidate points belong to the Pareto frontier,
>> where n is the number of bits in the string.
>> Thus, I need a really fast algorithm for this kind of operation. As I am
>> doing now (I will post the code in github), it works fine until the
>> frontier has a large number of elements.
>> Just one example, suppose that I'm using n = 16 and I have 6,000 elements
>> in the frontier. If I generate 1000 generations, then I will need to check
>> if 16,000 points are in the frontier.
>> It will lead to 96,000,000 comparisons considering that no point will be
>> added to the frontier.
>>
>> Thanks,
>> Ronan
>>
>>
[julia-users] Re: Help to optimize a loop through a list
Ah I see. Yeah this probably depends a lot on the way you are representing
the bits and how you split the objectives. If each objective is an
ASCIIString of bits and they're held separately (i.e. objectives is a
Vector{ASCIIString}) what I have provided should work because the isless
function works on strings. It probably isn't the most efficient way to
compare them however.
On Friday, April 24, 2015 at 1:34:25 PM UTC-3, Ronan Chagas wrote:
>
> Hi Duane Wilson,
>
> Em sexta-feira, 24 de abril de 2015 11:52:08 UTC-3, Duane Wilson escreveu:
>>
>> Actually I was able to get the go ahead from my boss to create a gist of
>> the code I've produced. I've modified it a little bit, as some of the
>> things in there are really relevant.
>>
>> http://nbviewer.ipython.org/gist/dwil/5cc31d1fea141740cf96
>>
>> Any comments for optimizing this a little be more would be appreciated :)
>>
>>
> Thanks very much, it will help me and, if I can contribute, I will tell
> you :)
>
> The problem is that for each generation of this evolutionary algorithm I
> will need to check if n candidate points belong to the Pareto frontier,
> where n is the number of bits in the string.
> Thus, I need a really fast algorithm for this kind of operation. As I am
> doing now (I will post the code in github), it works fine until the
> frontier has a large number of elements.
> Just one example, suppose that I'm using n = 16 and I have 6,000 elements
> in the frontier. If I generate 1000 generations, then I will need to check
> if 16,000 points are in the frontier.
> It will lead to 96,000,000 comparisons considering that no point will be
> added to the frontier.
>
> Thanks,
> Ronan
>
>
[julia-users] Re: Help to optimize a loop through a list
Hi Duane Wilson, Em sexta-feira, 24 de abril de 2015 11:52:08 UTC-3, Duane Wilson escreveu: > > Actually I was able to get the go ahead from my boss to create a gist of > the code I've produced. I've modified it a little bit, as some of the > things in there are really relevant. > > http://nbviewer.ipython.org/gist/dwil/5cc31d1fea141740cf96 > > Any comments for optimizing this a little be more would be appreciated :) > > Thanks very much, it will help me and, if I can contribute, I will tell you :) The problem is that for each generation of this evolutionary algorithm I will need to check if n candidate points belong to the Pareto frontier, where n is the number of bits in the string. Thus, I need a really fast algorithm for this kind of operation. As I am doing now (I will post the code in github), it works fine until the frontier has a large number of elements. Just one example, suppose that I'm using n = 16 and I have 6,000 elements in the frontier. If I generate 1000 generations, then I will need to check if 16,000 points are in the frontier. It will lead to 96,000,000 comparisons considering that no point will be added to the frontier. Thanks, Ronan
[julia-users] Re: Help to optimize a loop through a list
Thanks very much guys! I will post the entire module in github (maybe this weekend if I have time). It will be slow, but then you can help me :) @Mauro The size of vars and f are fixed for each problem, thus I don't think it can be immutable. The dummy example is to find the Pareto frontier of f = [ x^2; (x-2)^2 ] given that -10 < x < 10 Thus, the size of f will be 2 and the size of vars will be 1.
[julia-users] Re: Help to optimize a loop through a list
Actually I was able to get the go ahead from my boss to create a gist of
the code I've produced. I've modified it a little bit, as some of the
things in there are really relevant.
http://nbviewer.ipython.org/gist/dwil/5cc31d1fea141740cf96
Any comments for optimizing this a little be more would be appreciated :)
On Friday, April 24, 2015 at 11:32:09 AM UTC-3, Duane Wilson wrote:
>
> It will definitely help to have the code you're using for this. I've have
> and, am currently doing, a lot of work in Julia on non-dominated sorting,
> so I would be happy to give any help I can. I have a relatively performant
> sorting algorithm I've written in Julia and getting 6000+ points down to
> near 0.5s should be possible.
>
>
>
>
> On Friday, April 24, 2015 at 10:27:08 AM UTC-3, Patrick O'Leary wrote:
>>
>> It's helpful if you can post the full code; gist.github.com is a good
>> place to drop snippets.
>>
>> From what I can see here, there are two things:
>>
>> (1) No idea if this is in global scope. If so, that's a problem.
>>
>> (2) push!() will grow and allocate as needed. It does overallocate so you
>> won't get a new allocation on every single push, but if you know how big
>> the final result will be, you can use the sizehint() method to avoid the
>> repeated reallocations.
>>
>> Please read the Performance Tips page for a longer description of (1) and
>> other information:
>> http://julia.readthedocs.org/en/latest/manual/performance-tips/
>>
>>
>> On Friday, April 24, 2015 at 7:47:38 AM UTC-5, Ronan Chagas wrote:
>>>
>>> Hi guys!
>>>
>>> I am coding MGEO algorithm into a Julia module.
>>> MGEO is a multiobjective evolutionary algorithm that was proposed by a
>>> researcher at my institution.
>>>
>>> I have already a version of MGEO in C++ (
>>> https://github.com/ronisbr/mgeocpp).
>>>
>>> The problem is that Julia version is very slow compared to C++.
>>> When I tried a dummy example, it took 0.6s in C++ and 60s in Julia.
>>>
>>> After some analysis, I realized that the problem is the loop through a
>>> list.
>>> The algorithm store a list of points (the Pareto frontier) and for every
>>> iteration the algorithm must go through every point in this list comparing
>>> each one with the new candidate to be at the frontier.
>>> The problem is that, for this dummy example, the process is repeated
>>> 128,000 times and the number of points in the frontier at the end is 6,000+.
>>>
>>> Each point in the list is an instance of this type:
>>>
>>> type ParetoPoint
>>> # Design variables.
>>> vars::Array{Float64,1}
>>> # Objective functions.
>>> f::Array{Float64, 1}
>>> end
>>>
>>> I am creating the list (the Pareto frontier) as follows
>>>
>>> paretoFrontier = ParetoPoint[]
>>>
>>> and pushing new points using
>>>
>>> push!(paretoFrontier, candidatePoint)
>>>
>>> in which candidatePoint is an instance of ParetoPoint.
>>>
>>> Can anyone help me to optimize this code?
>>>
>>> Thanks,
>>> Ronan
>>>
>>
[julia-users] Re: Help to optimize a loop through a list
It will definitely help to have the code you're using for this. I've have
and, am currently doing, a lot of work in Julia on non-dominated sorting,
so I would be happy to give any help I can. I have a relatively performant
sorting algorithm I've written in Julia and getting 6000+ points down to
near 0.5s should be possible.
On Friday, April 24, 2015 at 10:27:08 AM UTC-3, Patrick O'Leary wrote:
>
> It's helpful if you can post the full code; gist.github.com is a good
> place to drop snippets.
>
> From what I can see here, there are two things:
>
> (1) No idea if this is in global scope. If so, that's a problem.
>
> (2) push!() will grow and allocate as needed. It does overallocate so you
> won't get a new allocation on every single push, but if you know how big
> the final result will be, you can use the sizehint() method to avoid the
> repeated reallocations.
>
> Please read the Performance Tips page for a longer description of (1) and
> other information:
> http://julia.readthedocs.org/en/latest/manual/performance-tips/
>
>
> On Friday, April 24, 2015 at 7:47:38 AM UTC-5, Ronan Chagas wrote:
>>
>> Hi guys!
>>
>> I am coding MGEO algorithm into a Julia module.
>> MGEO is a multiobjective evolutionary algorithm that was proposed by a
>> researcher at my institution.
>>
>> I have already a version of MGEO in C++ (
>> https://github.com/ronisbr/mgeocpp).
>>
>> The problem is that Julia version is very slow compared to C++.
>> When I tried a dummy example, it took 0.6s in C++ and 60s in Julia.
>>
>> After some analysis, I realized that the problem is the loop through a
>> list.
>> The algorithm store a list of points (the Pareto frontier) and for every
>> iteration the algorithm must go through every point in this list comparing
>> each one with the new candidate to be at the frontier.
>> The problem is that, for this dummy example, the process is repeated
>> 128,000 times and the number of points in the frontier at the end is 6,000+.
>>
>> Each point in the list is an instance of this type:
>>
>> type ParetoPoint
>> # Design variables.
>> vars::Array{Float64,1}
>> # Objective functions.
>> f::Array{Float64, 1}
>> end
>>
>> I am creating the list (the Pareto frontier) as follows
>>
>> paretoFrontier = ParetoPoint[]
>>
>> and pushing new points using
>>
>> push!(paretoFrontier, candidatePoint)
>>
>> in which candidatePoint is an instance of ParetoPoint.
>>
>> Can anyone help me to optimize this code?
>>
>> Thanks,
>> Ronan
>>
>
[julia-users] Re: Help to optimize a loop through a list
It's helpful if you can post the full code; gist.github.com is a good place
to drop snippets.
>From what I can see here, there are two things:
(1) No idea if this is in global scope. If so, that's a problem.
(2) push!() will grow and allocate as needed. It does overallocate so you
won't get a new allocation on every single push, but if you know how big
the final result will be, you can use the sizehint() method to avoid the
repeated reallocations.
Please read the Performance Tips page for a longer description of (1) and
other information:
http://julia.readthedocs.org/en/latest/manual/performance-tips/
On Friday, April 24, 2015 at 7:47:38 AM UTC-5, Ronan Chagas wrote:
>
> Hi guys!
>
> I am coding MGEO algorithm into a Julia module.
> MGEO is a multiobjective evolutionary algorithm that was proposed by a
> researcher at my institution.
>
> I have already a version of MGEO in C++ (
> https://github.com/ronisbr/mgeocpp).
>
> The problem is that Julia version is very slow compared to C++.
> When I tried a dummy example, it took 0.6s in C++ and 60s in Julia.
>
> After some analysis, I realized that the problem is the loop through a
> list.
> The algorithm store a list of points (the Pareto frontier) and for every
> iteration the algorithm must go through every point in this list comparing
> each one with the new candidate to be at the frontier.
> The problem is that, for this dummy example, the process is repeated
> 128,000 times and the number of points in the frontier at the end is 6,000+.
>
> Each point in the list is an instance of this type:
>
> type ParetoPoint
> # Design variables.
> vars::Array{Float64,1}
> # Objective functions.
> f::Array{Float64, 1}
> end
>
> I am creating the list (the Pareto frontier) as follows
>
> paretoFrontier = ParetoPoint[]
>
> and pushing new points using
>
> push!(paretoFrontier, candidatePoint)
>
> in which candidatePoint is an instance of ParetoPoint.
>
> Can anyone help me to optimize this code?
>
> Thanks,
> Ronan
>
