Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Dworkin

Pages: [1] 2 3
1
Drivers / Re: New fluffos repo containing the 2.28 version.
« on: September 21, 2019, 07:29:12 AM »
Another direction you could take with FluffOS is improve the bytecode VM.

I did this for DGD as a prerequisite for JIT compilation.  Getting rid of lvalues as an explicit type gave me a speedup of 10-30%.

2
Drivers / Re: New fluffos repo containing the 2.28 version.
« on: September 21, 2019, 05:23:33 AM »
STM has the problem that it appears to scale worse than a well-designed implementation using locking, and you still have most of the same design headaches as you have with locking for multi-threaded code. Hydra doesn't require or implement STM, though it uses some of the same underlying ideas.

In any case, FluffOS & DGD are already overpowered for MUDs on present-day hardware, and DGD with JIT compilation is ridiculously overpowered. The speedup offered by JIT compilation will probably not play out in the realm of MUDs.

3
Drivers / Re: New fluffos repo containing the 2.28 version.
« on: September 10, 2019, 10:41:15 AM »
Silenus, I started working on the JIT compiler a long time ago, but didn't have time to complete it until recently.  I only decided to make use of LLVM a few months ago, before that I was still considering decompiling to C, instead.  I made the first point release of the JIT compiler just now.

The situation for DGD is similar to FluffOS, the community has shrunk and those who still use it are doing their own thing.  As a MUD server engine, DGD was probably feature-complete around 2002, and there is not a lot of interest in new releases.  And to top it off, I spend most of my free time on Hydra now, which is not yet used by anyone at all.  ;D

4
Drivers / Re: New fluffos repo containing the 2.28 version.
« on: August 17, 2019, 08:33:08 AM »
I noticed that you started an issue for JIT compilation, where you consider the option to compile to LLVM IR directly.

Another option would be to do both, preserving lightning-fast LPC compilation. For JIT compilation for DGD, I chose to compile from VM bytecode to LLVM IR in multiple passes; detecting basic blocks, determining the types of expressions, doing dataflow analysis, and finally generating LLVM IR which can be compiled with clang. I have this mostly working (mud boots and I can walk around), but there are a few bugs to iron out.

You can find the code at https://github.com/dworkin/lpc-ext/tree/master/jit.  It could probably be adopted for FluffOS without too much difficulty.

5
Drivers / Re: function pointers and anon funcs
« on: November 01, 2015, 03:09:36 PM »
Does it make sense for function pointers to persist when object references don't?

6
Drivers / Re: function pointers and anon funcs
« on: November 01, 2015, 08:45:51 AM »
Quote from: silenus on November 01, 2015, 07:23:52 AM
I might be wrong about this but I suspect that function pointers in dgd work be okay if you assume a sort of late binding i.e. make the function point just hold the object or program on which the pointer is called plus a string and arguments. I.e. a sort of on demand delayed call_other with no guarantees that it points to anything of if it ever did. I am not sure however with object upgrades how lambda closures (anon-funcs) could be made to work since in principle you either carry the code with the variable or compile the code into an object which is nameless and point to it. Could you not have an nameless object hold the code and have the function pointer point to the code in a nameless object that gets compiled on the fly? Depending on the copy semantics one could perhaps even use an lwo.

This discussion is wandering far afield, but the difficulty in combining object upgrading with anonymous functions is that you cannot unambiguously match an anonymous function reference to code in a newly upgraded object. Thus anonymous functions cannot be automatically upgraded.

None of this pertains to Fluffos, which doesn't have object upgrading.

7
Drivers / Re: function pointers and anon funcs
« on: November 01, 2015, 03:12:56 AM »
I think you are misremembering, Quixadhal. Fluffos doesn't allow recompilation of an object while retaining its data. DGD does, and that's one of the reasons why DGD has no function pointers.

8
Drivers / Re: Thoughts on licensing issue
« on: April 03, 2013, 10:12:34 AM »
Quote from: quixadhal on April 03, 2013, 09:40:41 AM
Actually, you don't need multithreading.  You need to not abort LPC thread execution when the time's up, but save the stack machine's state for that object and context switch to the next one.

Right now, if a thread exceeds their eval ticks, it just gets killed.  How hard would it be to save state and restore it next time around the loop?

That is so 20th century.  Event-driven, non-blocking, asynchronous I/O models are the height of fashion now: Node.js, Akka, Vert.x.

9
Drivers / Re: proposal for multi-threaded comm changes.
« on: March 07, 2013, 06:37:05 PM »
Quote from: quixadhal on March 05, 2013, 08:44:40 AM
I don't know the internals of FluffOS, so I don't know what can of worms you're opening by introducing multi-threading at that level.  Since FluffOS's LPC isn't itself multi-threaded (unlike DGD's Hydra), I suppose it wouldn't be too ugly as long as you were careful about mutex-locking the code that's fetching socket input and dumping it into the processing buffers (and likewise for output).

Hydra on Linux uses epoll_wait(), but for a single-threaded server select() can be more efficient because it can collect multiple events per call. The higher the activity/connections ratio, and the longer LPC execution takes (making it more likely that input events will be grouped together), the more efficient select() becomes.

10
Design Lab / Re: High Level Design Series: Technology Stack (The NEW 7 Layer Surprise)
« on: August 04, 2012, 07:52:17 AM »
Quote from: Shem (aka MadScientist) on August 03, 2012, 06:06:16 PM
Because one of my high level goals is to reach both 1st & 3rd world infrastructures, I'm trying to figure out an infrastructure model that would be essentially UI agnostic.  Maybe something Client/Server Obj/Event ...

People in third-world countries don't have computers, but they do have phones; in a few years they'll have Android smartphones. Given that you want to reach this enormous population, perhaps you should drop support for the tiny and shrinking group of people who will connect with telnet-like clients from first-world computers.  ;)

11
Design Lab / Re: High Level Design Series: Blue Sky WISH List(s)
« on: July 16, 2012, 09:59:43 AM »
To return to the subject of modern mud drivers, if DGD were not available today, I would take a look at Node. Javascript, event-driven like LPC, and it's a server not a script.

12
Design Lab / Re: High Level Design Series: Blue Sky WISH List(s)
« on: July 16, 2012, 09:31:30 AM »
Quote from: chaos on July 16, 2012, 09:23:31 AM
I'm entirely certain you were successful in pulling all the game-mechanical cruft out of DGD, and hopefully all of the freakishly broken "performance optimizations" too.  (My favorite is the behavior I discovered under LDMud after various of my daemon objects stopped working: if nothing attempts to call a function on an object via call_other() for some period of time, reset() stops getting called!  And there is no driver config switch for this behavior!  So awesome.  You can imagine how much of my hair I pulled out trying to debug that idiocy.)  The only assumption I had in mind for DGD was that of being a telnet server.

The telnet part is optional; some DGD mudlibs use HTTP.

13
Design Lab / Re: High Level Design Series: Blue Sky WISH List(s)
« on: July 16, 2012, 09:14:20 AM »
Quote from: chaos on July 16, 2012, 09:00:15 AM
I thought that some assumptions were in there that the system is going to be a Telnet server hooking up connections to objects.  Meaning, I didn't think DGD made you write your own socket handling model like Pike would.  If I'm wrong, I humbly apologize.

DGD is a server, yes; it doesn't make LPC into a scripting language, as Pike does.  But what about the game server assumptions?

14
Design Lab / Re: High Level Design Series: Blue Sky WISH List(s)
« on: July 16, 2012, 08:33:46 AM »
Quote from: chaos on July 15, 2012, 06:25:02 PM
I'm pretty sure we have a modern LP driver, the Pike programming language.  Just, y'know, somebody probably has to make a mudlib for it.  (Which will be challenging because it actually follows through on the separation of concerns that MudOS and DGD were aiming at and doesn't have game server model assumptions baked into its core.)

This suggests that DGD does have game server model assumptions baked into its core.  Can you name one?  I do not think there are any, but perhaps I overlooked something.

15
Design Lab / Re: High Level Design Series: Technology Stack (The NEW 7 Layer Surprise)
« on: July 16, 2012, 08:18:18 AM »
Quote from: Shem (aka MadScientist) on July 12, 2012, 02:17:02 PM
My planned Technology Stack (likely DGD based):
  • OS - Host Server(s) (ie Linux, Windows Server, etc ...)
  • Driver (VM Sandbox, Compiler, Security, Services, ...)
  • Driver Extension(s) (3rd Party MudLIB Optimizations)
  • MudLIB(s) (Game Methods, Mechanics, & Models)
  • Story OBJs (Actors, Settings, Events, & Context)
  • Interface (Client Tools such as Telnet, TinTin++, Adaptive Tech)
  • Player (Total Wetware Interactive eXperience -Silly rabbit, TWIX is for Kids!)

I am of course flattered that you would consider using DGD for your project. I have one suggestion:

Put the interface at level 3, not level 6, and take the technological developments of the last 20 years into account.  Nobody wants to use telnet anymore; not even when it runs as an app on a web page.

Pages: [1] 2 3