Programming

On an Intel PIII 800 under linux with gcc and no optimization, I get the following:

Running the program with the hard-coded character searching and printing 100000 times (this is 100000 distinct calls to these functions), I get an average of 0.038 seconds per run. Using the constant character, I get an average of 0.039 seconds per run. So hard coding is more efficient.

You can also use the pre-processor to achieve some level of generality without sacrificing performance. Instead of defining a constant, just do:

Code:

#define AT_SIGN '@'

...

ptr = strrchr( string, AT_SIGN );

Despite what everyone said I think speed differences between both cases are not mensurable. For one, memory is stored in the data segment in both cases thus it's accessed in the same way/speed. Furthermore, this is highly platform/architecture/implementation dependent.

We should call a meta-programmer to enlighten us with accurate specifications on the matter at hand.

It IS measurable. But even after 1/2 million invocations, it made almost no difference on a very slow (10-year old) machine.

mostly wrong. The '@' literal is embedded in the machine instructions itself (for x86 architectures), so that's in the code segment. The "const" designation for a variable means the compiler can optimize that variable, for instance, by also "hard coding" the value inside instructions. However, I did not turn on optimizations. In my code, I defined the const char to be inside the main() call, meaning it would go on the stack. Do nothing is on the data segment. Finally, the call to strchr places both arguments on the stack. So the price of having a constant in an immediate instruction type is practically nullified by this.

Architecture and processor, yes. For instance, while practically all processors have both an 'immediate' addressing and a 'direct' addressing mode, the difference in the number of clock cycles to process such an argument varies across architectures (surely), processor manufacturers (AMD vs Intel), and processor families (Pentium vs Celeron). There almost always IS a difference, but in very-large-pipelined architectures and efficient caching, that difference is statistically erased.

However, there's more dependency on the compiler. Whether the compiler chooses immediate mode or direct mode for literals, whether it uses direct or stack-indexed addressing addressing for constants, weather it passes the first argument in using a register or the last, etc, etc. The OS can come into play, too, especially with my program of 100000 lines of code. This likely meant there were page-traps during the execution. For this reason (and others), I took an average of several runs.

WTF do you mean by a metaprogrammer??

I also did some testing and results were not conclusive that's why I said that. After ~0 calls to strrchr() in x86 with no forced preemption (kernel) and -20 nice level, 950 clock ticks happen in both cases (times()). I did the test 10 times, and results looked always the same.

I disagree, you're mixing things up. In elf32-i386 file format both cases store data in .rodata section (sections simplify my explanation). Although everything gets push()'d to the stack when a function is called, the places where data is push()'d FROM is the same. Let me demonstrate:

Code:

int
main ()
{
        write (1, "MOMMA", 5);
        return 0;
}
"MOMMA" string is stored in .rodata section, let's disassemble (objdump -D):
Disassembly of section .text:
...
080483b0 <main>:
...
 80483c1:       c7 44 24 08 05 00 00    movl   $0x5,0x8(%esp)
 80483c8:       00 
 80483c9:       c7 44 24 04 bc 84 04    movl   $0x80484bc,0x4(%esp)
 80483d0:       08 
 80483d1:       c7 04 24 01 00 00 00    movl   $0x1,(%esp)
 80483d8:       e8 13 ff ff ff          call   80482f0 <write@plt>
...
(items are push()'d in reverse order $0x5, $0x80484bc, $0x1)
Anyway, let's search for 0x80484bc :

Disassembly of section .rodata:
...
080484b8 <_IO_stdin_used>:
 80484b8:       01 00                   add    %eax,(%eax)
 80484ba:       02 00                   add    (%eax),%al
 80484bc:       4d                      dec    %ebp
 80484bd:       4f                      dec    %edi
 80484be:       4d                      dec    %ebp
 80484bf:       4d                      dec    %ebp
 80484c0:       41                      inc    %ecx
"\x4d\x4f\x4d\x4d\x41" = "MOMMA"

Thus demonstrating that despite "MOMMA" is used in main() (.text section), it is retrieved from .rodata section

Now, let's store "MOMMA" in a const var and call it from write():
# objdump -s test|grep -A 1 rodata
Contents of section .rodata:
 80484c4 03000000 01000200 4d4f4d4d 4100      ........MOMMA. 

So, the string is used in the .text section from .rodata section in both cases.

I meant compiler programmers eheh

I agree with everything else you said.