All of lore.kernel.org
 help / color / mirror / Atom feed
From: Linhaifeng <haifeng.lin-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
To: Bruce Richardson
	<bruce.richardson-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
	Tetsuya Mukawa <mukawa-AlSX/UN32fvPDbFq/vQRIQ@public.gmane.org>
Cc: "dev-VfR2kkLFssw@public.gmane.org" <dev-VfR2kkLFssw@public.gmane.org>
Subject: Re: some questions about  rte_memcpy
Date: Thu, 22 Jan 2015 20:53:13 +0800	[thread overview]
Message-ID: <54C0F2B9.7050006@huawei.com> (raw)
In-Reply-To: <20150122113426.GC4580@bricha3-MOBL3>



On 2015/1/22 19:34, Bruce Richardson wrote:
> On Thu, Jan 22, 2015 at 07:23:49PM +0900, Tetsuya Mukawa wrote:
>> On 2015/01/22 16:35, Matthew Hall wrote:
>>> On Thu, Jan 22, 2015 at 01:32:04PM +0800, Linhaifeng wrote:
>>>> Do you mean if call rte_memcpy before rte_eal_init() would crash?why?
>>> No guarantee. But a theory. It might use some things from the EAL init to 
>>> figure out which version of the accelerated algorithm to use.
>>
>> This selection is done at compile-time.
>> And if the size is constant, I guess DPDK assumes memcpy is replaced by
>> inline __builtin_memcpy.
>> I haven't checked the performance of builtin memcpy, but probably much
>> faster.
>>
> 
> Yes, that assumption is correct. A couple of years ago we discovered that for
> constant size values, the compiler would generate much faster code for us
> using a regular memcpy than rte_memcpy, hence the macro.
> 
> /Bruce
> 
>> Tetsuya
>>
>>> Matthew.
>>
>>
> 
> 

Hi,Bruce

I test it,most results like you said use constant may be faster,but sometimes not.

linux-mnSyvH:/mnt/sdb/linhf/test # ./rte_memcpy_test 16 9999999
rte_memcpy(constant) used:279893712	@@@@@@@@@@@@@@ not faster
rte_memcpy(variable) used:277818600
linux-mnSyvH:/mnt/sdb/linhf/test # ./rte_memcpy_test 16 9999999
rte_memcpy(constant) used:279264328	@@@@@@@@@@@@@@ not faster
rte_memcpy(variable) used:277667116
linux-mnSyvH:/mnt/sdb/linhf/test # ./rte_memcpy_test 16 9999999
rte_memcpy(constant) used:279491832	@@@@@@@@@@@@@@ not faster
rte_memcpy(variable) used:277622772
linux-mnSyvH:/mnt/sdb/linhf/test # ./rte_memcpy_test 32 9999999
rte_memcpy(constant) used:279402156	@@@@@@@@@@@@@@ not faster
rte_memcpy(variable) used:277738464
linux-mnSyvH:/mnt/sdb/linhf/test # ./rte_memcpy_test 32 9999999
rte_memcpy(constant) used:279305172	@@@@@@@@@@@@@@ not faster
rte_memcpy(variable) used:277483004
linux-mnSyvH:/mnt/sdb/linhf/test # ./rte_memcpy_test 32 9999999
rte_memcpy(constant) used:279784124	@@@@@@@@@@@@@@ not faster
rte_memcpy(variable) used:277605332
linux-mnSyvH:/mnt/sdb/linhf/test # ./rte_memcpy_test 48 9999999
rte_memcpy(constant) used:322817260
rte_memcpy(variable) used:350333864
linux-mnSyvH:/mnt/sdb/linhf/test # ./rte_memcpy_test 48 9999999
rte_memcpy(constant) used:322840748
rte_memcpy(variable) used:350297868
linux-mnSyvH:/mnt/sdb/linhf/test # ./rte_memcpy_test 48 9999999
rte_memcpy(constant) used:322488240
rte_memcpy(variable) used:350348652
linux-mnSyvH:/mnt/sdb/linhf/test # ./rte_memcpy_test 64 9999999
rte_memcpy(constant) used:322021428
rte_memcpy(variable) used:350416440
linux-mnSyvH:/mnt/sdb/linhf/test # ./rte_memcpy_test 64 9999999
rte_memcpy(constant) used:321370900
rte_memcpy(variable) used:350355796
linux-mnSyvH:/mnt/sdb/linhf/test # ./rte_memcpy_test 64 9999999
rte_memcpy(constant) used:322704552
rte_memcpy(variable) used:349900832
linux-mnSyvH:/mnt/sdb/linhf/test # ./rte_memcpy_test 128 9999999
rte_memcpy(constant) used:422705828
rte_memcpy(variable) used:425493328
linux-mnSyvH:/mnt/sdb/linhf/test # ./rte_memcpy_test 128 9999999
rte_memcpy(constant) used:422421840	@@@@@@@@@@@@@@ not faster
rte_memcpy(variable) used:413691412
linux-mnSyvH:/mnt/sdb/linhf/test # ./rte_memcpy_test 128 9999999
rte_memcpy(constant) used:425233088	@@@@@@@@@@@@@@ not faster
rte_memcpy(variable) used:421136724
linux-mnSyvH:/mnt/sdb/linhf/test # ./rte_memcpy_test 256 9999999
rte_memcpy(constant) used:901014608	@@@@@@@@@@@@@@ not faster
rte_memcpy(variable) used:900997388
linux-mnSyvH:/mnt/sdb/linhf/test # ./rte_memcpy_test 256 9999999
rte_memcpy(constant) used:900803308	@@@@@@@@@@@@@@ not faster
rte_memcpy(variable) used:900794076
linux-mnSyvH:/mnt/sdb/linhf/test # ./rte_memcpy_test 256 9999999
rte_memcpy(constant) used:901842436	@@@@@@@@@@@@@@ not faster
rte_memcpy(variable) used:901218984
linux-mnSyvH:/mnt/sdb/linhf/test #



here is my test codes:

#include <stdio.h>
#include <rte_memcpy.h>
#include <rte_cycles.h>


int main(int narg, char** args)
{
        int i;
        char buf[1024];
        uint64_t start, end;

        if (narg < 3) {
                printf("usage:./rte_memcpy_test size times\n");
                return 0;
        }

        size_t size_v = atoi(args[1]);
        const size_t size_c = atoi(args[1]);
        int times = atoi(args[2]);

        start = rte_rdtsc();
        for(i = 0; i < times; i++) {
                rte_memcpy(buf, buf, size_c);
        }
        end = rte_rdtsc();
        printf("rte_memcpy(constant) used:%llu\n", end - start);

        start = rte_rdtsc();
        for (i = 0; i < times; i++) {
                rte_memcpy(buf, buf, size_v);
        }
        end = rte_rdtsc();
        printf("rte_memcpy(variable) used:%llu\n", end - start);

        return 0;
}





-- 
Regards,
Haifeng

  reply	other threads:[~2015-01-22 12:53 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-22  3:39 some questions about rte_memcpy Linhaifeng
     [not found] ` <54C070DF.1050006-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
2015-01-22  4:45   ` Matthew Hall
     [not found]     ` <20150122044531.GA13230-Hv3ogNYU3JfZZajBQzqCxQ@public.gmane.org>
2015-01-22  5:32       ` Linhaifeng
     [not found]         ` <54C08B54.50700-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
2015-01-22  7:35           ` Matthew Hall
     [not found]             ` <20150122073526.GA14800-Hv3ogNYU3JfZZajBQzqCxQ@public.gmane.org>
2015-01-22 10:23               ` Tetsuya Mukawa
     [not found]                 ` <54C0CFB5.909-AlSX/UN32fvPDbFq/vQRIQ@public.gmane.org>
2015-01-22 11:34                   ` Bruce Richardson
2015-01-22 12:53                     ` Linhaifeng [this message]
     [not found]                       ` <54C0F2B9.7050006-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
2015-01-22 15:21                         ` Bruce Richardson
2015-01-23  2:58                           ` Linhaifeng

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=54C0F2B9.7050006@huawei.com \
    --to=haifeng.lin-hv44wf8li93qt0dzr+alfa@public.gmane.org \
    --cc=bruce.richardson-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
    --cc=dev-VfR2kkLFssw@public.gmane.org \
    --cc=mukawa-AlSX/UN32fvPDbFq/vQRIQ@public.gmane.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.