public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Denys Vlasenko <vda.linux@googlemail.com>
To: Michal Nazarewicz <mina86@mina86.com>
Cc: linux-kernel@vger.kernel.org, m.nazarewicz@samsung.com,
	"Douglas W. Jones" <jones@cs.uiowa.edu>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH 3/3] lib: vsprintf: added a put_dec() test and benchmark tool
Date: Fri, 6 Aug 2010 07:10:06 +0200	[thread overview]
Message-ID: <201008060710.06304.vda.linux@googlemail.com> (raw)
In-Reply-To: <b3cd8c92d68f3ca7104be13841f1f66f7db9f7e1.1280872240.git.mina86@mina86.com>

On Friday 06 August 2010 00:38, Michal Nazarewicz wrote:
> This commit adds a test application for the put_dec() and
> family of functions that are used by the previous two commits.
> 
> Signed-off-by: Michal Nazarewicz <mina86@mina86.com>

> +put-dec-test: put-dec-test.c
> +	exec $(CC) $(CFLAGS) -o $@ $<

(1) Why exec?
(2) Add -Wall, you'd be surprised


> +static uint64_t rand_64(void)
> +{
> +	uint64_t v = 0, m = 1;
> +	for (;;) {
> +		uint64_t n;
> +		v = m * rand();
> +		n = m + m * RAND_MAX;
> +		if (n < m)
> +			break;
> +		m = n;
> +	}
> +	return v;
> +}

What this function do? Looks cryptic. In my testing, it picks 0
quite often.


> +static char buf1[24];

Can you size the array safely, without assuming that long long
is no wider than 64 bits?


> +#define FUNC(func, outer, inner, correction, format, value) do {	\
> +		struct timeval start;					\
> +		unsigned i, o;						\
> +		for (i = (inner); i--; ) {				\
> +			typeof(value) v = (value);			\
> +			ret |= test(#func, func(buf1, v), format, v);	\

I'd add memset(buf1, 77, sizeof(buf1)) before test


> +int main(int argc, char **argv) {
> +	unsigned long iterations = 1000, i;
> +	struct timeval correction;
> +	int ret = 0;
> +
> +	srand(time(NULL));
> +
> +	if (argc > 1)
> +		iterations = atoi(argv[1]);
> +
> +	gettimeofday(&correction, NULL);
> +	for (i = 25000 * iterations; i; --i)
> +		rand_64();
> +	stop(NULL, &correction, NULL);

Why is this "correction" thing needed? I looked at the entire machinery
and I see no reason to have it.


> +	puts(">> Benchmarks:\n\tput_dec_full()");
> +	fflush(NULL);
> +
> +	FUNC(orig_put_dec_full, iterations, 100000, NULL, "%05u", i);

You have variable named i, you pass it as macro parameter,
but macro has local variable named i too.
Is it an International Obfuscated C Code Contest entry?


> +	FUNC(mod1_put_dec_full, iterations, 100000, NULL, "%05u", i);
> +	FUNC(mod3_put_dec_full, iterations, 100000, NULL, "%05u", i);
> +	FUNC(mod5_put_dec_full, iterations * 10, 10000, NULL, "%04u", i);

> +	puts("\tput_dec_trunc()");
> +	fflush(NULL);
> +
> +	FUNC(orig_put_dec_trunc, iterations, 100000, NULL, "%u", i);
> +	FUNC(mod1_put_dec_trunc, iterations, 100000, NULL, "%u", i);
> +	FUNC(mod3_put_dec_trunc, iterations, 100000, NULL, "%u", i);
> +	FUNC(mod5_put_dec_trunc, iterations * 10, 10000, NULL, "%u", i);
> +	FUNC(mod3_put_dec_8bit, iterations * 500, 256, NULL, "%u", i);

> +	puts("\n\tput_dec()");
> +	fflush(NULL);
> +
> +	FUNC(orig_put_dec, iterations / 4, 100000, &correction, "%llu", rand_64());

"%llu" fmt is for unsigned long long, not uint64_t.


> +	FUNC(mod1_put_dec, iterations / 4, 100000, &correction, "%llu", rand_64());
> +	FUNC(mod2_put_dec, iterations / 4, 100000, &correction, "%llu", rand_64());
> +	FUNC(mod3_put_dec, iterations / 4, 100000, &correction, "%llu", rand_64());
> +	FUNC(mod4_put_dec, iterations / 4, 100000, &correction, "%llu", rand_64());
> +	FUNC(mod5_put_dec, iterations / 4, 100000, &correction, "%llu", rand_64());
> +	FUNC(mod6_put_dec, iterations / 4, 100000, &correction, "%llu", rand_64());
> +	FUNC(mod7_put_dec, iterations / 4, 100000, &correction, "%llu", rand_64());
> +	FUNC(mod8_put_dec, iterations / 4, 100000, &correction, "%llu", rand_64());

Here a lot of CPU time is taken by rand() calls. Also, you use different
values for different functions, which is wrong.


-- 
vda

  reply	other threads:[~2010-08-06  5:10 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-05 22:38 [PATCH 1/3] lib: vsprintf: optimised put_dec_trunc() and put_dec_full() Michal Nazarewicz
2010-08-05 22:38 ` [PATCH 2/3] lib: vsprintf: optimised put_dec() for 32-bit machines Michal Nazarewicz
2010-08-05 22:38   ` [PATCH 3/3] lib: vsprintf: added a put_dec() test and benchmark tool Michal Nazarewicz
2010-08-06  5:10     ` Denys Vlasenko [this message]
2010-08-06  8:34       ` Michał Nazarewicz
2010-08-06 15:57         ` Raja R Harinath
2010-08-06 19:26         ` Denys Vlasenko
2010-08-06 20:58           ` Michal Nazarewicz
2010-08-06  5:18   ` [PATCH 2/3] lib: vsprintf: optimised put_dec() for 32-bit machines Denys Vlasenko
2010-08-06  7:08     ` Michal Nazarewicz
2010-08-06  7:35       ` Denys Vlasenko
2010-08-06  8:54         ` Michał Nazarewicz
2010-08-06  3:58 ` [PATCH 1/3] lib: vsprintf: optimised put_dec_trunc() and put_dec_full() Denys Vlasenko
2010-08-06  6:56   ` Michal Nazarewicz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201008060710.06304.vda.linux@googlemail.com \
    --to=vda.linux@googlemail.com \
    --cc=akpm@linux-foundation.org \
    --cc=jones@cs.uiowa.edu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=m.nazarewicz@samsung.com \
    --cc=mina86@mina86.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox