I am guessing Warcraft III will not gain too much performance from the 64bit move directly. Diablo III performed a lot better when built for 64bit but there were other engine changes at the same time voiding the tests. Tools such as 7-Zip perform a lot better when built for 64bit. Like wise Simutrans when built for 64bit can perform worse for the same reason, but on some systems (more modern ones) it may actually perform better. For example StarCraft II lost performance when moving from 32bit to 64bit on my system due to the worse cache performance and higher memory bandwidth usage. Only way to know is actual physical benchmarks. This has nothing to do with performance but can potentially allow the game to do more than it currently can. Ignoring the obvious removal of a restrictive memory limit. Actual instructions per clock cycle may be reduced due to worse cache performance and higher memory bandwidth requirements.Cache performance of processors is reduced due to less of the application data fitting inside the cache.Memory footprint of the application will be larger due to larger address sizes.

Potential instructions per clock cycle of the application, the speed at which code can potentially run, can be improved due to instruction set features of 64bit.In other words, it'd be only useful for auxiliary computations that are entirely independent from the game state, depending only on the inputs you give to it.ĭon't get me wrong, I'm all for having the option, I'm just not sure how they're going to pull it off.Ĭlick to expand.Same answer, yes and no. You most definitely would have to jump through weird hoops to send data between threads (channels?), and it's very likely that only one thread would have access to the engine's API. Which, in practice, translates to some ergonomic concessions when trying to use them. Even Lua doesn't really support multithreading, though there are some extensions and libraries that add such support, but even then, they come with some big caveats AFAIK. I also wasn't so much referring to the potential of the users mis-using the API, but rather the inherent challenges associated with providing a thread-safe engine API. Lua does have one in the form of coroutines already.

If you simply want concurrent running tasks, then a single-threaded asynchronous model is preferable. I can't really think of many scenarios where using multiple threads would be a requirement, unless you're doing something really computationally heavy (in which case, perhaps you should be making your own game instead anyway.). In my personal experience with modding, even the most 'demanding' mods don't really need to tap into multi-threading.

Warcraft 3 patch 1.31 download