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
next prev parent 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.