My suggestion is to write a short test script using these modules and the other suggestions we've given (i.e., use the strict and warnings pragmas and not to use symbolic references) to work out the issue with each thread updating the same var and when/if you have trouble post that test script and a new question regarding that new problem. Once those issues are worked out, we can work on integrating those fixes in your current script.

I managed to sort of get it running, however I have to avoid using join() or detach(), and within about 30 seconds my memory becomes full and the program errors and quits. I've ran it in linux, which gave me a "pthread_create returned 11" error, which confirms that there are too many threads being created.

Thank you for taking the time to help me out, this code is starting to drive me insane :)

I'm not sure if multi threading is really giving me any performance gain? I timed multiple runs and the threaded version was on average 5x slower, however because of the memory leak it's obvious it isn't working properly so it may not have been a representative sample of what is really possible.

How difficult would a thread pool be to implement? I only need 5 - 10 threads running at a time.

I already profiled my code, the scoring subroutine was the slowest so I decided to thread that, so instead of it waiting to score image 1, then image 2 ... 10, it could have 10 threads running the subroutine.

Someone who attempted something very similar to me suggested I store the images in a 2d array, I did that and got a 35% improvement in speed, I'm attempting a complete overhaul of the code to see if I can push that further.

I was thinking maybe the GD library wasn't thread safe, but from what I've read there was a feature which wasn't (that I didn't use), but it's already been patched.

While you work on overhauling the code, you may want to take these things into consideration.

1) You're calling your main() sub prior to declaring/initializing the file scoped vars that the sub uses and you have way too many of those vars.

2) The use of a main() sub is unneeded and only servers to add unnecessary indentation.

3) Every sub is accessing file scoped vars directly, which is a bad coding practice. You should a) declare your vars in the smallest scope that they require and b) pass globally scoped vars to subs rather than accessing them directly.

4) You have way too much duplication of code. Instead of having individual subs that update a specific var, you should make the subs more generic and pass in vars by reference. That alone would mean you could drop most of those subs.

5) The C style for loop is very verbose and looks cluttered. It's much cleaner and easier to use Perl's style of the for loop.

6) I suspect that the multiple use of nested for loops could be the source of part of the slowdown. I have not analyzed them enough, but I'm pretty sure that those blocks can be reworked to reduce the amount of looping.

7) Your save_genes() sub looks pretty inefficient. The use of the join function could help in cleaning up or getting rid of those for loops. It might be better and more efficient to build up a data structure and then dump that to the file in one print statement.

With more analysis, I could probably come up with more things to consider, but that should be enough to get started.