x86-64 Builds

[MechWarrior001]

Last time I checked it is possible to build a x86-64 executable, but it has to be written to take advantage of the additional abilities. That being said, can Mineserver use x86-64 abilities or are those not coded in yet?

[Manhim]

What abilities?

[Ben S.]

Last time I checked it is possible to build a x86-64 executable, but it has to be written to take advantage of the additional abilities. That being said, can Mineserver use x86-64 abilities or are those not coded in yet?

You wouldn't really see drastic advantages with a 64 bit build.  However if the dependencies (libevent and libnoise) utilized all the advantages 64 bit provides, then you might see a decent decrease in time it takes to generate terrain and poll events and such.

Right now this project is already miles ahead in terms of performance than the official minecraft server.  This would be something that would be implemented once a completely stable 32 bit version is complete.

[MechWarrior001]

What abilities?

Well, these specific examples don't apply to Mineserver itself, but some x86-64 builds of games can, as a result of the extra available resources, produce longer visual distances, reduce loading times, etc.

A properly coded 64bit Mineserver could have exponentially faster map generation and NPC calculation times than a 32bit server, even if both are running on the exact same hardware.

At least that is what I understand.

[ReDucTor]

People should use standard types like 'int' or even 'long' where size is not required, this provides more flexibility, I have seen some people using uintXX in some loops (you people know who you are), these things should be avoided.

Speed is not gained by 64-bit processing, but speed is gained by making code which doesn't need to be emulated on a 64-bit machine, if someone is wanting to run a 64-bit version of mineserver they can compile it them selves, when we reach a more public release I'm sure we can have package releases for both 64-bit and 32-bit.

Some things like map generation are done using libnoise, which internally used doubles, most FPUs are 80-bit FPUs regardless of what you through into them, however speed will sometimes differ depending on things like strictness settings if things where using floats over doubles.

Such things are minimal optimizations and should not be the first thought for anyone, I believe its more important that people focus on major flaws in speed with some peoples programming style (e.g. ftol everywhere)

If we can get a programming standard created to help eliminate and some peoples potentially slower coding this would be useful, at some time during the coming holidays I'll probably jump in and refactor some of the slower points.

[deoxxa]

I have seen some people using uintXX in some loops (you people know who you are)

>_>
<_<
>_>

[krono]

On my OS X, mineserver gets compiled as x86_64 by default and
I haven't noticed any problems.

A Question:
What is the problem with uintXX?
Did you mean uintXX_t like in http://en.wikipedia.org/wiki/Stdint.h (or its C++ equivalent cstdint)?
  FWIW, I like size_t loop variables.

[ReDucTor]

We have an typedefs which are very much the same, using these types means that the compiler will implement checks and typecast equivalent code which is completely unnecessary, size_t is a much better alternative.

[Fador]

64bit windows binary built: http://mineserver.be/downloads/mineserver_20101216003400_9a5dd6df_x64_VS2010.zip

The build pack (http://mineserver.be/downloads/mineserver-VS2010_build_pack.zip) also contains everything needed for building 32/64bit version with VC2010 (get from http://www.microsoft.com/express/Windows/).