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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox