|
One of reasons I like just plain C. The addresses are right there to be manipulated. Dangerous but useful.
/*
Count the number times character 'c' is in the given string s with length m
Note: address of s is passed by value, as is c and m so pointer math is self contained within routine
this let me step through the string incrementing its address.
Loop ends when null character of string is reached (C strings need to have null terminator)
or count down reaches zero.
Faster than indexing the string as an array.
*/
int STR_CountChar( char *s, char c, int m )
{
int count;
count = 0;
if( s == NULL ) return( 0 );
while( *s && m-- )
{
if( *s == c ) count++;
s++;
}
return( count );
}
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
Quote: Faster than indexing the string as an array
Please let me doubt about it.
Your code produces (gcc cross-compilation for ARM Cortex-M0, optimization set to -O3)
253 0000 30B5 push {r4, r5, lr}
259 0002 0028 cmp r0, #0
260 0004 13D0 beq .L37
262 0006 0378 ldrb r3, [r0]
263 0008 002B cmp r3, #0
264 000a 10D0 beq .L37
266 000c 002A cmp r2, #0
267 000e 0ED0 beq .L37
268 0010 0024 movs r4, #0
269 0012 02E0 b .L34
271 .L40:
272 0014 013A subs r2, r2, #1
275 0016 002A cmp r2, #0
276 0018 07D0 beq .L38
278 .L34:
280 001a CB1A subs r3, r1, r3
281 001c 5D42 rsbs r5, r3, #0
282 001e 6B41 adcs r3, r3, r5
284 0020 0130 adds r0, r0, #1
287 0022 E418 adds r4, r4, r3
290 0024 0378 ldrb r3, [r0]
291 0026 002B cmp r3, #0
292 0028 F4D1 bne .L40
294 .L38:
295 002a 2000 movs r0, r4
297 .L32:
300 002c 30BD pop {r4, r5, pc}
302 .L37:
304 002e 0020 movs r0, #0
306 0030 FCE7 b .L32
while the following one
int STR_CountChar_Alt( const char s[], char c, int m )
{
int count = 0;
for ( int k = 0; s[k] && (k < m); ++k)
{
if (s[k] == c )
++count;
}
return count;
}
produces
323 0000 30B5 push {r4, r5, lr}
330 0002 0378 ldrb r3, [r0]
331 0004 002B cmp r3, #0
332 0006 10D0 beq .L46
333 0008 002A cmp r2, #0
334 000a 0EDD ble .L46
335 000c 0400 movs r4, r0
336 000e 8218 adds r2, r0, r2
338 0010 0020 movs r0, #0
340 0012 02E0 b .L44
342 .L51:
343 0014 0134 adds r4, r4, #1
346 0016 9442 cmp r4, r2
347 0018 06D0 beq .L42
349 .L44:
351 001a CB1A subs r3, r1, r3
352 001c 5D42 rsbs r5, r3, #0
353 001e 6B41 adcs r3, r3, r5
354 0020 C018 adds r0, r0, r3
357 0022 6378 ldrb r3, [r4, #1]
358 0024 002B cmp r3, #0
359 0026 F5D1 bne .L51
361 .L42:
365 0028 30BD pop {r4, r5, pc}
367 .L46:
369 002a 0020 movs r0, #0
371 002c FCE7 b .L42
Now, I might be wrong (since I have NOT computed the exact execution cycles, nor I have measured them), but the former assembly code doesn't look faster then the latter one.
I suppose it could be a case of 'premature optimization'.
"In testa che avete, Signor di Ceprano?"
-- Rigoletto
|
|
|
|
|
Wow, you really looked into this.
Back in the day when I did a lot of C programming, it was the general opinion that the use of indexing arrays carried a small amount of overhead. Your code analysis shows that a compiler can optimize that. Thanx for the feedback. Tells me that I need to run a benchmark for both approaches with a much larger loop.
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
jmaida wrote: that a compiler can optimize that
Indeed. Compiler optmization is very aggressive now (at least in my experience with GCC), and simpler code is sometimes better optimized.
"In testa che avete, Signor di Ceprano?"
-- Rigoletto
|
|
|
|
|
Test results using the STR_CountChar( char *s, char c, int m );
input string: gggggggggggggggggggggggggggggeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
Strength Length 80
Interations 50000000
CLOCKS PER SEC 1000
Non-Indexed Elapsed 5976
Index Elapsed 6444
so for 50,000,000 iterations and -O3 GCC optimization, non-indexed was ~.66 seconds faster
Timer used CPU clock ticks returned by C function clock();
Not a definitive test, but probably a good approximation
I used i9-9900 CPU @ 3.10ghz
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
However, "never take a benchmark at face value", on constant input values GCC makes all sorts of weird optimizations.
"In testa che avete, Signor di Ceprano?"
-- Rigoletto
|
|
|
|
|
I agree. In grad school, we wrote a lot of PL/I code.
IBM's top of the line optimizing compiler at the time.
Our professor (BTW an Italian from Argentina), gave us projects to "play" with the optimizer.
Long time ago. The technology is much more advanced today.
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
I made my own tests...
And I have to admit the non-indexed code is impressively faster than the indexed one (clocks):
non-indexed 288299
indexed 426617
(one million or randomly-sized, random strings).
Now I'm 'wondering which of the buggers to blame'. 
"In testa che avete, Signor di Ceprano?"
-- Rigoletto
|
|
|
|
|
I guess he means the operator precedence here surprised him! 
|
|
|
|
|
|
And...
What did you expect?
"In testa che avete, Signor di Ceprano?"
-- Rigoletto
|
|
|
|
|
... a compilation error 
|
|
|
|
|
int Inquisition = 3;
cout<< "The Spanish" + Inquisition;
I fixed up the code to make it clearer. Iβm sure that you werenβt expecting that either!π€ͺ
If you can't laugh at yourself - ask me and I will do it for you.
|
|
|
|
|
|
int value= 3;
cout << value + "ABCDEF";
|
|
|
|
|
This is legal C, but a real coding horror. The only place this should appear is in an obfuscated C contest entry. 
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Looks like even The Lounge is not appropriate place for posting such code...
Thank you for valuable information, I will do my best to avoid such terrible code in the future.
|
|
|
|
|
int value = 3;
cout << &value["ABCDEF"];
|
|
|
|
|
Coding horrors all of them 
Life should not be a journey to the grave with the intention of arriving safely in a pretty and well-preserved body, but rather to skid in broadside in a cloud of smoke, thoroughly used up, totally worn out, and loudly proclaiming βWow! What a Ride!" - Hunter S Thompson - RIP
|
|
|
|
|
Nice. And without & it prints D.
|
|
|
|
|
#Worldle #310 1/6 (100%)
π©π©π©π©π©π
https://worldle.teuteuf.fr
too easy
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
#Worldle #310 1/6 (100%)
π©π©π©π©π©π
https://worldle.teuteuf.fr
Easy indeed.
|
|
|
|
|
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
#Worldle #310 1/6 (100%)
π©π©π©π©π©π
https://worldle.teuteuf.fr
Yes, that one was easy.
|
|
|
|
|
#Worldle #309 3/6 (100%)
π©π©π©π©β¬βοΈ
π©π©π©π©π¨β‘οΈ
π©π©π©π©π©π
https://worldle.teuteuf.fr
I had no idea until I checked
One should play this game to learn about the shape of the world.
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
