Thread: Quick speed test

So I thought of a different method for reading in numbers and to check it was actually faster (which I strongly suspected) I decided to run a speed test only the resulting difference was so vast I thought maybe I did something wrong in the second that was taking more time than needed, here's a link to the files I used:
base62_speedtest.tar.gz - Google Drive
And here's my output:

Code:

make base62.run
cc -fPIC -Wall -Wno-multichar  -shared -o ./libnext.so -c next.c
cc -fPIC -Wall -Wno-multichar  -D OUT=base62.elf -o ./base62.elf base62.c ./libnext.so
base62.c: In function ‘main’:
base62.c:270:24: warning: format ‘%llu’ expects argument of type ‘long long unsigned int’, but argument 2 has type ‘counter_t’ {aka ‘volatile long unsigned int’} [-Wformat=]
  270 |  printf("Method 0 = %llu, Method 1 = %llu\n", method0, method1 );
      |                     ~~~^                      ~~~~~~~
      |                        |                      |
      |                        long long unsigned int counter_t {aka volatile long unsigned int}
      |                     %lu
base62.c:270:41: warning: format ‘%llu’ expects argument of type ‘long long unsigned int’, but argument 3 has type ‘counter_t’ {aka ‘volatile long unsigned int’} [-Wformat=]
  270 |  printf("Method 0 = %llu, Method 1 = %llu\n", method0, method1 );
      |                                      ~~~^              ~~~~~~~
      |                                         |              |
      |                                         |              counter_t {aka volatile long unsigned int}
      |                                         long long unsigned int
      |                                      %lu
./base62.elf
07 = 7
999 = 999
0b101 = 5
0x5f5e0ff = 99999999
9stop = 9
Method 0 = 213564, Method 1 = 18446727230073051771
rm base62.elf libnext.so
Compilation finished successfully.

Could a few people run this ("make base.run" is the command) and show me their results please.

If you fix the printf warnings the output is more like:

Code:

7 = 7
999 = 999
0b101 = 5
0x5f5e0ff = 99999999
9stop = 9
Method 0 = 18446744073705503012, Method 1 = 18446713453979999608

Thank you hodor, yeah I noticed those warnings only after I posted but figured that was a minor deal compared to the ridicules output, good to know my suspicions were correct though, unfortunately encountered a bug when converting to a library for other mini-projects to use, eventually gonna put it all in one library to cover general input / output of characters, also decided that the whole dst & leng thing in the reader functions was actually a slow down since it had to check there was enough space, I instead typedef'd a char8_t fixed size array and swaped out the 2 parameters for just one using the typedef and use it directly when converting into UTF-8 or simply reading UTF-8, also finally found out what I should use for ide characters and am now working on adding that, I'm also trying to merge the unit tests of both numbers and characters into one now to give me an idea of how to handle detecting either in preperation for expression handling. As a final note I'm also planning on adding array access support for string literals to make detecting underlying types easier or something else I'm sure others will think of before me, I'm thinking the usual [ # ] is good enough, any thoughts for other stuff while I'm at it?

As it turns out the bug was in a different function, it was simply caught in ubase62

Originally Posted by awsdert

As it turns out the bug was in a different function, it was simply caught in ubase62

Which bug?

Originally Posted by Hodor

Which bug?

Originally Posted by awsdert

...unfortunately encountered a bug when converting to a library for other mini-projects to use

Originally Posted by Hodor

If the very small slowdown in speed is a problem then using the less portable non-loop version of the function might be worth it.

Also, from memory, both the loop and non-loop versions have a bug in them for bases >= 36 which I didn't mention the other day because I forgot and I couldn't work out how to demonstrate the bug anyway. [strike]I don't have the code anymore but a bool used to choose between lower and upper case characters for the conversion is not initialised (I think it was called highashigh or lowaslow or highaslow or something like that)[/strike]. Edit: actually base62.c is in your new archive for the other current question and the unitialised variable is called lowislow

Hmm, given lowislow is a parameter of the function I doubt that it could ever be uninitialised, unless the one I uploaded is different to the version I have now:

Code:

int ubase62(
	NEXTC *_nextc, uint_least64_t *dst, int base,
	bool lowislow, size_t min_len, size_t max_len )
{
	int ret = nextc_validate(_nextc), c;
	size_t i = 0, l, h;
	uint_least64_t num = 0;
	if ( !max_len ) max_len = -2;
	if ( ret != EXIT_SUCCESS )
		goto ubase62_done;
	else if ( base < 2 ) {
		ret = ERANGE;
		FAIL( stderr, ret, "base is too low!" );
		goto ubase62_done;
	}
	else if ( base <= 36 ) { l = 10; h = 10; }
	else if ( base > 62 ) {
		ret = ERANGE;
		FAIL( stderr, ret, "base is too high!" );
		goto ubase62_done;
	}
	else if ( lowislow ) { l = 10; h = 36; }
	else { l = 36; h = 10; }
	do {
		c = _nextc->c[0];
		if ( c >= U'0' && c <= U'9' )
			c -= U'0';
		else if ( c >= U'A' && c <= U'Z' )
			{ c -= U'A'; c += h; }
		else if ( c >= U'a' && c <= U'z' )
			{ c -= U'a'; c += l; }
		else break;
		if ( c >= base || i >= max_len ) break;
		num *= base;
		num += c;
		++i;
	} while ( (ret = nextc(_nextc)) == EXIT_SUCCESS );
	if ( ret != EXIT_SUCCESS )
		FAIL( stderr, ret, "" );
	if ( i < min_len ) {
		ret = ERANGE;
		FAIL( stderr, ret, "Not enough digits" );
		fprintf( stderr,
			"c = '%c', i = %zu, min_len = %zu, max_len = %zu\n",
			_nextc->c[0], i, min_len, max_len );
	}
	ubase62_done:
	if ( dst ) *dst = num;
	return ret;
}

Btw what kind of bug did you experience above base 36? I never tested that high cause I didn't expect there to be issues when it uses the same handling just with a larger range