Random Chitchat 2012-2016
(06-19-2014, 05:00 AM)worktycho Wrote: RipGround Might benefit but I don't think its doing enough work. The main thing I think is that is is prime example of why we need a second plugin language for compute heavy plugins.

I think a good solution might be compiled-in C++ plugins, or perhaps even dynamic libraries that are somehow used on startup (is that even possible?).
Thanks given by:
Gentlemen, before we start another "alternative plugin language" discussion, let's step back and have a look at what we have.

The plugin presented by STR_Warrior is a raw one, a developer version, and it is in need of polishing before we can call it a proper plugin. The performance problems aren't caused by slow plugin language, they're caused by using somewhat wrong idioms. These are the main reasons why things tend to get slow, and no alternative language is gonna solve a badly chosen algorithm.

Let's analyze this plugin:
On every world tick, for each tornado, it basically calls RipGround and PullEntities (we're concentrating on the hot path here). The RipGround function iterates over the entire tornado's ground coverage and selects a few blocks to rip out. It basically is a big loop that says: Do this 441 times: calculate a random number, in 1/250 of cases, dig the block. So basically this uses a double for loop with 441 calls to random in order to rip out 2 - 3 blocks. We're smarter than that, we can do better:
NumBlocksToRip = 2 + random(2)
for i = 1, NumBlocksToRip do
  local BlockX = m_Pos.x + random(21) - 10
  local BlockZ = m_Pos.z + random(21) - 10
  -- Rip out block at {BlockX, Height, BlockZ}
end
This alone should improve the performance hugely.

Then the entities. They don't need constant guidance. They can be pulled every other tick, or even every 4 ticks. Again, savings on the order of 75 % work. Even the ground ripping can be done in every Nth tick, possibly ripping out more blocks if needed.

I believe these changes alone should make this plugin viable.
Thanks given by:
I've read the 1.8 changelog and I'm concerned by this little line with no additional info to it:
"All dimensions are now stored differently, increasing performance"
Source: http://minecraft.gamepedia.com/1.8 , General -> Performance
So what are they changing again?
Thanks given by:
I think that each world/dimension now has it's own thread, but that might have been reverted.
Thanks given by:
(06-19-2014, 11:12 PM)STR_Warrior Wrote: I think that each world/dimension now has it's own thread, but that might have been reverted.
In 1.8 every dimension will run inside his own thread.
Thanks given by:
I thought that was already true in 1.6 or so. The sentence talks about storage, not threeding, though.
Thanks given by:
(06-20-2014, 12:45 AM)xoft Wrote: I thought that was already true in 1.6 or so. The sentence talks about storage, not threeding, though.
You may want to follow @jeb_ and @Dinnerbone on twitter Wink
https://twitter.com/Dinnerbone/status/46...7990827010
Thanks given by:
Yes, but that's from a month ago. The problems they had with it might have been fixed already.
Thanks given by:
pffft. We had that ages ago thanks to xoft.
Thanks given by:
How to get where the player is looking in C++?
I'm trying to implement pig riding.
Thanks given by:




Users browsing this thread: 19 Guest(s)