Not when it comes to GP. One word: bloat.
Later generations are MUCH BIGGER than earlier generations in terms of
total number of nodes.
On Mar 26, 2010, at 12:43 PM, Vlad Palnik wrote:
> The number of generations is irrelevant when it comes to system
> memory, your system
> only runs one generation at a time, you population size is what you
> need to take a look
> at and maybe reducing it or running Island Exchanger? Also even
> though you can increase
> java memory to more than you have on your system and use swap space
> I would not
> recommend it. Your generation runs will slow down significantly,
> your system will
> spend most of the time moving individuals to/from you HD.
> On Wed, Mar 24, 2010 at 6:42 AM, Jason Thomas <[log in to unmask]>
> Try increasing Java heap space with the -Xmx parameter.
> e.g. - java -Xmx500m
> On Wed, Mar 24, 2010 at 5:10 AM, Claes Gyllenswärd <[log in to unmask]
> > wrote:
> 2010/3/24 Bill O'Neil <[log in to unmask]>:
> > Hello,
> > I have a GP which I would like to have run for extended periods of
> > The problem is something I would expect to take possibly months to
> > accurate results. I set it at 500 generations just to test it out
> and I ran
> > out of heap space. I tried upping the heap space memory and it
> > crashed at the same exact spot. Could this be caused by too many
> > generations, or are my trees getting too large?
> > I then lowered the amount of times it loops through the expected
> result and
> > it was able to finish all 500 generations. However, I would like
> to use as
> > much information as possible. Are there any ways I could work
> around this?
> > Possibly running separate 500 generation runs on smaller amounts
> of data
> > then taking the best individuals from each and restarting it using
> the new
> > individuals?
> > Thanks,
> > Bill
> What is the exact error message when the program dies?
> Try using the VisualVM to determine what eats your memory.