18 Nov, 2008, The_Fury wrote in the 1st comment:
Can someone explain to me how URANGE works.

`#define URANGE(a, b, c)	((b) < (a) ? (a) : ((b) > © ? © : (b)))`
18 Nov, 2008, Kline wrote in the 2nd comment:
if( b < a )
return a;
else if( b > c )
return c;
else
return b;
18 Nov, 2008, Kayle wrote in the 3rd comment:
Hrm.. Something about the U macros was broken.. but I can't recall what. You should check SmaugFuss 1.9 and see which we changed. Something wasn't working right, and I can't recall. =/
18 Nov, 2008, quixadhal wrote in the 4th comment:
URANGE(5, x, 10) would return 5 if x < 5, would return 10 if x <= 10, and would return x for values between 5 and 10. In other words, it caps both ends, so the result is always between 5 and 10.
18 Nov, 2008, kiasyn wrote in the 5th comment:
Kayle said:
Hrm.. Something about the U macros was broken.. but I can't recall what. You should check SmaugFuss 1.9 and see which we changed. Something wasn't working right, and I can't recall. =/

URANGE( rand(), x, rand() ) was unreliable.
18 Nov, 2008, David Haley wrote in the 6th comment:
If that were the only problem, it would not be so bad. Basically, it evaluates the parameters more than once. If those parameters are function calls, then the functions get called several times. Bad times.

The change was to make the macro into a function so that arguments were evaluated exactly once.
18 Nov, 2008, Lobotomy wrote in the 7th comment:
DavidHaley said:
If that were the only problem, it would not be so bad. Basically, it evaluates the parameters more than once. If those parameters are function calls, then the functions get called several times. Bad times.

The change was to make the macro into a function so that arguments were evaluated exactly once.

Considering the overhead of function calls versus macros, I'm curious as to why typeof() wasn't just used in the macros instead to fix the problem while maintaining their status as macros.
18 Nov, 2008, David Haley wrote in the 8th comment:
There is basically no overhead to be considered here for function calls versus macros. For starters, the overhead is negligible unless you're doing something thousands upon thousands of times per second. Second, a function like this would most likely be inlined by an optimizing compiler, making the overhead go away.

As for typeof, it's a gcc extension, which is probably why it wasn't used.
18 Nov, 2008, elanthis wrote in the 9th comment:
Keep in mind that if you are want to make a function inlined, it needs to be defined in a header, and using an extension like the inline keyword. No compiler can optimize inlining across translation unit boundaries, except those that compile to an intermediary form rather than object code, like LLVM can.

David's pretty much spot on about the overhead being negligable, though. We're talking MUDs, for goodness' sake. Any performance issues you're going to have in something like that is almost guaranteed to boil down to your code using a horribly inefficient algorithm, not something like function call overhead. Making your code buggier and harder to maintain (e.g., using a macro where a function could be used) for the sake of micro-optimizations is the kind of thing you do when your code is 100% done and not going to change… which for a MUD, doesn't happen until the MUD is dead.
18 Nov, 2008, David Haley wrote in the 10th comment:
elanthis said:
for the sake of micro-optimizations is the kind of thing you do when your code is 100% done and not going to change… which for a MUD, doesn't happen until the MUD is dead.

I agree completely and would like to make this statement even stronger: you only micro-optimize if it actually improves performance. If your optimization increases overall program efficiency by ~1ms per second for the entire execution of your MUD in that second, it's unclear that you spent your programmer time usefully – especially if you're not even close to maxing out CPU usage during that second.

In short: optimize inner loops that run thousands upon thousands of times per second in an application that really cares about performance that is already maxing out the resources available to it.
Random Picks

0.0/10