Better support for multicore CPUs

[TenPlus1]

shame that the luajit compiler itself couldn't make use of multiple cores when running the mods.

[Astrobe]

I'm thinking... There was a thread about the world being "too small", there is a WIP mod that allows multiple map gen, and several mods that stack "worlds" vertically.

So suppose one slices vertically the world into 4 subworlds with each its own mapgen - direct support in the engine. The subworlds should normally/usually not interact (I know there are a few devils in the details there). Then one could have one thread per subworld.

[Lejo]

I must say my Minetest Server only uses the whole core(s) on startup.
The only one Problem was the auth.txt overflow.
So it depends on the mods, if they are well coded and so on.
But technic servers are always laggy.
Sure this is a Problem of the mods, but minetest should be able to handle some technic mods.

I am for multithreading but only if there is a good and efficient solution.

[sofar]

shame that the luajit compiler itself couldn't make use of multiple cores when running the mods.

Lua has no internal locking at all. It would need a redesign to do that, and that would lower the performance, most likely.

[843jdc]

A server with few players and running few mods that don't do much as fast. The game engine starts lugging when you pile on lots of players, CPU-intensive mods, and a clogged network pipeline.

After 2? years I forget most of the details. I remember (maybe) that areas of the map would operate slowly if that area had lots of mobs or other items while other areas of the map would be very responsive.

Cash's World had a few mods that ate up CPU cycles. Everyone wanted machines to make diamonds. They didn't just want a couple of machines. They wanted a *lot*. Rows and rows of them. And everyone wanted their own personal teleporter. Teleporting somewhere would often result in a blank screen that took some time to clear while the server sent map data to my client. Which was as expected. I was the player jumping around so I should pay a penalty. I assume the server was sending my client the map data for my local area. Is that data compressed?

Players logging in would slow everything down. The server would pause while sending data to a player. Worse if the player was playing using a mobile device while riding in the back of daddy's car cruising down the road switching cell towers :/

Just standing at spawn doing nothing except watching, I would see players pause in-place only to suddenly zip around the map before standing still again. I assume (again) that the server was busy "doing its thing" and pumping out player movements, etc over the network. Network traffic was pretty high. Maxed-out on player logins. Compressing/encoding this data would lessen it and allow more players for a given Internet speed.

I was thinking of multi-threading based on player groupings, say 10 players per thread. But Astrobe's idea sounds better. Have a master server handling the master map. The map is split up into sections, each with its own sub-server with mods running on a thread. Player logins are on a separate thread. When a player log ins, the master server hands off the player to the appropriate sub-server. If any sections starts to bog down, split it up. Make the main map file an index file and that might even allow super-large maps without going to 64 bits :) Mapgen might be a problem. Each map section would(?) have to have access to terrain data from adjacent map blocks. Problem: multiple copies of LUA data tables. nom nom nom here too Someone call Pacman! :)

[sofar]

Is that data compressed?

yes