Proof-of-concept Genetic Algorithm Optimization Build

Check for duplicates

• I've checked for duplicate issues by using the search function of the issue tracker

Is your feature request related to a problem?

Yes.

Describe the solution you'd like

I did two separate projects. In the first Lua implementation of the UI and the implementation of the genetic algorithm itself in Rust.

https://github.com/Tiikara/path_of_building_genetic_genetic_lualib - genetic library on rust for lua
https://github.com/Tiikara/pathofbuildinggenetic - PoB with genetic

Describe alternatives you've considered

No response

Additional context

Currently implemented:

• Genetic algorithm
• Multithreaded calculation
• UI interface for setting the values the genetic algorithm will aim for
• Saving the genetic algorithm settings in Build xml
• Displaying the best results in the UI during the optimization process
• Use of conventional nodes
• Using ascendence nodes
• Using mastery nodes

Current issues:

• Slow performance due to long shortest path search (the algorithm takes 20 minutes on my Intel Core i9 12900k and uses 8 gigabytes of memory)
• Memory leak on optimization restart

What needs to be done before merge:

• My fork uses the 64bit architecture and luajit2.1 from https://github.com/openresty/luajit2. Can we already recompile the project to 64bit? :)

The 64bit architecture is necessary because of threads' memory usage. The luajit2.0 used in the project now cannot allocate more than 2 Gbytes of memory, that's why I chose https://github.com/openresty/luajit2 without this limitation.

Project dependencies (runtime_x64) https://github.com/Tiikara/pathofbuildinggenetic compiled with Visual Studio 2019

Commencez par le fork pathofbuildinggenetic lié et ses dépendances runtime_x64, puis comparez la Lua UI et la bibliothèque génétique Rust avec la configuration LuaJIT 2.0 du projet principal. Reproduisez le workflow d’optimisation et étudiez le temps d’exécution de 20 minutes signalé, l’utilisation élevée de la mémoire et la fuite lors du redémarrage. Le travail sera considéré comme terminé lorsqu’un plan de merge pour la prise en charge de 64-bit sera défini et qu’un accord aura été trouvé sur les problèmes restants de performances et de mémoire.