MUDBytes Community - Viewing Topic: Proposed bug fixes

David Haley Wizard Group: Members Posts: 5,728 Joined: Jun 30, 2007	#31 Posted Oct 10, 2008, 11:44 am
	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.
	......................... -- d.c.h -- BabbleMUD Project (custom codebase) Legends of the Darkstone (head coder) http://david.the-haleys.org ......................... WWW

Runter Wizard Group: Members Posts: 1,074 Joined: Jun 1, 2006	#32 Posted Oct 10, 2008, 7:56 pm
	Quote: From DavidHaley ... The overhead for this stuff is so low as to be basically negligible given the general performance requirements of MUDs. 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]
	......................... -Heath For once you have tasted flight Ruby you will walk the earth with your eyes turned skywards, for there you have been and there you will long to return. -- Leonardo Da Vinci Yukihiro Matsumoto Last edited Oct 10, 2008, 8:02 pm by Runter AIM Yahoo MSN

Vassi Conjurer Group: Members Posts: 182 Joined: Sep 24, 2008	#33 Posted Oct 10, 2008, 8:42 pm
	Runter said: [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)
	......................... Vassi no Diem et Tharin <ramble/> WWW AIM

Runter Wizard Group: Members Posts: 1,074 Joined: Jun 1, 2006	#34 Posted Oct 11, 2008, 7:50 am
	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.
	......................... -Heath For once you have tasted flight Ruby you will walk the earth with your eyes turned skywards, for there you have been and there you will long to return. -- Leonardo Da Vinci Yukihiro Matsumoto AIM Yahoo MSN

MacGregor Magician Group: Members Posts: 54 Joined: Oct 3, 2008	#35 Posted Oct 11, 2008, 8:27 am
	Meh, if it's raw performance you want, you'll write it in assembly.

quixadhal Wizard Group: Members Posts: 1,256 Joined: Oct 17, 2007	#36 Posted Oct 11, 2008, 9:21 am
	Assembly is for the weak. Write it in microcode for REAL speed! Better yet, do the VLSI layout for ROM. The NP junction BRUTALIZES you with its charge difference!
	.........................

Vassi Conjurer Group: Members Posts: 182 Joined: Sep 24, 2008	#37 Posted Oct 11, 2008, 11:14 am
	Runter said: 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. 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)
	......................... Vassi no Diem et Tharin <ramble/> WWW AIM

David Haley Wizard Group: Members Posts: 5,728 Joined: Jun 30, 2007	#38 Posted Oct 11, 2008, 12:32 pm
	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.
	......................... -- d.c.h -- BabbleMUD Project (custom codebase) Legends of the Darkstone (head coder) http://david.the-haleys.org ......................... WWW

MacGregor Magician Group: Members Posts: 54 Joined: Oct 3, 2008	#39 Posted Oct 11, 2008, 3:47 pm
	quixadhal said: Assembly is for the weak. Write it in microcode for REAL speed! Better yet, do the VLSI layout for ROM. 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!

quixadhal
Wizard

Group: Members
Posts: 1,256
Joined: Oct 17, 2007

#40 Posted Oct 12, 2008, 5:55 pm

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

Original

Code (text):

 
    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

Code (text):

 
    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

Code (text):

 
    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.

.........................

http://i302.photobucket.com/albums/nn96/quixadhal/Alelord_banner.png

MacGregor
Magician

Group: Members
Posts: 54
Joined: Oct 3, 2008

#41 Posted Oct 12, 2008, 6:20 pm

I like the "with spaces" option myself. It's unfortunate that the particular example you came up with has the line wrap, or was that perhaps intentional?

In any case, the style I do not like looks like this:

Code (text):

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

ie, no spaces at all.

Lobotomy Sorcerer Group: Members Posts: 353 Joined: Jul 18, 2008	#42 Posted Oct 12, 2008, 7:09 pm
	I would also suggest the "with spaces" style. It makes code considerably easier on the eyes, I find.

David Haley
Wizard

Group: Members
Posts: 5,728
Joined: Jun 30, 2007

#43 Posted Oct 12, 2008, 9:04 pm

I never put spaces around a type specifier. I don't put spaces in general inside parentheses unless it is a complicated expression and the spaces help legibility. This is partly why I never use a program to blindly re-indent my source code; I use an editor to do it as I write it, and then I can tweak it if so inclined. I believe that indenting/spacing should serve the end goal of clarity, and not be an end goal in and of itself.

So in this case I prefer the lower one, but had your expressions been more complicated (e.g. involving nested expressions, or more complex operations) I might have preferred spaces.

EDIT: after rereading some things that others said, I should specify that I very strongly believe in spacing "words" -- the spaces I don't believe in are ones where there is sufficient spacing already. For example, in the code

Code (text):

1
2
3

... (char*) ...

the type specifier is already separated from the rest by spaces. I should also note that I tend to not put spaces in between the star and the type being pointed to, because I believe that the semantic unit is "pointer to (type)", and not "type that is modified later by pointer". So,

Code (text):

1
2
3

char* c;

is IMO preferable to:

Code (text):

1
2
3

char * c;

both of which are very strongly preferable to:

Code (text):

1
2
3

char *c;

.........................
-- d.c.h --
BabbleMUD Project (custom codebase)
Legends of the Darkstone (head coder)
http://david.the-haleys.org
.........................

Last edited Oct 12, 2008, 9:07 pm by David Haley

WWW

Vassi
Conjurer

Group: Members
Posts: 182
Joined: Sep 24, 2008

#44 Posted Oct 12, 2008, 11:16 pm

This topic is so all over the place, I love it.

In any event, I think we could all argue about preferences forever, at the end of the day it should really matter most to those working on the project on a regular basis - so it doesn't really matter what my thoughts on the matter are, for instance.

On a side-note, though, auto-indent programs or "code beautifiers" inevitably drive me nuts because they do things like this:

Code (text):

 
if ( condition1 == condition2 ) {
   x = function();
} else {
   x = altFunction();
}

And that manner of bracing is just plain evil.

.........................
Vassi no Diem et Tharin
<ramble/>

WWW

AIM

quixadhal
Wizard

Group: Members
Posts: 1,256
Joined: Oct 17, 2007

#45 Posted Oct 13, 2008, 2:42 am

MacGregor, no it wasn't an intentional choice... but I'm happy it did because it does illustrate that the extra whitespace isn't free. Of course, this assumes we want to stick with the default 78 column width. My terminal is 137 columns wide with a font still big enough for my bad eyesight to resolve, so I certainly won't complain if we wanted 96 or even 132 as a width.

David, I agree for type casting, but unfortunately indent doesn't give the flexibility to allow arbitrary parens to have spaces added, but disallow them inside the typecast. I think it's probably the lesser of two evils to suffer with the extra spaces than to have them absorbed elsewhere.

Vassi, that's one option I can control. The settings I have put braces on their own lines, so the above would become:

Code (text):

if ( condition1 == condition2 )
{
    x = function();
}
else
{
    x = altFunction();
}

I want to come up with a .indent.pro file that can be included with the source, so that modifications can be reformatted to fit in with the overall style, which shouldn't be too radical a departure from the original. Nothing's perfect, but I think it's more important to keep everything looking like it belongs together, than have it exactly right.

.........................