Groups > comp.lang.c++ > #70942 > unrolled thread

Union type punning in C++

Started by	Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>
First post	2020-01-01 19:24 +0000
Last post	2020-01-13 16:29 -0800
Articles	20 on this page of 135 — 18 participants

Back to article view | Back to comp.lang.c++

  Union type punning in C++ Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2020-01-01 19:24 +0000
    Re: Union type punning in C++ boltar@nowhere.org - 2020-01-02 09:36 +0000
    Re: Union type punning in C++ Öö Tiib <ootiib@hot.ee> - 2020-01-02 03:34 -0800
      Re: Union type punning in C++ Bo Persson <bo@bo-persson.se> - 2020-01-02 12:49 +0100
        Re: Union type punning in C++ Öö Tiib <ootiib@hot.ee> - 2020-01-02 04:52 -0800
          Re: Union type punning in C++ boltar@nowhere.org - 2020-01-02 17:22 +0000
            Re: Union type punning in C++ Öö Tiib <ootiib@hot.ee> - 2020-01-02 10:26 -0800
              Re: Union type punning in C++ Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2020-01-02 21:54 +0000
                Re: Union type punning in C++ boltar@nowhere.org - 2020-01-03 14:49 +0000
                  Re: Union type punning in C++ David Brown <david.brown@hesbynett.no> - 2020-01-03 17:11 +0100
                  Re: Union type punning in C++ Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2020-01-03 17:55 +0000
              Re: Union type punning in C++ boltar@nowhere.org - 2020-01-03 09:55 +0000
                Re: Union type punning in C++ David Brown <david.brown@hesbynett.no> - 2020-01-03 11:20 +0100
                Re: Union type punning in C++ Öö Tiib <ootiib@hot.ee> - 2020-01-03 02:21 -0800
                  Re: Union type punning in C++ boltar@nowhere.org - 2020-01-03 14:55 +0000
                    Re: Union type punning in C++ Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-03 16:04 +0100
                      Re: Union type punning in C++ "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-01-03 14:45 -0800
                        Re: Union type punning in C++ Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-04 01:26 +0100
                          Re: Union type punning in C++ "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-01-03 16:55 -0800
                            Re: Union type punning in C++ Melzzzzz <Melzzzzz@zzzzz.com> - 2020-01-04 01:02 +0000
                              Re: Union type punning in C++ "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-01-03 17:06 -0800
                    Re: Union type punning in C++ Öö Tiib <ootiib@hot.ee> - 2020-01-03 07:34 -0800
                      Re: Union type punning in C++ boltar@nowhere.org - 2020-01-03 16:12 +0000
                        Re: Union type punning in C++ Öö Tiib <ootiib@hot.ee> - 2020-01-03 08:49 -0800
                        Re: Union type punning in C++ Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-03 19:28 +0100
                          Re: Union type punning in C++ Melzzzzz <Melzzzzz@zzzzz.com> - 2020-01-03 18:54 +0000
                            Re: Union type punning in C++ Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-04 01:25 +0100
                              Re: Union type punning in C++ Melzzzzz <Melzzzzz@zzzzz.com> - 2020-01-04 00:28 +0000
                                Re: Union type punning in C++ Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-04 01:41 +0100
                                  Re: Union type punning in C++ Melzzzzz <Melzzzzz@zzzzz.com> - 2020-01-04 00:52 +0000
                                    Re: Union type punning in C++ Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-04 08:08 +0100
                                      Re: Union type punning in C++ Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-04 08:34 +0100
                                        Re: Union type punning in C++ Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-04 08:43 +0100
                                        Re: Union type punning in C++ Melzzzzz <Melzzzzz@zzzzz.com> - 2020-01-04 08:20 +0000
                                          Re: Union type punning in C++ Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-04 09:25 +0100
                                      Re: Union type punning in C++ Melzzzzz <Melzzzzz@zzzzz.com> - 2020-01-04 08:25 +0000
                                        Re: Union type punning in C++ Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-04 09:25 +0100
                                          Re: Union type punning in C++ Melzzzzz <Melzzzzz@zzzzz.com> - 2020-01-04 08:27 +0000
                                            Re: Union type punning in C++ Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-04 09:36 +0100
                                              Re: Union type punning in C++ Melzzzzz <Melzzzzz@zzzzz.com> - 2020-01-04 08:41 +0000
                                                Re: Union type punning in C++ Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-04 09:49 +0100
                                                  Re: Union type punning in C++ Melzzzzz <Melzzzzz@zzzzz.com> - 2020-01-04 09:01 +0000
                                                    Re: Union type punning in C++ Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-04 10:02 +0100
                                                      Re: Union type punning in C++ Melzzzzz <Melzzzzz@zzzzz.com> - 2020-01-04 09:19 +0000
                                                        Re: Union type punning in C++ Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-04 10:38 +0100
                              Re: Union type punning in C++ David Brown <david.brown@hesbynett.no> - 2020-01-04 12:45 +0100
                                Re: Union type punning in C++ Melzzzzz <Melzzzzz@zzzzz.com> - 2020-01-04 12:00 +0000
                                  Re: Union type punning in C++ Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-04 13:03 +0100
                                Re: Union type punning in C++ Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-04 14:22 +0100
                        Re: Union type punning in C++ "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-01-03 14:46 -0800
                      Re: Union type punning in C++ Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-01-03 10:32 -0800
                        Re: Union type punning in C++ Öö Tiib <ootiib@hot.ee> - 2020-01-03 10:43 -0800
                          Re: Union type punning in C++ Melzzzzz <Melzzzzz@zzzzz.com> - 2020-01-03 18:55 +0000
              Re: Union type punning in C++ Daniel <danielaparker@gmail.com> - 2020-01-08 09:40 -0800
                Re: Union type punning in C++ Öö Tiib <ootiib@hot.ee> - 2020-01-08 13:23 -0800
                  Re: Union type punning in C++ Daniel <danielaparker@gmail.com> - 2020-01-08 22:41 -0800
                  Re: Union type punning in C++ Daniel <danielaparker@gmail.com> - 2020-01-08 22:52 -0800
                    Re: Union type punning in C++ Öö Tiib <ootiib@hot.ee> - 2020-01-09 12:59 -0800
                      Re: Union type punning in C++ Daniel <danielaparker@gmail.com> - 2020-01-09 13:32 -0800
                      Re: Union type punning in C++ Mister2U@honorific.org - 2020-01-10 12:28 +0000
                        Re: Union type punning in C++ David Brown <david.brown@hesbynett.no> - 2020-01-10 14:02 +0100
                          Re: Union type punning in C++ Mister2U@honorific.org - 2020-01-10 16:21 +0000
                            Re: Union type punning in C++ David Brown <david.brown@hesbynett.no> - 2020-01-10 19:18 +0100
                              Re: Union type punning in C++ Daniel <danielaparker@gmail.com> - 2020-01-10 15:41 -0800
                                Re: Union type punning in C++ David Brown <david.brown@hesbynett.no> - 2020-01-11 12:01 +0100
                                  Re: Union type punning in C++ Daniel <danielaparker@gmail.com> - 2020-01-11 07:05 -0800
                                    Re: Union type punning in C++ David Brown <david.brown@hesbynett.no> - 2020-01-11 23:53 +0100
                                      Re: Union type punning in C++ Mr Flibble <flibble@i42.removethisbit.co.uk> - 2020-01-12 01:41 +0000
                                        Re: Union type punning in C++ Daniel <danielaparker@gmail.com> - 2020-01-11 19:00 -0800
                                          Re: Union type punning in C++ Mr Flibble <flibble@i42.removethisbit.co.uk> - 2020-01-13 17:32 +0000
                              Re: Union type punning in C++ Mister2U@honorific.org - 2020-01-11 11:53 +0000
                                Re: Union type punning in C++ David Brown <david.brown@hesbynett.no> - 2020-01-11 13:20 +0100
                                  Re: Union type punning in C++ Mister2U@honorific.org - 2020-01-11 12:33 +0000
                                    Re: Union type punning in C++ David Brown <david.brown@hesbynett.no> - 2020-01-11 14:28 +0100
                            Re: Union type punning in C++ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-01-11 10:48 +0000
                        Re: Union type punning in C++ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-01-11 11:05 +0000
                          Re: Union type punning in C++ Mister2U@honorific.org - 2020-01-11 11:55 +0000
            Re: Union type punning in C++ Bo Persson <bo@bo-persson.se> - 2020-01-02 21:12 +0100
              Re: Union type punning in C++ boltar@nowhere.org - 2020-01-03 14:46 +0000
                Re: Union type punning in C++ Bo Persson <bo@bo-persson.se> - 2020-01-03 20:01 +0100
            Re: Union type punning in C++ David Brown <david.brown@hesbynett.no> - 2020-01-02 23:23 +0100
    Re: Union type punning in C++ peter koch <peter.koch.larsen@gmail.com> - 2020-01-02 12:39 -0800
    Re: Union type punning in C++ "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-01-02 15:39 -0800
      Re: Union type punning in C++ Öö Tiib <ootiib@hot.ee> - 2020-01-02 16:58 -0800
        Re: Union type punning in C++ "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-01-02 17:55 -0800
          Re: Union type punning in C++ Öö Tiib <ootiib@hot.ee> - 2020-01-03 00:40 -0800
            Re: Union type punning in C++ Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2020-01-03 14:04 +0000
              Re: Union type punning in C++ David Brown <david.brown@hesbynett.no> - 2020-01-03 15:24 +0100
                Re: Union type punning in C++ "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-01-03 14:34 -0800
                  Re: Union type punning in C++ Melzzzzz <Melzzzzz@zzzzz.com> - 2020-01-03 22:59 +0000
                    Re: Union type punning in C++ Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2020-01-04 00:11 +0000
                      Re: Union type punning in C++ Melzzzzz <Melzzzzz@zzzzz.com> - 2020-01-04 00:21 +0000
                        Re: Union type punning in C++ Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2020-01-04 00:26 +0000
                          Re: Union type punning in C++ "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-01-04 16:51 -0800
                      Re: Union type punning in C++ "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-01-03 18:47 -0800
                        Re: Union type punning in C++ "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-01-03 19:07 -0800
              Re: Union type punning in C++ Öö Tiib <ootiib@hot.ee> - 2020-01-03 06:47 -0800
                Re: Union type punning in C++ Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2020-01-03 14:57 +0000
                  Re: Union type punning in C++ Öö Tiib <ootiib@hot.ee> - 2020-01-03 07:38 -0800
                    Re: Union type punning in C++ Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2020-01-03 17:06 +0000
                      Re: Union type punning in C++ Öö Tiib <ootiib@hot.ee> - 2020-01-03 11:05 -0800
            Re: Union type punning in C++ "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-01-03 14:38 -0800
              Re: Union type punning in C++ Öö Tiib <ootiib@hot.ee> - 2020-01-03 22:37 -0800
        Re: Union type punning in C++ Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-11 07:10 -0800
          Re: Union type punning in C++ Öö Tiib <ootiib@hot.ee> - 2020-01-11 10:23 -0800
            Re: Union type punning in C++ Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-13 09:01 -0800
              Re: Union type punning in C++ Öö Tiib <ootiib@hot.ee> - 2020-01-13 11:03 -0800
                Re: Union type punning in C++ James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-13 12:48 -0800
                  Re: Union type punning in C++ Öö Tiib <ootiib@hot.ee> - 2020-01-13 14:15 -0800
                    Re: Union type punning in C++ James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-13 21:47 -0500
                      Re: Union type punning in C++ Öö Tiib <ootiib@hot.ee> - 2020-01-13 23:44 -0800
                        Re: Union type punning in C++ James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-14 08:26 -0500
                Re: Union type punning in C++ Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-14 07:30 -0800
                  Re: Union type punning in C++ Öö Tiib <ootiib@hot.ee> - 2020-01-14 09:11 -0800
                    Re: Union type punning in C++ James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-14 21:52 -0500
                      Re: Union type punning in C++ Öö Tiib <ootiib@hot.ee> - 2020-01-14 23:15 -0800
                    Re: Union type punning in C++ Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-21 02:03 -0800
      Re: Union type punning in C++ Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-11 07:28 -0800
        Re: Union type punning in C++ "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-01-11 20:40 -0800
          Re: Union type punning in C++ James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-12 20:16 -0500
            Re: Union type punning in C++ "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-01-12 17:28 -0800
              Re: Union type punning in C++ James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-12 21:53 -0500
                Re: Union type punning in C++ Manfred <noname@add.invalid> - 2020-01-13 18:50 +0100
                Re: Union type punning in C++ "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-01-13 16:21 -0800
              Re: Union type punning in C++ Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-13 08:57 -0800
                Re: Union type punning in C++ "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-01-13 16:27 -0800
                  Re: Union type punning in C++ Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-14 07:05 -0800
                    Re: Union type punning in C++ "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-01-14 20:58 -0800
                      Re: Union type punning in C++ Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-21 03:47 -0800
              Re: Union type punning in C++ Öö Tiib <ootiib@hot.ee> - 2020-01-15 01:22 -0800
                Re: Union type punning in C++ James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-15 08:04 -0500
                  Re: Union type punning in C++ Öö Tiib <ootiib@hot.ee> - 2020-01-15 09:38 -0800
                    Re: Union type punning in C++ James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-15 11:01 -0800
          Re: Union type punning in C++ Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-13 08:37 -0800
            Re: Union type punning in C++ "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-01-13 16:29 -0800

Page 3 of 7 — ← Prev page 1 2 [3] 4 5 6 7 Next page →

#71096

From	Bonita Montero <Bonita.Montero@gmail.com>
Date	2020-01-04 09:49 +0100
Message-ID	<qupjj0$fsc$1@news.albasani.net>
In reply to	#71094

> No, you are buffon. I just commented on assembly output.
> It would be interresting what code would gcc generate on
> larger blocks...

But this isn't true:

> For small blocks movs instructions are better. For big ones
> opposite.

[toc] | [prev] | [next] | [standalone]

#71097

From	Melzzzzz <Melzzzzz@zzzzz.com>
Date	2020-01-04 09:01 +0000
Message-ID	<vvYPF.387599$zP6.333132@fx03.am4>
In reply to	#71096

On 2020-01-04, Bonita Montero <Bonita.Montero@gmail.com> wrote:
>> No, you are buffon. I just commented on assembly output.
>> It would be interresting what code would gcc generate on
>> larger blocks...
>
> But this isn't true:
>
>> For small blocks movs instructions are better. For big ones
>> opposite.
You will never learn anything. Because you don't listen more
experienced...

-- 
press any key to continue or any other to quit...
U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec
Svi smo svedoci - oko 3 godine intenzivne propagande je dovoljno da jedan narod poludi --  Zli Zec
Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi 
bili naoruzani. -- Mladen Gogala

[toc] | [prev] | [next] | [standalone]

#71098

From	Bonita Montero <Bonita.Montero@gmail.com>
Date	2020-01-04 10:02 +0100
Message-ID	<qupkb6$cff$1@news.albasani.net>
In reply to	#71097

>>> For small blocks movs instructions are better. For big ones
>>> opposite.

> You will never learn anything. Because you don't listen more
> experienced...

I'll listen to the experience of the compiler-writers.
They're have for sure more experience than you.

[toc] | [prev] | [next] | [standalone]

#71099

From	Melzzzzz <Melzzzzz@zzzzz.com>
Date	2020-01-04 09:19 +0000
Message-ID	<UMYPF.288054$jm4.146016@fx28.am4>
In reply to	#71098

On 2020-01-04, Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>>> For small blocks movs instructions are better. For big ones
>>>> opposite.
>
>> You will never learn anything. Because you don't listen more
>> experienced...
>
> I'll listen to the experience of the compiler-writers.
> They're have for sure more experience than you.

You are dumb. You clearly see different code that does not holds your
presumption. If that was true generated assembly code for same code snippet
would be same and all compilers woudl be equally efficient. Not ralizing
taht fact makes you a dumb.


-- 
press any key to continue or any other to quit...
U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec
Svi smo svedoci - oko 3 godine intenzivne propagande je dovoljno da jedan narod poludi --  Zli Zec
Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi 
bili naoruzani. -- Mladen Gogala

[toc] | [prev] | [next] | [standalone]

#71100

From	Bonita Montero <Bonita.Montero@gmail.com>
Date	2020-01-04 10:38 +0100
Message-ID	<qupmfc$8o5$1@news.albasani.net>
In reply to	#71099

Am 04.01.2020 um 10:19 schrieb Melzzzzz:
> On 2020-01-04, Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>>>> For small blocks movs instructions are better. For big ones
>>>>> opposite.
>>
>>> You will never learn anything. Because you don't listen more
>>> experienced...
>>
>> I'll listen to the experience of the compiler-writers.
>> They're have for sure more experience than you.
> 
> You are dumb. You clearly see different code that does not holds your
> presumption. If that was true generated assembly code for same code snippet
> would be same and all compilers woudl be equally efficient. Not ralizing
> taht fact makes you a dumb.

Look at this:

#include <iostream>
#include <cstring>
#include <cstdint>
#include <chrono>

using namespace std;
using namespace chrono;

extern "C" void fAvx();
extern "C" void fMovs();

int main()
{
	using timestamp = time_point<high_resolution_clock>;
	timestamp start = high_resolution_clock::now();
	fAvx();
	uint64_t ns = (uint64_t)duration_cast<nanoseconds>( 
high_resolution_clock::now() - start ).count();;
	cout << (double)ns / 1.0E6 << "ms" << endl;
	start = high_resolution_clock::now();
	fMovs();
	ns = (uint64_t)duration_cast<nanoseconds>( high_resolution_clock::now() 
- start ).count();;
	cout << (double)ns / 1.0E6 << "ms" << endl;
}

And the assembly code fopr fAvx and fMovs:

_TEXT SEGMENT

fAvx PROC
	sub     rsp, 64
	mov     rdx, 1000000000
avxLoop:
	vmovups ymm0, [rsp]
	vmovups [rsp + 32], ymm0
	dec     rdx
	jnz     avxLoop
	add     rsp, 64
	ret
fAvx ENDP

fMovs PROC
	push    rsi
	push    rdi
	sub     rsp, 64
	mov     rdx, 1000000000
movsLoop:
	mov     rcx, 4
	mov     rsi, rsp
	lea     rdi, [rsp + 32]
	rep movsq
	dec     rdx
	jnz     movsLoop
	add     rsp, 64
	pop     rdi
	pop     rsi
	ret
fMovs ENDP

_TEXT ENDS
END

I repeatedly copy 32 bytes - _a_small_amount_of_memory_ and according
what you say copying with movs should be faster here. But on my computer
fAvx is 6,6 times faster. Any questions?

[toc] | [prev] | [next] | [standalone]

#71103

From	David Brown <david.brown@hesbynett.no>
Date	2020-01-04 12:45 +0100
Message-ID	<quptru$7j6$1@dont-email.me>
In reply to	#71062

On 04/01/2020 01:25, Bonita Montero wrote:
>> For small blocks movs instructions are better.
>> For big ones opposite.
> 
> The compiler knows better than stupid Melzzz.
> 

I suspect the results will be highly dependent on details, like the 
exact chip you are using, and where you draw the line between "small 
blocks" and "big blocks".

Compiler writers put a lot of effort into fine-tuning this kind of thing 
for different situations.  But the compiler can only optimise on the 
basis of the information you give it.  If you want optimal code for a 
particular device, you have to tell the compiler exactly which device 
you want to target (and what devices you want to support, which is not 
necessarily the same thing).  Then it can make a stab at picking the 
right kind of instructions here - whether it is SIMD, loops, rep 
instructions, AVX, or whatever.

Different compilers can make different assumptions about the target 
device, when this information is missing from the command lines.

So in any argument about which instruction sequence is "best", it is 
entirely possible for both sides to be right and very likely that the 
argument is pointless.

[toc] | [prev] | [next] | [standalone]

#71104

From	Melzzzzz <Melzzzzz@zzzzz.com>
Date	2020-01-04 12:00 +0000
Message-ID	<a7%PF.63893$Kj.62468@fx21.am4>
In reply to	#71103

On 2020-01-04, David Brown <david.brown@hesbynett.no> wrote:
> On 04/01/2020 01:25, Bonita Montero wrote:
>>> For small blocks movs instructions are better.
>>> For big ones opposite.
>> 
>> The compiler knows better than stupid Melzzz.
>> 
>
> I suspect the results will be highly dependent on details, like the 
> exact chip you are using, and where you draw the line between "small 
> blocks" and "big blocks".
>
> Compiler writers put a lot of effort into fine-tuning this kind of thing 
> for different situations.  But the compiler can only optimise on the 
> basis of the information you give it.  If you want optimal code for a 
> particular device, you have to tell the compiler exactly which device 
> you want to target (and what devices you want to support, which is not 
> necessarily the same thing).  Then it can make a stab at picking the 
> right kind of instructions here - whether it is SIMD, loops, rep 
> instructions, AVX, or whatever.
>
> Different compilers can make different assumptions about the target 
> device, when this information is missing from the command lines.
>
> So in any argument about which instruction sequence is "best", it is 
> entirely possible for both sides to be right and very likely that the 
> argument is pointless.

In this particular case gcc is right and VC is wrong.
~/examples/assembler >>> ./rdtscp 1000000                                                                                                                                                                                      
1000000 128 byte blocks, loops:4
rep movsb                       0.01132903184211
rep movsq                       0.01134612947368
movntdq                         0.00317828842105
movntdq prefetch                0.00316638236842
movntdq prefetch ymm            0.00316397368421
~/examples/assembler >>> ./rdtscp 1                                                                                                                                                                                        [32]
1 128 byte blocks, loops:4000000
rep movsb                       0.00000002601557
rep movsq                       0.00000001063161
movntdq                         0.00000008210285
movntdq prefetch                0.00000008319713
movntdq prefetch ymm            0.00000008284743

simply put for large blocks SSE2/AVX2 is better for
small movs on both Intel and AMD.
On Intel pre Zen2 AVX2 was better as it has 256 bit
data move while AMD prior to Zen2 has 128 bit.


-- 
press any key to continue or any other to quit...
U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec
Svi smo svedoci - oko 3 godine intenzivne propagande je dovoljno da jedan narod poludi --  Zli Zec
Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi 
bili naoruzani. -- Mladen Gogala

[toc] | [prev] | [next] | [standalone]

#71105

From	Bonita Montero <Bonita.Montero@gmail.com>
Date	2020-01-04 13:03 +0100
Message-ID	<qupuun$ij1$1@news.albasani.net>
In reply to	#71104

> simply put for large blocks SSE2/AVX2 is better for
> small movs on both Intel and AMD.

No, movsd/q is always inferiror.

[toc] | [prev] | [next] | [standalone]

#71109

From	Bonita Montero <Bonita.Montero@gmail.com>
Date	2020-01-04 14:22 +0100
Message-ID	<quq3i8$7c3$1@news.albasani.net>
In reply to	#71103

 > I suspect the results will be highly dependent on details, like the
 > exact chip you are using, and where you draw the line between "small
 > blocks" and "big blocks".
Here's a little benchmark that compares rep movsq with avx-copying
(without loop-unrolling!):

C++-Code:

#include <Windows.h>
#include <iostream>
#include <cstring>
#include <cstdint>
#include <chrono>
#include <intrin.h>

using namespace std;
using namespace chrono;

extern "C" void fAvx(   __m256 *src, __m256 *dst, size_t size, size_t 
repts );
extern "C" void fMovs(  __m256 *src, __m256 *dst, size_t size, size_t 
repts );

int main()
{
     size_t const  PAGE       = 4096,
                   ROUNDS     = 100'000;
     char         *pPage      = (char *)VirtualAlloc( nullptr, 2 * PAGE, 
MEM_RESERVE | MEM_COMMIT, PAGE_READWRITE );
     __m256       *src        = (__m256 *)pPage,
                  *dst        = (__m256 *)(pPage + PAGE);
     memset( pPage, 0, 2 * PAGE );
     using timestamp = time_point<high_resolution_clock>;
     for( size_t size = 1; size <= (PAGE / 32); ++size )
     {
         timestamp start = high_resolution_clock::now();
         fAvx( src, dst, size, ROUNDS );
         uint64_t avxNs = (uint64_t)duration_cast<nanoseconds>( 
high_resolution_clock::now() - start ).count();;
         start = high_resolution_clock::now();
         fMovs( src, dst, size, ROUNDS );
         uint64_t movsNs = (uint64_t)duration_cast<nanoseconds>( 
high_resolution_clock::now() - start ).count();;
         cout << "size: " << size << "\tavx:\t" << avxNs / 1.0E6 << 
"\tmovs\t" << movsNs / 1.0E6 << endl;
     }
}

Asm-Code:

_TEXT SEGMENT

; void fAvx( __m256 *src, __m256 *dst, size_t count, size_t repts );
; rcx: src
; rdx: dst
; r8:  count
; r9:  repts
fAvx PROC
     test    r9, r9
     jz      zero
     test    r8, r8
     jz      zero
     mov     rax, r8
     shl     rax, 5
     add     rax, rcx
     sub     rdx, rcx
     mov     r10, rcx
     mov     r11, rdx
     jmp     avxLoop
reptLoop:
     mov     rcx, r10
     mov     rdx, r11
avxLoop:
     vmovups ymm0, [rcx]
     vmovups [rcx+rdx], ymm0
     add     rcx, 32
     cmp     rcx, rax
     jne     avxLoop
     dec     r9
     jnz     reptLoop
zero:
     ret
fAvx ENDP

; void fMovs( __m256 *src, __m256 *dst, size_t count, size_t repts );
; rcx: src
; rdx: dst
; r8:  count
; r9:  repts
fMovs PROC
     test    r9, r9
     jz      zero
     push    rsi
     push    rdi
     mov     r10, rcx
     mov     r11, rdx
     lea     rdx, [r8 * 4]
reptLoop:
     mov     rsi, r10
     mov     rdi, r11
     mov     rcx, rdx
     rep movsq
     dec     r9
     jnz     reptLoop
     pop     rdi
     pop     rsi
zero:
     ret
fMovs ENDP

_TEXT ENDS
END

That's the relative speedup of AVX over rep movsq:

size: 1     1383,79%
size: 2     737,12%
size: 3     433,35%
size: 4     342,41%
size: 5     283,20%
size: 6     431,57%
size: 7     351,47%
size: 8     340,53%
size: 9     314,24%
size: 10    325,57%
size: 11    270,96%
size: 12    327,83%
size: 13    296,13%
size: 14    275,73%
size: 15    284,19%
size: 16    317,27%
size: 17    331,54%
size: 18    266,05%
size: 19    287,00%
size: 20    281,83%
size: 21    276,17%
size: 22    261,85%
size: 23    263,01%
size: 24    251,48%
size: 25    247,98%
size: 26    237,64%
size: 27    239,66%
size: 28    187,04%
size: 29    185,92%
size: 30    189,09%
size: 31    168,90%
size: 32    179,31%
size: 33    220,31%
size: 34    192,71%
size: 35    207,33%
size: 36    214,69%
size: 37    156,90%
size: 38    169,47%
size: 39    184,87%
size: 40    159,98%
size: 41    175,79%
size: 42    156,60%
size: 43    162,29%
size: 44    155,36%
size: 45    158,09%
size: 46    164,42%
size: 47    154,88%
size: 48    164,17%
size: 49    155,84%
size: 50    157,59%
size: 51    148,29%
size: 52    152,67%
size: 53    139,59%
size: 54    149,78%
size: 55    140,99%
size: 56    146,94%
size: 57    142,01%
size: 58    148,15%
size: 59    141,62%
size: 60    152,89%
size: 61    152,00%
size: 62    149,20%
size: 63    150,13%
size: 64    150,45%
size: 65    140,96%
size: 66    132,11%
size: 67    142,80%
size: 68    135,96%
size: 69    146,18%
size: 70    140,17%
size: 71    139,63%
size: 72    139,22%
size: 73    131,02%
size: 74    145,43%
size: 75    138,23%
size: 76    132,02%
size: 77    142,05%
size: 78    135,97%
size: 79    136,52%
size: 80    138,93%
size: 81    136,06%
size: 82    138,59%
size: 83    139,08%
size: 84    134,50%
size: 85    136,64%
size: 86    134,28%
size: 87    133,35%
size: 88    129,82%
size: 89    138,07%
size: 90    132,57%
size: 91    125,16%
size: 92    138,73%
size: 93    135,70%
size: 94    131,55%
size: 95    126,62%
size: 96    134,87%
size: 97    130,83%
size: 98    129,21%
size: 99    126,70%
size: 100    133,07%
size: 101    129,39%
size: 102    129,12%
size: 103    125,27%
size: 104    124,14%
size: 105    131,78%
size: 106    132,87%
size: 107    131,40%
size: 108    128,29%
size: 109    122,95%
size: 110    121,13%
size: 111    121,73%
size: 112    126,26%
size: 113    130,87%
size: 114    131,31%
size: 115    124,70%
size: 116    119,53%
size: 117    121,42%
size: 118    120,34%
size: 119    125,65%
size: 120    124,95%
size: 121    130,36%
size: 122    128,35%
size: 123    128,25%
size: 124    127,47%
size: 125    124,28%
size: 126    124,14%
size: 127    122,69%
size: 128    122,76%

So movsq is never faster.
Here's the result graphically: https://app.unsee.cc/#45f34f42
So its also exact the opposite as Melzzz said: movsq becomes
more competitive as the block-size raises.

[toc] | [prev] | [next] | [standalone]

#71055

From	"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>
Date	2020-01-03 14:46 -0800
Message-ID	<quog8g$fpn$2@gioia.aioe.org>
In reply to	#71031

On 1/3/2020 8:12 AM, boltar@nowhere.org wrote:
> On Fri, 3 Jan 2020 07:34:50 -0800 (PST)
> =?UTF-8?B?w5bDtiBUaWli?= <ootiib@hot.ee> wrote:
>> On Friday, 3 January 2020 16:55:21 UTC+2, bol...@nowhere.org  wrote:
>>> You made the claim so either back it up or fuck off back under your bridge.
>>
>> Being vulgar makes you to look only more pathetic. You started by
> 
> Ooh get you!
> 
>> demonstrating lack of knowledge with the "overhead of a
>> function call + loop" first. So now please have balls to stand behind
>> your words of nonsense or to admit your miserable ignorance and
>> obtain that clue bat Mr Flibble keeps suggesting. Sad obscenities do
>> not help you. :D
> 
> So you're saying using memcpy() never creates a function call or loop
> because its built in?[...]

Did he say that? Where?

[toc] | [prev] | [next] | [standalone]

#71041

From	Keith Thompson <Keith.S.Thompson+u@gmail.com>
Date	2020-01-03 10:32 -0800
Message-ID	<87o8vko0fq.fsf@nosuchdomain.example.com>
In reply to	#71025

Öö Tiib <ootiib@hot.ee> writes:
> On Friday, 3 January 2020 16:55:21 UTC+2, bol...@nowhere.org  wrote:
[...]
>> You made the claim so either back it up or fuck off back under your bridge.
>
> Being vulgar makes you to look only more pathetic.

And, frankly, responding doesn't make you look good.  As long as you
keep engaging with trolls, they have no incentive to stop trolling.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
    [Note updated email address]
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#71042

From	Öö Tiib <ootiib@hot.ee>
Date	2020-01-03 10:43 -0800
Message-ID	<38397819-d1fc-4669-938c-e64e10553503@googlegroups.com>
In reply to	#71041

On Friday, 3 January 2020 20:32:49 UTC+2, Keith Thompson  wrote:
> Öö Tiib <ootiib@hot.ee> writes:
> > On Friday, 3 January 2020 16:55:21 UTC+2, bol...@nowhere.org  wrote:
> [...]
> >> You made the claim so either back it up or fuck off back under your bridge.
> >
> > Being vulgar makes you to look only more pathetic.
> 
> And, frankly, responding doesn't make you look good.  As long as you
> keep engaging with trolls, they have no incentive to stop trolling.

Yeah, seems that I waste my own (and possibly other people's) time 
since boltrol can not reason coherently.

[toc] | [prev] | [next] | [standalone]

#71044

From	Melzzzzz <Melzzzzz@zzzzz.com>
Date	2020-01-03 18:55 +0000
Message-ID	<A6MPF.212907$NM1.25532@fx38.am4>
In reply to	#71042

On 2020-01-03, Öö Tiib <ootiib@hot.ee> wrote:
> On Friday, 3 January 2020 20:32:49 UTC+2, Keith Thompson  wrote:
>> Öö Tiib <ootiib@hot.ee> writes:
>> > On Friday, 3 January 2020 16:55:21 UTC+2, bol...@nowhere.org  wrote:
>> [...]
>> >> You made the claim so either back it up or fuck off back under your bridge.
>> >
>> > Being vulgar makes you to look only more pathetic.
>> 
>> And, frankly, responding doesn't make you look good.  As long as you
>> keep engaging with trolls, they have no incentive to stop trolling.
>
> Yeah, seems that I waste my own (and possibly other people's) time 
> since boltrol can not reason coherently.
>

Perhaps he is just dumb?


-- 
press any key to continue or any other to quit...
U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec
Svi smo svedoci - oko 3 godine intenzivne propagande je dovoljno da jedan narod poludi --  Zli Zec
Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi 
bili naoruzani. -- Mladen Gogala

[toc] | [prev] | [next] | [standalone]

#71227

From	Daniel <danielaparker@gmail.com>
Date	2020-01-08 09:40 -0800
Message-ID	<e702d21c-64d8-4f61-a7d7-2c0155bdcb31@googlegroups.com>
In reply to	#70977

On Thursday, January 2, 2020 at 1:26:46 PM UTC-5, Öö Tiib wrote:

> Experiments of mine and others have shown that usage of memcpy
> instead of other ways of type punning tends to generate better or
> same codes. It is hard to find examples where other methods are
> really beneficial. 

Does that observation apply to, eg. bit casting 

uint8_t v[8000000] to float[1000000]

(which is a typical case in deserialization of typed arrays when endiness lines up.)

Thanks,
Daniel

[toc] | [prev] | [next] | [standalone]

#71229

From	Öö Tiib <ootiib@hot.ee>
Date	2020-01-08 13:23 -0800
Message-ID	<7d328228-e31b-40af-8b8d-c279953a3760@googlegroups.com>
In reply to	#71227

On Wednesday, 8 January 2020 19:41:11 UTC+2, Daniel  wrote:
> On Thursday, January 2, 2020 at 1:26:46 PM UTC-5, Öö Tiib wrote:
> 
> > Experiments of mine and others have shown that usage of memcpy
> > instead of other ways of type punning tends to generate better or
> > same codes. It is hard to find examples where other methods are
> > really beneficial. 
> 
> Does that observation apply to, eg. bit casting 
> 
> uint8_t v[8000000] to float[1000000]
> 
> (which is a typical case in deserialization of typed arrays when endiness lines up.)

Note that bytes are special since memory consists of those. It is
not type punning to convert between POD object and its bytes. 
Otherwise memcpy itself would be wrong. With "type punning" things
like converting between IEEE double and uint64_t are usually meant.

However when we deserialize then we typically get those bytes from
somewhere as smaller packets. For example Ethernet packet is
1500 bytes + 26 bytes of header and there are usually other
garbage by protocol so for floats there is less than 1500 bytes.
Then we memcpy from there into our floats. I can't
even imagine how you suggest to use union there instead. Can you?

[toc] | [prev] | [next] | [standalone]

#71234

From	Daniel <danielaparker@gmail.com>
Date	2020-01-08 22:41 -0800
Message-ID	<c2484625-0567-43cd-8b94-cb1922a91c94@googlegroups.com>
In reply to	#71229

On Wednesday, January 8, 2020 at 4:24:03 PM UTC-5, Öö Tiib wrote:
> 
> However when we deserialize then we typically get those bytes from
> somewhere as smaller packets. For example Ethernet packet is
> 1500 bytes + 26 bytes of header and there are usually other
> garbage by protocol so for floats there is less than 1500 bytes.
> Then we memcpy from there into our floats. I can't
> even imagine how you suggest to use union there instead. Can you?

No :-)

Daniel

[toc] | [prev] | [next] | [standalone]

#71235

From	Daniel <danielaparker@gmail.com>
Date	2020-01-08 22:52 -0800
Message-ID	<606e7225-a464-49d9-b2d1-2ccefcb1056a@googlegroups.com>
In reply to	#71229

On Wednesday, January 8, 2020 at 4:24:03 PM UTC-5, Öö Tiib wrote:
> 
> However when we deserialize then we typically get those bytes from
> somewhere as smaller packets. For example Ethernet packet is
> 1500 bytes + 26 bytes of header and there are usually other
> garbage by protocol so for floats there is less than 1500 bytes.
> Then we memcpy from there into our floats. 

But if the last item in the packet is half a float, do you still memcpy
directly into floats? 

Daniel

[toc] | [prev] | [next] | [standalone]

#71250

From	Öö Tiib <ootiib@hot.ee>
Date	2020-01-09 12:59 -0800
Message-ID	<4ea8ace4-2582-4d80-9ba7-990fc289c256@googlegroups.com>
In reply to	#71235

On Thursday, 9 January 2020 08:52:31 UTC+2, Daniel  wrote:
> On Wednesday, January 8, 2020 at 4:24:03 PM UTC-5, Öö Tiib wrote:
> > 
> > However when we deserialize then we typically get those bytes from
> > somewhere as smaller packets. For example Ethernet packet is
> > 1500 bytes + 26 bytes of header and there are usually other
> > garbage by protocol so for floats there is less than 1500 bytes.
> > Then we memcpy from there into our floats. 
> 
> But if the last item in the packet is half a float, do you still memcpy
> directly into floats? 

What you mean by "half a float"? Half-received? 
If half-received then may be yes, may be no. Hard to
tell without context.

For example if program needs to process received floats even
without all received then I probably would not copy half-floats.
But if it may refuse to work until all floats are received then
I probably would copy half but would throw after timeout
destroying all the received floats and not processing anyway.

[toc] | [prev] | [next] | [standalone]

#71252

From	Daniel <danielaparker@gmail.com>
Date	2020-01-09 13:32 -0800
Message-ID	<44db5d0b-7fa4-4be9-b332-f6877f51495b@googlegroups.com>
In reply to	#71250

On Thursday, January 9, 2020 at 3:59:40 PM UTC-5, Öö Tiib wrote:
> 
> What you mean by "half a float"? Half-received?

Half-received
 
> If half-received then may be yes, may be no. Hard to
> tell without context.
> 
> For example if program needs to process received floats even
> without all received then I probably would not copy half-floats.
> But if it may refuse to work until all floats are received then
> I probably would copy half but would throw after timeout
> destroying all the received floats and not processing anyway.

Fair enough.

Daniel

[toc] | [prev] | [next] | [standalone]

#71254

From	Mister2U@honorific.org
Date	2020-01-10 12:28 +0000
Message-ID	<qv9qli$osu$1@gioia.aioe.org>
In reply to	#71250

On Thu, 9 Jan 2020 12:59:29 -0800 (PST)
=?UTF-8?B?w5bDtiBUaWli?= <ootiib@hot.ee> wrote:
>On Thursday, 9 January 2020 08:52:31 UTC+2, Daniel  wrote:
>> On Wednesday, January 8, 2020 at 4:24:03 PM UTC-5, =C3=96=C3=B6 Tiib wrot=
>e:
>> >=20
>> > However when we deserialize then we typically get those bytes from
>> > somewhere as smaller packets. For example Ethernet packet is
>> > 1500 bytes + 26 bytes of header and there are usually other
>> > garbage by protocol so for floats there is less than 1500 bytes.
>> > Then we memcpy from there into our floats.=20
>>=20
>> But if the last item in the packet is half a float, do you still memcpy
>> directly into floats?=20
>
>What you mean by "half a float"? Half-received?=20
>If half-received then may be yes, may be no. Hard to
>tell without context.
>
>For example if program needs to process received floats even
>without all received then I probably would not copy half-floats.
>But if it may refuse to work until all floats are received then
>I probably would copy half but would throw after timeout
>destroying all the received floats and not processing anyway.

These sort of problems are why any genuine network programmer always includes
the expected packet size in a stream packet (usually at the beginning) instead 
of doing something stupid like sending raw XML or json on its own where 
constant parsing is required to see if the end of the data has been reached yet
and may get it wrong if the formatting is bad and continue waiting for data 
beyond the end. For UDP where data send in a single write is returned in a 
single read that approach is fine, not so for TCP. Sadly a new generation of 
programmers has yet to figure this out.

[toc] | [prev] | [next] | [standalone]

Page 3 of 7 — ← Prev page 1 2 [3] 4 5 6 7 Next page →

csiph-web

Union type punning in C++

Contents

#71096

#71097

#71098

#71099

#71100

#71103

#71104

#71105

#71109

#71055

#71041

#71042

#71044

#71227

#71229

#71234

#71235

#71250

#71252

#71254