Author Topic: smart pointers as a change to the driver for refcounting  (Read 3290 times)

Offline Camlorn

  • Friend
  • **
  • Posts: 76
    • View Profile
Re: smart pointers as a change to the driver for refcounting
« Reply #15 on: October 15, 2014, 09:31:38 AM »
I recall hearing once that Discworld takes a couple gigabytes.  This may be false, and seems excessive.  Discworld has a very, very large number of players-back when I played it, 80-100, probably more.
3 Kingdoms is another LPMud.  I am unsure which driver.  Back when I played it, 3 Kingdoms had upwards of 150 players.  3 Kingdoms rebooted once a week, or thereabouts.  This rebooting was not for system problems, it was for game balance-3 Kingdoms does not save eq, and part of gameplay is reacquiring it after boot.  3 Kingdoms never, ever lags.
Batmud is probably the largest mud I know of.  I don't recall it rebooting at all, but this may have happened.  If it did, it didn't impact the players much.  batmud, in the not-too-distant past, had upwards of 300 players at peak times.  Batmud also never lagged.
It's not worth it, basically.  No player will notice.  No mud admin will notice.  No one but the very few people who hack the driver care.  Most muds don't hack the driver.  It's a bit like saying that you're going to make your compiler 2% faster so that end users have better programs-the end user isn't going to notice.  In the case of Fluffos, it's mostly stable, so don't touch.
As for DGD: a basic language of your own takes a couple weeks.  Dgd does a bunch of stuff that's hard that isn't part of the "language."  The big selling points of DGD are that it's got atomics and it's got the ability to let your mud pretend it never shuts down.  Dgd is really a language which tries to be compatible with another nonstandard language, a system that tries to run it in an environment that makes today look like heaven, and the ability to conceptually use more ram than you actually have available.
As for my own language?  With modern constraints, it would take 2 weeks to a month to have something basic but usable going.  Grab any of the frameworks--llvm plus something like antlr comes to mind--and you're 75% done with your compiler.  Interpreting is easy enough, especially--as you said--because those micro optimizations have little to no impact.  If your goal is to experiment with this kind of thing then I suggest starting your own project.  You're talking about retrofitting a system that's worked fine since the early 90s or before-I'm not sure where Fluffos's roots began.  It feels like your goal is to learn something, but maybe I'm wrong.

Offline FallenTree

  • BFF
  • ***
  • Posts: 476
    • View Profile
Re: smart pointers as a change to the driver for refcounting
« Reply #16 on: October 15, 2014, 05:32:13 PM »
I gave this some thought lately, in my experience, shared_ptr is really infectious,  once you start use shared_ptr and pass that around, you need to make sure *everywhere* is also using shared_ptr,  this make it quite hard to do it right in current codebase.

Offline Camlorn

  • Friend
  • **
  • Posts: 76
    • View Profile
Re: smart pointers as a change to the driver for refcounting
« Reply #17 on: October 15, 2014, 11:13:14 PM »
That's also true.  I switched to shared_ptr for my own projects, but retrofitting one of them (much, much smaller) took something around two weeks before everything was right.  At that point, that was something like 20% of the total development time put into it.