Sorry, I thought you were talking about actual search, as in the 'find' command.

As for the other stuff, well, I think we've wandered pretty far away from what we were talking about. We could all start adding extra requirements based on things we do every once in a while and pretty soon no solution at all would work for everything. :wink:

I use screen. So, for me, if I want to poke at another codebase, I just hit ctrl-A ctrl-C, cd to that directory, edit a random file that has the function call I want in it (grep works), then hit 'ctrl-]' to jump to the defintion. I suppose you could automate that…

grep -n send_to_char *.c | head -1 | awk -F: '{print "vim +"$2" "$1}'

For that matter, looking at the tags file, it's just a list of "token" "filename" "pattern" tuples. You could probably write a little bash function to pull the result and make your editor do that search. I'm sure that's all vim does… I know you can open a file with +N to jump to line N, and with +/pattern to jump to a pattern match.

LOL, I started writing such a function, and then read the man page for ctags. You can use "vi -t tagname" to edit whatever file the tag is defined in, at that line.

Other editor users might wish to continue writing that function…. or join the dark side and embrace vi. We have cookies!

However, yeah… nobody will ever agree on all parts of any coding standards. Shoot, most of the codebases aren't consistent internally, let alone when things get added in. My own preferences lean towards compacting things vertically, since normal displays are wider than they are tall, but I know having the braces for if/else/while/etc on the same line as the statement bugs the hell out of some people.

In doing my next chunk of autumn cleaning, I discovered that malloc_debug isn't actually defined anywhere, nor is it part of the standard malloc library. Apparently it was installed wherever ROM was built. In any case, that makes it mostly worthless to us, since if you try to define and use it, it won't work.

I'll strip it out. It looks like all it did was run malloc_verify() at the top of each game_loop and abort if that complained. I'm sure we can
remember that the main loop is a good place to make such checks if we find a better memory subsystem later. :)

Malloc_debug is a memory debugging library. It primarily replaces malloc, calloc, etc with its own wrapper functions which instrument calls to the real malloc etc. It can also monitor string functions such as strlen, strcpy, well, pretty much anything declared in string.h. You use it by #defining MALLOC_DEBUG and linking against libdmalloc.a.

I'm rather surprised you didn't know about it; that stuff is in many merc derivs including ROM, Rot, envy, ember, godwars, smaug, SWR, etc.

It may be in many codebases, but there is no such library on my system, which is a pretty stock Debian installation. It seems odd that I'd have gc_malloc() installed by default (garbage-collecting… never bother with free() again), but not dmalloc.

Hmmm, ok. I'll install that package and see if the calling API is unchanged. If it is, I'll add the appropriate library links in the Makefile so defining it will actually work.

Thanks for the heads up!

Actually Merc and Envy were quite consistent style-wise. Alander had a coding style quite different from Furey's, so RoM looks like a bit of a mess. On the other hand, it makes it easy to spot Russ's changes from Merc. KaVir used the same coding style as Furey throughout Godwars, I believe. By the time you get to Ember, Quickmud et al, thnough, it starts to look really messy. Myself, I like Furey's way of formatting.

Anyway, I believe readability is important and whitespace promotes readability. And yes I'm one of those people who having the braces for if/else/while/etc on the same line as the statement bugs the hell out of :P

As for terminal layout, I tend to run multiple xterms set up as 80x50.

Interesting. Either this is a different library, or it has changed quite a bit since the 1990's. According to the docs, you have to include dmalloc.h as your last include file (so that it overrides the system calls and doesn't then get re-overridden). Additionally, malloc_debug and _verify have been renamed to dmalloc_debug() which takes an argument telling it what things to try and track, and dmalloc_verify().

I'm guessing that if you don't include dmalloc.h, you can call the routines as often as you like, but if your system library has malloc built-in (which all modern ones do), it will never DO anything.

It'll be interesting to see what (if anything) this reports. :)

I don't mean to derail the thread at all (as I'm not following the whole RaM situation - not particularly interested in it myself), but I must say what you've brought up is very interesting to me. I've never even heard of gc_malloc until now, and I have to say it sounds like a rather useful tool. However, I've heard in the past that garbage collectors may add considerable overhead to a program. What is your experience like in using gc_malloc (this is a question to anyone that uses it), and what are the performance differences/losses between a program with standard malloc/calloc and free calls versus using gc_alloc, if any? :thinking:

Here's a link to the man page, which itself has a link to the homepage of the project.

I only stumbled upon it when doing "man -k malloc" to try and figure out what malloc_debug was. I've used plenty of languages that do garbage collection as their method of memory management (perl, most heavily). I never notice much of a problem with them, and have written servers in perl that run for a few days at a time.

I would expect the big win (in C) would be the ability to use strdup() to modify and return strings and not have to care about freeing the old ones, or keeping static buffers around. Once the old pointer reference goes away, the garbage collection will come along and free the memory.

I'm sure there is some overhead from scanning the stack and heap to see if a memory block is still referenced, but have no numbers to suggest how much.

One way we could test this would be to make sure all your memory allocation is done via gc_ (using macros, or whatever), and make your free() macros just do nothing (there IS a gc_free… but they tell you not to use it).

Compare the CPU/memory use over a couple of hours of similar load, each way.

You can also use such a library as a replacement for specific things. It makes the consequential overhead almost nil for the feature. Such as what Quixandhal pointed out with strings. It doesn't have to be a complete, across the board replacement.

The overhead for this stuff is so low as to be basically negligible given the general performance requirements of MUDs. If you were talking about main loops that ran thousands upon thousands of times per second, you might have reason to worry, but really, it's not a problem. Java has garbage collection and it's plenty fast enough to run high-performance calculations. (Of course, straight up C/C++ is faster, but that's not the point.) Basically all interpreted languages these days have garbage collection, and I wager that the majority of them are also fast enough to run a MUD in.

That said, I would rather do what Runter suggested and use/implement a special purpose memory management solution in those places where I know I need it. For example, I have my own shared string object that manages everything completely behind the scenes. I can happily assign strings, and it takes care of dealing with the central string pool, freeing strings when necessary.

I think you just made the argument for making a mud in python.


[additionally] I generally agree on the subject of high level vs low level. I typically use high level solutions anywhere I can. I like ruby and python quite a bit. However, Also to point out, many mud hobbyists pay hosts for the ram/CPU they use. To those people sometimes overhead does matter. ;) [/additionally]

I think that's really the only reason people have shied away. I can't speak for Python but .NET and Java have a tendency to generate a much larger footprint from the get-go though after load they tend to even out substantially. VPS costs are starting to fall, though, so I think this will soon be an option for everyone who can afford 12-20 bucks a month - even for a windows VPS. (Davion indirectly introduced me to my new one, and hoooly cow are the specs way better)

12-20 bucks is more than reasonable, it's about the price of an MMO account and not that much higher than the 8-10 dollars for most Linux-based MUD hosting now - except you get the whole system to play with and configure (the downside being that you get the whole system to play with and configure)

It's not really true that high level languages tend to even out over the long term. If designed with efficiency in mind C can do major things on barely no resources. Even with the best designs, designed similarly in C will result in vastly less resources used. Plus, the idea of a high level language is to use the features in a way that you aren't concerned with efficiency. You're concerned with productivity. I mean, the idea that they even out is kinda ridiculous considering I was using over 20 megs of ram when I turned my python mud on before I added any features or additional code but the network code. I never hit 20 megs on my fully developed C mud with data.

The thing that makes me laugh is people assume that the reason people don't use anything but their favorite high level language is because they don't know how to.

Meh, if it's raw performance you want, you'll write it in assembly. :biggrin:

Assembly is for the weak. Write it in microcode for REAL speed! Better yet, do the VLSI layout for ROM. :devil:

The NP junction **BRUTALIZES** you with its charge difference!

Sorry, evening out was was the wrong choice of words, settling down is perhaps better? to use your example my C# mud hits 18-20 megs of ram when it first boots as well but after a few days it can go as low as 6 mb as some of the framework 'cruft' is written out of the working set. It didn't intend to imply that they eventually caught up with the performance of C, for all the reasons you described. Anyway, I really don't want to derail this thread which has a higher purpose (other than to say I'd help if it wasn't C =P)

High-level languages have a high startup cost because you have to load the interpreter and standard languages. In many cases, the cost from there is not really asymptotically higher.

I would quibble somewhat with the statement that people aren't concerned with efficiency in a high-level language. I mean, I guess you don't have to be, but if you're writing a program, or even a section of a program, for which performance is important, it behooves you to know a bit about the implementation and how to write efficiently in that situation.

Yeah, but I can do assembly in userspace. But if you reallly want speed, yes, burning your own PALs is the way to do it!

Here's an indent question for ya'll…. this is a tiny section from comm.c:

Original

if ( setsockopt( fd, SOL_SOCKET, SO_REUSEADDR,
    (char *) &x, sizeof(x) ) < 0 )
    {
        perror( "Init_socket: SO_REUSEADDR" );
        close(fd);
        exit( 1 );
    }

with spaces after parens

if ( setsockopt( fd, SOL_SOCKET, SO_REUSEADDR,
                     ( char * ) &x, sizeof( x ) ) < 0 )
    {
        perror( "Init_socket: SO_REUSEADDR" );
        close( fd );
        exit( 1 );
    }

no spaces after parens

if (setsockopt(fd, SOL_SOCKET, SO_REUSEADDR, (char *) &x, sizeof(x)) < 0)
    {
        perror("Init_socket: SO_REUSEADDR");
        close(fd);
        exit(1);
    }

Which of the two lower ones do you like better?

I didn't change anything else but the setting for putting spaces around parens, the more compact one just happens to fit in 78 columns and doesn't wrap.