Minetest optimization and running it on a R-Pi2 B

[greencopper]

Yesterday I got a Raspberry Pi 2 B model and I had really hoped it could have run Minetest as a server since it can run both Minecraft and Voxelands without problems.

However, even with optimization there is still a lot of lag.

I have noticed that much lag appears with people are crafting stuff and continuing pressing the left mouse button to get several items crafted. Also a lot of lag apears when people are opening and closing doors.

This seems to me that this is a coding optimization problem and not a hardware problem.

Being able to run Minetest on a R-Pi2 should be possible and I really hope more work will go into optimization on the server part and network protocol part.

Anyone who got it running succelfully on low power hardware?

Also is there a way to debug the code while running the server part to determine bottlenecks if any? I have done optimization on other languages, but not on C++. In this case I am talking about run-time debugging displaying function/method calls etc.

[rubenwardy]

Valgrind is a way of seeing where the program spends it's time. Crafting is known to be badly optimised, it's being worked on.

[Ivà]

Well, here you have a map that was done with an R-Pi:

viewtopic.php?f=12&t=11291

Some optimization tips in that thread too, but yes, crafting using an R-Pi as a server is a pain. And generating new map is slow (but hey, R-Pi has very limited cpu power).

[Sokomine]

If crafting is such a pain, perhaps less receipes (reduced crafting grid?) plus traders which sell more complex items might help a bit. An entirely diffrent crafting system could also be of intrest.

I'd love to know how my mg_villages, a mod that works with a lua-based mapgen, will behave on a Raspberry Pi 2.

What impact do flowers have? And leafdecay?

[Zeno]

Also is there a way to debug the code while running the server part to determine bottlenecks if any? I have done optimization on other languages, but not on C++. In this case I am talking about run-time debugging displaying function/method calls etc.

Here is one of my tests (I have a few but this is a nice simple one)

Your phone or window isn't wide enough to display the code box. If it's a phone, try rotating it to landscape mode.

Code: Select all

valgrind --tool=callgrind --instr-atstart=no --dump-instr=yes --collect-jumps=yes \
        /home/zeno/minetest/bin/minetestserver \
        --config ~/.minetest/disk_test.conf --world ~/.minetest/worlds/disk_test


I use the --instr-atstart = no switch so that I can start the profiling when I want (after all the init stuff usually). If you want to capture data for the entire execution, simply omit the switch (or change it to --instr-atstart = yes).

Note that, for callgrind, you should build the release build of minetest server but add the -g switch to the gcc/clang options. I.e. callgrind is really designed for collecting data for programs that have been built with optimisation.

Omit the callgrind_control commands below if you don't use the --instr-atstart=no switch

After minetestserver is running, to start collecting data (start instrumentation), run

Your phone or window isn't wide enough to display the code box. If it's a phone, try rotating it to landscape mode.

Code: Select all

callgrind_control -i on


To turn it off

Your phone or window isn't wide enough to display the code box. If it's a phone, try rotating it to landscape mode.

Code: Select all

callgrind_control -i off


The data will be dumped in the directory you run valgrind from with the filename callgrind.out.PID

You can certainly (try to) read that file but not many people would get very far. I use KCachegrind to visualise the collected data.

There is a lot you can do with callgrind (including separating the data by thread)... best to start here: http://valgrind.org/docs/manual/cl-manual.html for stuff more advanced than the example I gave at the top of this post.

Edit: You don't need to add the -g switch to the compiler options but it's very beneficial; with it added you can look at the cost of things inside functions so you get a lot more detail.

[Ivà]

I'd love to know how my mg_villages, a mod that works with a lua-based mapgen, will behave on a Raspberry Pi 2.

I PM you.

As for the flowers and leafdecay, how should I measure performance?