Random Chitchat 2012-2016

[xoft]

I've just tried implementing a Simplex noise, and now I have mixed feelings about it. I was expecting it to be slower than our current noise implementation for our specific usage scenarios (generating a 3D array of values close to each other), but the actual slowness is overwhelming - our current noise is so much optimized that it is 11 times faster than the Simplex noise (!) Not bad for an algorithm that is supposed to be much slower

The main reason behind this result (and behind my initial assumption) is the usage scenario - we ask the noise generator for many values close to each other. Our noise implementation has been highly optimized for this, caching whatever values it can. Unfortunately, I can't see how the Simplex noise could be optimized in the same way, it doesn't use a regular grid so it cannot cache anything, it must painfully calculate each and every value.

Remind me to pat myself on the shoulder, this noise optimization is really something I could be proud of

[NiLSPACE]

Too bad the Simplex noise can't be optimized as much.

It would be pretty cool if you could simply change the used noise for a generator though. We'd have to re-organize the Noise class to be some kind of interface which other classes inherit from. That way we could simply do something like this:

switch (inifile.GetValueSet("Generator", "BiomalNoise3DNoiseType", "Cubic")) 
{
    case "Cubic": 
    {
        m_Noise = CubicNoise(seed);
        break;
    }
    case "Simplex": 
    {
        m_Noise = SimplexNoise(seed);
        break;
    }
}

[xoft]

I didn't say it couldn't be optimized, I just said that I don't currently see a way. It may well be possible to make it much faster.

A solution similar to yours should be possible, just templatize the BiomalNoise3D class to take the underlying noise as a template parameter (and implement a Simplex noise class that provides the same interface as the cInterp5DegNoise class (like in the NoiseSpeedTest project), then you could create the proper class in runtime. I personally don't think it's worth it, but what do I know, maybe the Simplex noise is visually much better than what we have. No other way to find out other than implementing it

[xoft]

While exploring the cClientHandle issues, I ran into something weird: The std::recursive_mutex::lock() is throwing a system error back at me on my Ubuntu. I mean, wtf, if even a simple mutex is not working, then what?!?

[NiLSPACE]

It seems Microsoft has released the VS2017 Release candidate: https://www.visualstudio.com/en-us/news/...tes#willow

[Seadragon91]

@xoft Looking at the description of std::recursive_mutex::lock(), it can throw three errors:

• A deadlock was detected (implementations may detect certain cases of deadlock).
  
• The thread does not have privileges to perform the operation.
  
• The native handle type manipulated is already locked.
  

Source: http://www.cplusplus.com/reference/mutex...utex/lock/

[xoft]

@Seadragon91 It has thrown a system error code 22, which, in my understanding, is EINVAL on Ubuntu Xenial 64-bit. Since I've also seen a malloc failure in another debugging session, I suspect a memory corruption somewhere. Perhaps a valgrind session is in order.

[xoft]

I believe I've fixed one huge pain in our collective a**es - the cClientHandle race conditions. I did test this extensively, but still would appreciate more people going through the changes: https://github.com/cuberite/cuberite/pull/3439

Mostly, the change is about adding a cCriticalSection wrapped around cClientHandle's m_State, so that each write is protected. If such a write depends on a previous read, the read is included in the CS lock. Still, there are places where the value of m_State is not as important (say, when deciding what chunks to send next, it's not exactly important if the client has just disconnected - the chunk will be chosen and then the clienthandle destroyed anyway), so there are places where it makes sense to read the m_State value without holding the CS. For that reason, m_State is kept as a std::atomic.

[NiLSPACE]

@xoft, I was thinking, perhaps the PluginChecker should check if decimals were given to a function that only accepts integers. That way you can prevent rounding errors like this.

[xoft]

That won't be possible, because the Lua API descriptions don't specify whether they accept floating points, or integers only - they only say "number".