All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Mattias Rönnblom" <hofors@lysator.liu.se>
To: Stephen Hemminger <stephen@networkplumber.org>, dev@dpdk.org
Cc: "Mattias Rönnblom" <mattias.ronnblom@ericsson.com>,
	"Ray Kinsella" <mdr@ashroe.eu>
Subject: Re: [PATCH v4 1/3] random: add rte_drand() function
Date: Thu, 26 May 2022 15:20:29 +0200	[thread overview]
Message-ID: <84afee2e-fa4c-faf1-d046-febb0ae77c09@lysator.liu.se> (raw)
In-Reply-To: <20220525203123.277180-2-stephen@networkplumber.org>

On 2022-05-25 22:31, Stephen Hemminger wrote:
> The PIE code and other applications can benefit from having a
> fast way to get a random floating point value. This new function
> is equivalent to drand() in the standard library.
> 
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> ---
>   app/test/test_rand_perf.c              |  7 +++++
>   doc/guides/rel_notes/release_22_07.rst |  5 ++++
>   lib/eal/common/rte_random.c            | 41 ++++++++++++++++++++++++++
>   lib/eal/include/rte_random.h           | 18 +++++++++++
>   lib/eal/meson.build                    |  3 ++
>   lib/eal/version.map                    |  1 +
>   6 files changed, 75 insertions(+)
> 
> diff --git a/app/test/test_rand_perf.c b/app/test/test_rand_perf.c
> index fe797ebfa1ca..26fb1d9a586e 100644
> --- a/app/test/test_rand_perf.c
> +++ b/app/test/test_rand_perf.c
> @@ -20,6 +20,7 @@ static volatile uint64_t vsum;
>   
>   enum rand_type {
>   	rand_type_64,
> +	rand_type_float,
>   	rand_type_bounded_best_case,
>   	rand_type_bounded_worst_case
>   };
> @@ -30,6 +31,8 @@ rand_type_desc(enum rand_type rand_type)
>   	switch (rand_type) {
>   	case rand_type_64:
>   		return "Full 64-bit [rte_rand()]";
> +	case rand_type_float:
> +		return "Floating point [rte_drand()]";
>   	case rand_type_bounded_best_case:
>   		return "Bounded average best-case [rte_rand_max()]";
>   	case rand_type_bounded_worst_case:
> @@ -55,6 +58,9 @@ test_rand_perf_type(enum rand_type rand_type)
>   		case rand_type_64:
>   			sum += rte_rand();
>   			break;
> +		case rand_type_float:
> +			sum += 1000. * rte_drand();

Including this floating point multiplication will lead to an 
overestimation of rte_drand() latency.

You could refactor this function to be a macro, and pass the return type 
to as a parameter to this macro. I did just that, and on both an AMD 
5900X and a Cortex-A72 it didn't add more than ~5%, so I don't think 
it's necessary.

> +			break;
>   		case rand_type_bounded_best_case:
>   			sum += rte_rand_max(BEST_CASE_BOUND);
>   			break;
> @@ -83,6 +89,7 @@ test_rand_perf(void)
>   	printf("Pseudo-random number generation latencies:\n");
>   
>   	test_rand_perf_type(rand_type_64);
> +	test_rand_perf_type(rand_type_float);
>   	test_rand_perf_type(rand_type_bounded_best_case);
>   	test_rand_perf_type(rand_type_bounded_worst_case);
>   
> diff --git a/doc/guides/rel_notes/release_22_07.rst b/doc/guides/rel_notes/release_22_07.rst
> index e49cacecefd4..b131ea577226 100644
> --- a/doc/guides/rel_notes/release_22_07.rst
> +++ b/doc/guides/rel_notes/release_22_07.rst
> @@ -104,6 +104,11 @@ New Features
>     * ``RTE_EVENT_QUEUE_ATTR_WEIGHT``
>     * ``RTE_EVENT_QUEUE_ATTR_AFFINITY``
>   
> +* ** Added function get random floating point number.**
> +
> +  Added the function ``rte_drand()`` to provide a pseudo-random
> +  floating point number.
> +
>   
>   Removed Items
>   -------------
> diff --git a/lib/eal/common/rte_random.c b/lib/eal/common/rte_random.c
> index 4535cc980cec..3dc3484ee655 100644
> --- a/lib/eal/common/rte_random.c
> +++ b/lib/eal/common/rte_random.c
> @@ -6,6 +6,9 @@
>   #include <x86intrin.h>
>   #endif
>   #include <unistd.h>
> +#ifdef RTE_LIBEAL_USE_IEEE754
> +#include <ieee754.h>
> +#endif
>   
>   #include <rte_branch_prediction.h>
>   #include <rte_cycles.h>
> @@ -173,6 +176,44 @@ rte_rand_max(uint64_t upper_bound)
>   	return res;
>   }
>   
> +double
> +rte_drand(void)
> +{
> +	struct rte_rand_state *state = __rte_rand_get_state();
> +	uint64_t rand64 = __rte_rand_lfsr258(state);
> +#ifdef RTE_LIBEAL_USE_IEEE754
> +	union ieee754_double u = {
> +		.ieee = {
> +			.negative = 0,
> +			.exponent = IEEE754_DOUBLE_BIAS,
> +		},
> +	};
> +
> +	/* Take 64 bit random value and put it into the mantissa
> +	 * This uses direct access to IEEE format to avoid doing
> +	 * any direct floating point math here.
> +	 */
> +	u.ieee.mantissa0 = rand64 >> 32;
> +	u.ieee.mantissa1 = rand64;
> +
> +	return u.d - 1.0;
> +#else
> +	/* Slower method requiring floating point divide
> +	 *

Do you know how much slower? I ran rand_perf_test on two of my systems.

                       AMD 5900X     Pi4 (ARM Cortex-A72)
IEEE754 version          12              1.19
Non-IEEE754 version      11              1.16
Naive version*           24              1.16

* (double)rte_rand() / (double)UINT64_MAX

Numbers are TSC cycles/op.

Surprisingly, it seems like the IEEE754 version is slower on both of 
these machines.

Do you have a machine (or a different use case) where the supposedly 
more optimized version actually runs faster?

> +	 * The double mantissa only has 53 bits, so we uniformly mask off the
> +	 * high 11 bits and then floating-point divide by 2^53 to achieve a
> +	 * result in [0, 1).
> +	 *
> +	 * We are not allowed to emit 1.0, so denom must be one greater than
> +	 * the possible range of the preceeding step.
> +	 */
> +	static const uint64_t denom = (uint64_t)1 << 53;

Remove "static const". Surely, this can't make a difference (at least 
not in a positive direction).

> +
> +	rand64 &= denom - 1;
> +	return (double)rand64 / denom;
> +#endif
> +}
> +
>   static uint64_t
>   __rte_random_initial_seed(void)
>   {
> diff --git a/lib/eal/include/rte_random.h b/lib/eal/include/rte_random.h
> index 29f5f1325a30..f6541c2b0f08 100644
> --- a/lib/eal/include/rte_random.h
> +++ b/lib/eal/include/rte_random.h
> @@ -65,6 +65,24 @@ rte_rand(void);
>   uint64_t
>   rte_rand_max(uint64_t upper_bound);
>   
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this API may change without prior notice
> + *
> + * Generates a pseudo-random floating point number.
> + *
> + * This function returns a nonnegative double-precision floating random
> + * number uniformly distributed over the interval [0.0, 1.0).
> + *
> + * The generator is not cryptographically secure.
> + * If called from lcore threads, this function is thread-safe.
> + *
> + * @return
> + *   A pseudo-random value between 0 and 1.0.
> + */
> +__rte_experimental
> +double rte_drand(void);
> +
>   #ifdef __cplusplus
>   }
>   #endif
> diff --git a/lib/eal/meson.build b/lib/eal/meson.build
> index 056beb946119..e50524901c98 100644
> --- a/lib/eal/meson.build
> +++ b/lib/eal/meson.build
> @@ -32,3 +32,6 @@ endif
>   if cc.has_function('getentropy', prefix : '#include <unistd.h>')
>       cflags += '-DRTE_LIBEAL_USE_GETENTROPY'
>   endif
> +if cc.has_header_symbol('ieee754.h', 'union ieee754_double')
> +    cflags += '-DRTE_LIBEAL_USE_IEEE754'
> +endif
> diff --git a/lib/eal/version.map b/lib/eal/version.map
> index d49e30bd042f..cfbade9a33e9 100644
> --- a/lib/eal/version.map
> +++ b/lib/eal/version.map
> @@ -422,6 +422,7 @@ EXPERIMENTAL {
>   	rte_intr_type_set;
>   
>   	# added in 22.07
> +	rte_drand;
>   	rte_thread_get_affinity_by_id;
>   	rte_thread_self;
>   	rte_thread_set_affinity_by_id;

  parent reply	other threads:[~2022-05-26 13:20 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-24 18:46 [RFT 0/2] pie: floating point fixes Stephen Hemminger
2022-05-24 18:46 ` [RFT 1/2] rte_pie: remove unnecessary floating point Stephen Hemminger
2022-05-24 18:46 ` [RFT 2/2] rte_pie: fix incorrect floating point math Stephen Hemminger
2022-05-24 19:31 ` [RFT 0/2] pie: floating point fixes Morten Brørup
2022-05-24 22:18 ` [RFT v2 0/3] pie: fix random number issues Stephen Hemminger
2022-05-24 22:18   ` [RFT v2 1/3] random: add rte_rand_float() Stephen Hemminger
2022-05-25 11:55     ` Ray Kinsella
2022-05-25 14:45     ` Mattias Rönnblom
2022-05-25 15:26       ` Morten Brørup
2022-05-25 15:45       ` Stephen Hemminger
2022-05-25 15:47       ` Stephen Hemminger
2022-05-24 22:18   ` [RFT v2 2/3] rte_pie: remove unnecessary floating point Stephen Hemminger
2022-05-24 22:18   ` [RFT v2 3/3] rte_pie: fix incorrect floating point math Stephen Hemminger
2022-05-25 17:12 ` [PATCH v3 0/3] introduce random floating point function Stephen Hemminger
2022-05-25 17:12   ` [PATCH v3 1/3] random: add rte_drand() funciton Stephen Hemminger
2022-05-25 17:12   ` [PATCH v3 2/3] rte_pie: remove unnecessary floating point Stephen Hemminger
2022-05-25 17:12   ` [PATCH v3 3/3] rte_pie: fix incorrect floating point math Stephen Hemminger
2022-05-25 20:31 ` [PATCH v4 0/3] introduce random floating point function Stephen Hemminger
2022-05-25 20:31   ` [PATCH v4 1/3] random: add rte_drand() function Stephen Hemminger
2022-05-26  9:56     ` Ray Kinsella
2022-05-26 13:20     ` Mattias Rönnblom [this message]
2022-05-26 15:25       ` Stephen Hemminger
2022-05-26 15:28       ` Stephen Hemminger
2022-05-26 20:19       ` Stephen Hemminger
2022-05-25 20:31   ` [PATCH v4 2/3] rte_pie: remove unnecessary floating point Stephen Hemminger
2022-05-25 20:31   ` [PATCH v4 3/3] rte_pie: fix incorrect floating point math Stephen Hemminger
2022-05-26  7:06   ` [PATCH v4 0/3] introduce random floating point function Morten Brørup
2022-05-26 20:26 ` [PATCH v5 " Stephen Hemminger
2022-05-26 20:26   ` [PATCH v5 1/3] random: add rte_drand() function Stephen Hemminger
2022-05-26 20:26   ` [PATCH v5 2/3] rte_pie: remove unnecessary floating point Stephen Hemminger
2022-05-30 11:50     ` Dumitrescu, Cristian
2022-06-21  8:18     ` Singh, Jasvinder
2022-05-26 20:26   ` [PATCH v5 3/3] rte_pie: fix incorrect floating point math Stephen Hemminger
2022-05-30 11:50     ` Dumitrescu, Cristian
2022-06-21  8:18     ` Singh, Jasvinder
2022-06-22  9:21   ` [PATCH v5 0/3] introduce random floating point function Thomas Monjalon

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=84afee2e-fa4c-faf1-d046-febb0ae77c09@lysator.liu.se \
    --to=hofors@lysator.liu.se \
    --cc=dev@dpdk.org \
    --cc=mattias.ronnblom@ericsson.com \
    --cc=mdr@ashroe.eu \
    --cc=stephen@networkplumber.org \
    /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.