MC-Server on Raspberry Pi

[FakeTruth]

Wow, that's crazy o_O

Isn't that a bug in gcc then?

[xoft]

I don't know. I don't know what the C++ standard says on this matter (two structures of the same name in different compilation units). I want to ask around at work, we've got some guys who are really into cutting-edge C++ standard knowledge

---

According to the standard, GCC was right. The standard dictates, in the so called "one definition rule", that a structure, if defined in multiple translation units, must be defined with exactly the same tokens. Otherwise it's an undefined behavior (so we were lucky that our RasPis didn't explode

[FakeTruth]

Well, great find. I never knew

[xoft]

Actually it makes (a lot of) sense - since C++ allows you to put method definitions anywhere, it has to mangle symbol names independent of filename. So if each of those structures contained a function of the same name, both functions would mangle to the same name and therefore would have been doubly defined, from the linker's viewpoint. Unfortunately for us, I was using those structures only for data storage, so the linker couldn't catch this.

Well, now that I see that MCServer works on the Pi as a charm, I can sell my Pi in peace

[FakeTruth]

Haha, getting rid of it so soon

[xoft]

Just for fun I ran a profiled version of MCServer on the RasPi. Quite unexpectedly, The function eating up the most time was the lighting thread's PrepareSkyLight() function with 17 % of the run time. Who would've thought?
Here's the list of top time-eaters. Notice how the generators are actually doing rather well.

Code:

%   cumulative   self              self     total          
time   seconds   seconds    calls   s/call   s/call  name    
17.84     10.22    10.22      398     0.03     0.03  cLightingThread::PrepareSkyLight
12.50     17.38     7.16      882     0.01     0.02  deflate_slow
10.77     23.55     6.17  1217115     0.00     0.00  cCaveTunnel::ProcessChunk
10.10     29.34     5.79    15968     0.00     0.00  fill_window
  8.38     34.14     4.80  1345982     0.00     0.00  longest_match
  8.25     38.87     4.73      422     0.01     0.04  cLightingThread::LightChunk
  5.85     42.22     3.35   370359     0.00     0.00  cHeiGenBiomal::GetHeightAt
  5.69     45.48     3.26     8901     0.00     0.00  cLightingThread::CalcLightStep
  4.08     47.82     2.34      484     0.00     0.00  cChunk::CreateBlockEntities
  2.34     49.16     1.34      478     0.00     0.02  cStructGenTrees::GenStructures
  2.09     50.36     1.20  1775634     0.00     0.00  cNoise::CubicNoise2D
  1.75     51.36     1.00     6123     0.00     0.00  adler32
  1.66     52.31     0.95   726731     0.00     0.00  cBioGenVoronoi::VoronoiBiome
  1.43     53.13     0.82   426000     0.00     0.00  cNoise::CubicNoise3D
  1.20     53.82     0.69     1814     0.00     0.00  cIniFile::FindValue
  0.98     54.38     0.56    34071     0.00     0.00  cStructGenRavines::cRavine::ProcessChunk
  0.59     54.72     0.34      484     0.00     0.01  cStructGenWormNestCaves::GenStructures
  0.54     55.03     0.31      866     0.00     0.00  compress_block

I guess the ARM architecture is good for math programming, but not so good for memory access. PrepareSkyLight jumps all over more than a 600 KiB block of memory, reading it and writing to it byte-wise. Generators usually take a few numeric values and chew them over and over until they get a final number out of it, and that's where a many-register platform wins.

I'd like to run a few more tests on this - to see if there's any kind of RAM cache somewhere in there, if it's better to access the memory consecutively or it is the same as accessing it randomly.

[TheCreeper]

On the latest revision im getting an error when attempting to compile.

Code:

[loxoko@Apollo mc-server]$ make release=1
/usr/bin/g++ -s -O3 -c -I. -Isource -Isource/md5 -IWebServer -Isource/packets -Isource/items -Isource/blocks -Itolua++-1.0.93/src/lib -Ilua-5.1.4/src -Izlib-1.2.7 -IiniFile -Itolua++-1.0.93/include -Ijsoncpp-src-0.5.0/include -Ijsoncpp-src-0.5.0/src/lib_json -Isquirrel_3_0_1_stable/include -Isquirrel_3_0_1_stable -Isquirrel_3_0_1_stable/sqrat squirrel_3_0_1_stable/squirrel/sqtable.cpp -o build/release/squirrel_3_0_1_stable/squirrel/sqtable.o
In file included from squirrel_3_0_1_stable/squirrel/sqpcheader.h:16:0,
                 from squirrel_3_0_1_stable/squirrel/sqtable.cpp:4:
squirrel_3_0_1_stable/squirrel/sqobject.h: In member function ‘void SQObjectPtr::Null()’:
squirrel_3_0_1_stable/squirrel/sqobject.h:294:16: warning: converting to non-pointer type ‘SQRawObjectVal {aka unsigned int}’ from NULL [-Wconversion-null]
In file included from squirrel_3_0_1_stable/squirrel/sqobject.h:5:0,
                 from squirrel_3_0_1_stable/squirrel/sqpcheader.h:16,
                 from squirrel_3_0_1_stable/squirrel/sqtable.cpp:4:
squirrel_3_0_1_stable/squirrel/squtils.h: In instantiation of ‘sqvector<T>::~sqvector() [with T = int]’:
squirrel_3_0_1_stable/squirrel/sqclosure.h:142:52:   required from here
squirrel_3_0_1_stable/squirrel/squtils.h:46:4: error: ‘sq_vm_free’ was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive]
In file included from squirrel_3_0_1_stable/squirrel/sqpcheader.h:17:0,
                 from squirrel_3_0_1_stable/squirrel/sqtable.cpp:4:
squirrel_3_0_1_stable/squirrel/sqstate.h:143:6: note: ‘void sq_vm_free(void*, SQUnsignedInteger)’ declared here, later in the translation unit
In file included from squirrel_3_0_1_stable/squirrel/sqobject.h:5:0,
                 from squirrel_3_0_1_stable/squirrel/sqpcheader.h:16,
                 from squirrel_3_0_1_stable/squirrel/sqtable.cpp:4:
squirrel_3_0_1_stable/squirrel/squtils.h: In instantiation of ‘void sqvector<T>::_realloc(SQUnsignedInteger) [with T = int; SQUnsignedInteger = unsigned int]’:
squirrel_3_0_1_stable/squirrel/squtils.h:34:4:   required from ‘void sqvector<T>::copy(const sqvector<T>&) [with T = int]’
squirrel_3_0_1_stable/squirrel/sqclosure.h:161:34:   required from here
squirrel_3_0_1_stable/squirrel/squtils.h:105:3: error: ‘sq_vm_realloc’ was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive]
In file included from squirrel_3_0_1_stable/squirrel/sqpcheader.h:17:0,
                 from squirrel_3_0_1_stable/squirrel/sqtable.cpp:4:
squirrel_3_0_1_stable/squirrel/sqstate.h:142:7: note: ‘void* sq_vm_realloc(void*, SQUnsignedInteger, SQUnsignedInteger)’ declared here, later in the translation unit
make: *** [build/release/squirrel_3_0_1_stable/squirrel/sqtable.o] Error 1
[loxoko@Apollo mc-server]$

[xoft]

THat is most certainly strange, the Squirrel engine and bindings haven't been touched for a while, so that should not be happening. I'll try compiling rev 730 if it reports the same problem here.

What OS release and gcc version are you using? So far we've all tried on the Raspbian image with gcc 4.6.

[TheCreeper]

Im compiling on Archlinux with gcc version 4.7.

[xoft]

It seems like a bug in the Squirrel library that is not C++-standard compatible and the new gcc version detected that. Try opening the GNUmakefile and adding "-fpermissive" to CXX_OPTIONS on lines 43, 53, 63 and 73; gcc should allow that code then.