Author Topic: Status update of fluffos 3.0  (Read 2410 times)

Offline FallenTree

  • BFF
  • ***
  • Posts: 482
    • View Profile
Status update of fluffos 3.0
« on: October 15, 2014, 05:26:31 PM »
First, a little recap:

Last release of fluffos 3.0 is  fluffos-3.0alpha7.4 ,  which was done , Nov 5, 2013  , almost a year ago. two biggest chinese mud has switched to it without issue (NT, PKUXKX).  More and more people are trying it out in chinese mud community, especially for running under cygwin on windows.

After that, I starte some exploratory work on 1) codebase refactoring, 2) switch to libtelnet, and 3) attempt to add multithreading support in the network stack, 1) is half-assed, 2) is done, and 3) dragged for a long time with no real progress.

Today I made the decision to kill 3) as the goal for 3.0 . I want to get a satisfying codebase out to serve as a future platform for later work.

Here are some of the TODO I have for 3.0, please let me know what you think:

1) finish code base reorganizing, and cleanups, the goal is to untangle the mess of the code has became, make it easier for people to make future changes.
2) remove all malloc nonsense, wrapper etc except sysmalloc and debugmalloc().
3) eliminate all RESIZE, string scratchpad implementations etc in driver, which is suspected to cause memory bloating and performance issues.
4) improve logging and errors if possible.
5) Have a canonical  options file, remove local_options file once and for all, make popular options configurable through runtime config. (like heartbeat_inteval)
6) Support call_out_realtime()  that will trigger base on real time delay, rather than in-game virtual time, this will finally decouple virtual time vs real time, greatly reduce the pressure on cpu on catching up.
7) support configurable driver tick (100ms) , this will inturn support sub second resolution for call_out and heartbeat.
8) Make it possible to compile, and run a LPC file directly on command line

Offline quixadhal

  • BFF
  • ***
  • Posts: 629
    • View Profile
    • WileyMUD
Re: Status update of fluffos 3.0
« Reply #1 on: October 17, 2014, 04:43:38 PM »
I fully agree with getting rid of the various malloc options, as they're not really needed these days.

The only benefit I can see to a malloc wrapper is to gather statistics, but for that to be useful you'd also need to wrap new/delete calls, moving forward.

I believe most of the resize/scratchpad stuff was to minimize the calls to allocate new memory, which was needed back when system malloc was horrible.  It shouldn't really be needed these days.  If you're in a situation where malloc() is a performance hit, you're probably swapping and should buy more RAM.

The only use for local_options is to avoid having it be overwritten when you update the driver source.  IE:  options.h will be overwritten, but local_options should not be in the repository.  I would just change it to be actually local_options.h, and rewrite the places that include it to fall back to options.h if the local version isn't there, instead of erroring out.

The configurable driver tick is a great thing.  I would suggest that heart_beat() be a seperate config value that gets rounded to a multiple of the driver tick.

That way, you can have high resolution call_out() but still retain your 2 second heart_beat(), if you want... or you can ramp heart_beat() up to crazy-fast if your CPU and players can handle it. :)

Making runtime configurable options is always good.  I would suggest the same thing as options.h though... have a default distributed file that is overridden by a local copy.

IMO, the driver should be able to run out-of-the-box, with sensible defaults and a minimal Lil/testsuite mudlib.

LPC command line scripts would be amusing.  Not sure how useful they'd be with the driver startup overhead, but hey... would be fun to be able to have an LPC cgi script in apache. *chuckle*

Offline silenus

  • BFF
  • ***
  • Posts: 165
    • View Profile
Re: Status update of fluffos 3.0
« Reply #2 on: October 17, 2014, 08:29:39 PM »
Would it be possible to have the reserve block play nice with STL containers? I think if this change were made it would allow for simplification of a lot of the code in the driver. I haven't really thought about this but I am thinking it would require perhaps as little a change as just adding a custom STL allocator.

This would allow for some obvious simplifications of various tables callouts, object table and uids. This would mean one could also remove avltree.
« Last Edit: October 17, 2014, 08:37:10 PM by silenus »

Offline FallenTree

  • BFF
  • ***
  • Posts: 482
    • View Profile
Re: Status update of fluffos 3.0
« Reply #3 on: October 18, 2014, 12:21:40 PM »
The reserved alloc should be gone too! With virtual memory managment no one should run out of memory.

Offline Camlorn

  • Friend
  • **
  • Posts: 76
    • View Profile
Re: Status update of fluffos 3.0
« Reply #4 on: October 19, 2014, 09:05:09 PM »
Well, technically, a 32-bit process is limited to at most 4 GB...so...is the driver 64-bit safe?

Offline quixadhal

  • BFF
  • ***
  • Posts: 629
    • View Profile
    • WileyMUD
Re: Status update of fluffos 3.0
« Reply #5 on: October 19, 2014, 09:29:32 PM »
It will be easier for it to be word-size safe when it doesn't try to do its own memory management.  Most compilers have definitions for things that match the target architecture's pointer size, such as size_t.  If you use those instead of "int", it should automatically do the right thing for whatever system you compile it on.

And letting the system handle memory management (via you using malloc/free or the constructor/destructor), you're less likely to run into issues.  When you try to reserve your own blocks of memory and then divvy them up, you're doing the MMU's job... and usually you end up doing it wrong somewhere, and that's where things go badly when you switch architectures.

Offline FallenTree

  • BFF
  • ***
  • Posts: 482
    • View Profile
Re: Status update of fluffos 3.0
« Reply #6 on: October 20, 2014, 01:18:33 PM »
the driver has been 64bit safe for a long time now I would say.

Offline Hilapdatus

  • Acquaintance
  • *
  • Posts: 11
    • View Profile
    • Dreamverse Support Site
Re: Status update of fluffos 3.0
« Reply #7 on: October 21, 2014, 06:25:56 AM »
Thank you for your work.

I don't mud much, haven't in many years, but I keep track of what's going on with FluffOS and, to a lesser extent, Dead Souls.  I've kept Dreamverse running all this time and switched it over to FluffOS a while back.