Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

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

Union type punning in C++

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

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

Contents

  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 2 of 7 — ← Prev page 1 [2] 3 4 5 6 7  Next page →

#71073

From"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>
Date2020-01-03 17:06 -0800
Message-ID<quooep$1j85$1@gioia.aioe.org>
In reply to#71072
On 1/3/2020 5:02 PM, Melzzzzz wrote:
> On 2020-01-04, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
>> On 1/3/2020 4:26 PM, Bonita Montero wrote:
>>>>>> You made the claim so either back it up or fuck off back under your
>>>>>> bridge.
>>>>>
>>>>> I just did
>>>>>
>>>>> #include <cstring>
>>>>> #include <cstdint>
>>>>>
>>>>> uint64_t native( double d )
>>>>> {
>>>>> #if defined(UNION)
>>>>>       union
>>>>>       {
>>>>>           double   du;
>>>>>           uint64_t dx;
>>>>>       };
>>>>>       du = d;
>>>>>       return dx;
>>>> [...]
>>>
>>>> It seems like a static_assert to ensure that a double is the same size
>>>> as a unit64_t is in order? ...
>>>
>>> LOL, in that _experimental_code_ just to prove
>>> that memcpy() is translated into efficient moves?
>>
>> Color me pendant... ;^)
> Not once I saw examples when compiler (gcc) returned garbage
> in different scenarios. That code screams 'volatile' ;)
> 

Actually, portability be damned, I used 64 bit atomics to work with 
doubles that happened to be of the same size. It was a fast and dirty 
way to work on doubles atomically. Well, I only used it for atomic swap, 
compare-exchange, load and store. NO fetch-and-add. It would destroy things.

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

#71025

FromÖö Tiib <ootiib@hot.ee>
Date2020-01-03 07:34 -0800
Message-ID<25969687-6510-4000-a4e4-e9722a9c6089@googlegroups.com>
In reply to#71019
On Friday, 3 January 2020 16:55:21 UTC+2, bol...@nowhere.org  wrote:
> On Fri, 3 Jan 2020 02:21:28 -0800 (PST)
> =?UTF-8?B?w5bDtiBUaWli?= <ootiib@hot.ee> wrote:
> >On Friday, 3 January 2020 11:55:29 UTC+2, bol...@nowhere.org  wrote:
> >> On Thu, 2 Jan 2020 10:26:35 -0800 (PST)
> >> =?UTF-8?B?w5bDtiBUaWli?= <ootiib@hot.ee> wrote:
> >> >On Thursday, 2 January 2020 19:22:52 UTC+2, bol...@nowhere.org  wrote:
> >> >> On Thu, 2 Jan 2020 04:52:42 -0800 (PST)
> >> >> =?UTF-8?B?w5bDtiBUaWli?= <ootiib@hot.ee> wrote:
> >> >> >On Thursday, 2 January 2020 13:49:39 UTC+2, Bo Persson  wrote:
> >> >> >> 
> >> >> >> The C++ committee seems unwilling to change the union rules and so 
> >> >> >> instead adds a bit_cast function to package the memcpy usage with a 
> >> >> >> slightly better name:
> >> >> >> 
> >> >> >> template< class To, class From >
> >> >> >> constexpr To bit_cast(const From& from) noexcept;
> >> >> >> 
> >> >> >> https://en.cppreference.com/w/cpp/numeric/bit_cast
> >> >> >
> >> >> >Thanks, I didn't somehow even notice that. So we can throw away
> >> >> >our own type punning wrappers around memcpy in C++20.
> >> >> 
> >> >> You realise using a union (or a cast) in theory uses very few CPU cycles
> >to
> >> >do 
> >> >> type punning, whereas memcpy has the overhead of a function call + loop.
> >Its
> >> >> an extremely inefficient way to do it if you don't need the new type to
> >be in
> >> >
> >> >> a seperate variable.
> >> >
> >> >That is the typical behavior of gibberish team. In one post it is
> >> >"de facto" in other "in theory". I wrote:
> >> >
> >> >Experiments of mine and others have shown that usage of memcpy
> >> 
> >> Lets see your test code then.
> >
> >You first. You demonstrated lack of knowledge with the "overhead of a
> 
> 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 
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

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

#71031

Fromboltar@nowhere.org
Date2020-01-03 16:12 +0000
Message-ID<qunp5o$17ci$1@gioia.aioe.org>
In reply to#71025
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? Ok, here's what Clang has to say about it:

void func()
{
        char s[100];
        char d[100];
        memcpy( &d, &s,100);
}

_func:                                  ## @func
	.cfi_startproc
## %bb.0:
	pushq	%rbp
	.cfi_def_cfa_offset 16
	.cfi_offset %rbp, -16
	movq	%rsp, %rbp
	.cfi_def_cfa_register %rbp
	subq	$224, %rsp
	movl	$100, %eax
	movl	%eax, %edx
	movq	___stack_chk_guard@GOTPCREL(%rip), %rcx
	movq	(%rcx), %rcx
	movq	%rcx, -8(%rbp)
	leaq	-224(%rbp), %rcx
	leaq	-112(%rbp), %rsi
	movq	%rcx, %rdi
	callq	_memcpy
	movq	___stack_chk_guard@GOTPCREL(%rip), %rcx
	movq	(%rcx), %rcx
	movq	-8(%rbp), %rdx
	cmpq	%rdx, %rcx
	jne	LBB0_2


callq memcpy? Ooops, that looks like a call to me. Sure, if the length is
short it will optimise it out to just movs , but that criteria wasn't
mentioned.

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

#71033

FromÖö Tiib <ootiib@hot.ee>
Date2020-01-03 08:49 -0800
Message-ID<d0670c6e-f127-4cba-a650-83e82f9ba936@googlegroups.com>
In reply to#71031
On Friday, 3 January 2020 18:12:48 UTC+2, bol...@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?

No, I did not say that. Are you straw-manning out of habit or did being pathetically profane affect your capability to read? I said that type
punning using memcpy does generate more correct code that is as efficient
or more efficient than other methods with modern (less than 15 years old)
C++ compilers when compiled with optimizations enabled.

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

#71039

FromBonita Montero <Bonita.Montero@gmail.com>
Date2020-01-03 19:28 +0100
Message-ID<quo15b$qp7$1@news.albasani.net>
In reply to#71031
> void func()
> {
>          char s[100];
>          char d[100];
>          memcpy( &d, &s,100);
> }

> _func:                                  ## @func
> 	.cfi_startproc
> ## %bb.0:
> 	pushq	%rbp
> 	.cfi_def_cfa_offset 16
> 	.cfi_offset %rbp, -16
> 	movq	%rsp, %rbp
> 	.cfi_def_cfa_register %rbp
> 	subq	$224, %rsp
> 	movl	$100, %eax
> 	movl	%eax, %edx
> 	movq	___stack_chk_guard@GOTPCREL(%rip), %rcx
> 	movq	(%rcx), %rcx
> 	movq	%rcx, -8(%rbp)
> 	leaq	-224(%rbp), %rcx
> 	leaq	-112(%rbp), %rsi
> 	movq	%rcx, %rdi
> 	callq	_memcpy
> 	movq	___stack_chk_guard@GOTPCREL(%rip), %rcx
> 	movq	(%rcx), %rcx
> 	movq	-8(%rbp), %rdx
> 	cmpq	%rdx, %rcx
> 	jne	LBB0_2

Didn't you use optimizations?

Look at this code:

size_t const N = 200;

struct S
{
	char c[200];
};


void f( S *a, S *b )
{
	memcpy( a->c, b->c, N );
}

This is the MSVC-code:

	movups	xmm0, XMMWORD PTR [rdx]
	movups	XMMWORD PTR [rcx], xmm0
	movups	xmm1, XMMWORD PTR [rdx+16]
	movups	XMMWORD PTR [rcx+16], xmm1
	movups	xmm0, XMMWORD PTR [rdx+32]
	movups	XMMWORD PTR [rcx+32], xmm0
	movups	xmm1, XMMWORD PTR [rdx+48]
	movups	XMMWORD PTR [rcx+48], xmm1
	movups	xmm0, XMMWORD PTR [rdx+64]
	movups	XMMWORD PTR [rcx+64], xmm0
	movups	xmm1, XMMWORD PTR [rdx+80]
	movups	XMMWORD PTR [rcx+80], xmm1
	movups	xmm0, XMMWORD PTR [rdx+96]
	movups	XMMWORD PTR [rcx+96], xmm0
	sub	rcx, -128
	movups	xmm0, XMMWORD PTR [rdx+112]
	movups	XMMWORD PTR [rcx-16], xmm0
	movups	xmm1, XMMWORD PTR [rdx+128]
	movups	XMMWORD PTR [rcx], xmm1
	movups	xmm0, XMMWORD PTR [rdx+144]
	movups	XMMWORD PTR [rcx+16], xmm0
	movups	xmm1, XMMWORD PTR [rdx+160]
	movups	XMMWORD PTR [rcx+32], xmm1
	movups	xmm0, XMMWORD PTR [rdx+176]
	movups	XMMWORD PTR [rcx+48], xmm0
	mov	rax, QWORD PTR [rdx+192]
	mov	QWORD PTR [rcx+64], rax
	ret	0

This is the gcc-code:

	movq	(%rsi), %rax
	movq	%rdi, %rcx
	leaq	8(%rdi), %rdi
	movq	%rax, -8(%rdi)
	movq	192(%rsi), %rax
	movq	%rax, 184(%rdi)
	andq	$-8, %rdi
	subq	%rdi, %rcx
	subq	%rcx, %rsi
	addl	$200, %ecx
	shrl	$3, %ecx
	rep movsq
	ret

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

#71043

FromMelzzzzz <Melzzzzz@zzzzz.com>
Date2020-01-03 18:54 +0000
Message-ID<G5MPF.212906$NM1.105724@fx38.am4>
In reply to#71039
On 2020-01-03, Bonita Montero <Bonita.Montero@gmail.com> wrote:
>
>> void func()
>> {
>>          char s[100];
>>          char d[100];
>>          memcpy( &d, &s,100);
>> }
>
>> _func:                                  ## @func
>> 	.cfi_startproc
>> ## %bb.0:
>> 	pushq	%rbp
>> 	.cfi_def_cfa_offset 16
>> 	.cfi_offset %rbp, -16
>> 	movq	%rsp, %rbp
>> 	.cfi_def_cfa_register %rbp
>> 	subq	$224, %rsp
>> 	movl	$100, %eax
>> 	movl	%eax, %edx
>> 	movq	___stack_chk_guard@GOTPCREL(%rip), %rcx
>> 	movq	(%rcx), %rcx
>> 	movq	%rcx, -8(%rbp)
>> 	leaq	-224(%rbp), %rcx
>> 	leaq	-112(%rbp), %rsi
>> 	movq	%rcx, %rdi
>> 	callq	_memcpy
>> 	movq	___stack_chk_guard@GOTPCREL(%rip), %rcx
>> 	movq	(%rcx), %rcx
>> 	movq	-8(%rbp), %rdx
>> 	cmpq	%rdx, %rcx
>> 	jne	LBB0_2
>
> Didn't you use optimizations?
>
> Look at this code:
>
> size_t const N = 200;
>
> struct S
> {
> 	char c[200];
> };
>
>
> void f( S *a, S *b )
> {
> 	memcpy( a->c, b->c, N );
> }
>
> This is the MSVC-code:
>
> 	movups	xmm0, XMMWORD PTR [rdx]
> 	movups	XMMWORD PTR [rcx], xmm0
> 	movups	xmm1, XMMWORD PTR [rdx+16]
> 	movups	XMMWORD PTR [rcx+16], xmm1
> 	movups	xmm0, XMMWORD PTR [rdx+32]
> 	movups	XMMWORD PTR [rcx+32], xmm0
> 	movups	xmm1, XMMWORD PTR [rdx+48]
> 	movups	XMMWORD PTR [rcx+48], xmm1
> 	movups	xmm0, XMMWORD PTR [rdx+64]
> 	movups	XMMWORD PTR [rcx+64], xmm0
> 	movups	xmm1, XMMWORD PTR [rdx+80]
> 	movups	XMMWORD PTR [rcx+80], xmm1
> 	movups	xmm0, XMMWORD PTR [rdx+96]
> 	movups	XMMWORD PTR [rcx+96], xmm0
> 	sub	rcx, -128
> 	movups	xmm0, XMMWORD PTR [rdx+112]
> 	movups	XMMWORD PTR [rcx-16], xmm0
> 	movups	xmm1, XMMWORD PTR [rdx+128]
> 	movups	XMMWORD PTR [rcx], xmm1
> 	movups	xmm0, XMMWORD PTR [rdx+144]
> 	movups	XMMWORD PTR [rcx+16], xmm0
> 	movups	xmm1, XMMWORD PTR [rdx+160]
> 	movups	XMMWORD PTR [rcx+32], xmm1
> 	movups	xmm0, XMMWORD PTR [rdx+176]
> 	movups	XMMWORD PTR [rcx+48], xmm0
> 	mov	rax, QWORD PTR [rdx+192]
> 	mov	QWORD PTR [rcx+64], rax
> 	ret	0
>
> This is the gcc-code:
>
> 	movq	(%rsi), %rax
> 	movq	%rdi, %rcx
> 	leaq	8(%rdi), %rdi
> 	movq	%rax, -8(%rdi)
> 	movq	192(%rsi), %rax
> 	movq	%rax, 184(%rdi)
> 	andq	$-8, %rdi
> 	subq	%rdi, %rcx
> 	subq	%rcx, %rsi
> 	addl	$200, %ecx
> 	shrl	$3, %ecx
> 	rep movsq
> 	ret

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


-- 
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]

#71062

FromBonita Montero <Bonita.Montero@gmail.com>
Date2020-01-04 01:25 +0100
Message-ID<quom1j$70t$1@news.albasani.net>
In reply to#71043
> For small blocks movs instructions are better.
> For big ones opposite.

The compiler knows better than stupid Melzzz.

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

#71067

FromMelzzzzz <Melzzzzz@zzzzz.com>
Date2020-01-04 00:28 +0000
Message-ID<m_QPF.776117$kBJ1.341593@fx12.am4>
In reply to#71062
On 2020-01-04, Bonita Montero <Bonita.Montero@gmail.com> wrote:
>> For small blocks movs instructions are better.
>> For big ones opposite.
>
> The compiler knows better than stupid Melzzz.

Nope. These two don's agree but:
~/examples/assembler >>> ./rdtscp 200                                                                                                                                                                                      [32]
200 128 byte blocks, loops:20000
rep movsb                       0.00000054797211
rep movsq                       0.00000054844105
movntdq                         0.00000065490963
movntdq prefetch                0.00000063764716
movntdq prefetch ymm            0.00000063049784
~/examples/assembler >>> ./rdtscp 4                                                                                                                                                                                        [32]
4 128 byte blocks, loops:1000000
rep movsb                       0.00000004582558
rep movsq                       0.00000002845861
movntdq                         0.00000008605540
movntdq prefetch                0.00000008531304
movntdq prefetch ymm            0.00000008636872

see, it's all empyrical...
>


-- 
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]

#71069

FromBonita Montero <Bonita.Montero@gmail.com>
Date2020-01-04 01:41 +0100
Message-ID<quon0m$3m1$1@news.albasani.net>
In reply to#71067
>>> For small blocks movs instructions are better.
>>> For big ones opposite.

>> The compiler knows better than stupid Melzzz.

> Nope. These two don's agree but:
> ~/examples/assembler >>> ./rdtscp 200                                                                                                                                                                                      [32]
> 200 128 byte blocks, loops:20000
> rep movsb                       0.00000054797211
> rep movsq                       0.00000054844105
> movntdq                         0.00000065490963
> movntdq prefetch                0.00000063764716
> movntdq prefetch ymm            0.00000063049784
> ~/examples/assembler >>> ./rdtscp 4                                                                                                                                                                                        [32]
> 4 128 byte blocks, loops:1000000
> rep movsb                       0.00000004582558
> rep movsq                       0.00000002845861
> movntdq                         0.00000008605540
> movntdq prefetch                0.00000008531304
> movntdq prefetch ymm            0.00000008636872
> see, it's all empyrical...

That's not as easy to test as you might think.

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

#71070

FromMelzzzzz <Melzzzzz@zzzzz.com>
Date2020-01-04 00:52 +0000
Message-ID<1lRPF.419944$ob4.134250@fx16.am4>
In reply to#71069
On 2020-01-04, Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>>> For small blocks movs instructions are better.
>>>> For big ones opposite.
>
>>> The compiler knows better than stupid Melzzz.
>
>> Nope. These two don's agree but:
>> ~/examples/assembler >>> ./rdtscp 200                                                                                                                                                                                      [32]
>> 200 128 byte blocks, loops:20000
>> rep movsb                       0.00000054797211
>> rep movsq                       0.00000054844105
>> movntdq                         0.00000065490963
>> movntdq prefetch                0.00000063764716
>> movntdq prefetch ymm            0.00000063049784
>> ~/examples/assembler >>> ./rdtscp 4                                                                                                                                                                                        [32]
>> 4 128 byte blocks, loops:1000000
>> rep movsb                       0.00000004582558
>> rep movsq                       0.00000002845861
>> movntdq                         0.00000008605540
>> movntdq prefetch                0.00000008531304
>> movntdq prefetch ymm            0.00000008636872
>> see, it's all empyrical...
>
> That's not as easy to test as you might think.

It is not easy, that is why I wrote tests...

>


-- 
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]

#71083

FromBonita Montero <Bonita.Montero@gmail.com>
Date2020-01-04 08:08 +0100
Message-ID<qupdkh$v1j$1@news.albasani.net>
In reply to#71070
>> That's not as easy to test as you might think.

> It is not easy, that is why I wrote tests...

You didn't test what I disassembled.

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

#71084

FromBonita Montero <Bonita.Montero@gmail.com>
Date2020-01-04 08:34 +0100
Message-ID<qupf5k$ppq$1@news.albasani.net>
In reply to#71083
>> It is not easy, that is why I wrote tests...

> You didn't test what I disassembled.

Here's a little test:

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

using namespace std;
using namespace chrono;

size_t const SIZE = 200;

struct S
{
     char c[200];
};

void fCopy( S *a, S *b )
{
     memcpy( a->c, b->c, SIZE );
}

int main()
{
     void (*volatile pfCopy)( S *, S * ) = fCopy;
     S               a, b;
     time_point<high_resolution_clock> start = high_resolution_clock::now();
     for( size_t n = 1'000'000; n; --n )
         pfCopy( &a, &b );
     uint64_t ns = (uint64_t)duration_cast<nanoseconds>( 
high_resolution_clock::now() - start ).count();;
     cout << (double)ns / 1.0E6 << "ms" << endl;
}

Under Windows the execution-time of the loop is 3.96ms.
Under Linux the execution time is 12.96ms.
SSE simply rules here.

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

#71085

FromBonita Montero <Bonita.Montero@gmail.com>
Date2020-01-04 08:43 +0100
Message-ID<qupfn9$o90$1@news.albasani.net>
In reply to#71084
> ...
> Under Windows the execution-time of the loop is 3.96ms.
> Under Linux the execution time is 12.96ms.
> SSE simply rules here.

MSVC even uses AVX2 for memcpy when I enable it via compiler-switch.
That's what the fCopy-code looks like then:

	vmovups	xmm0, XMMWORD PTR [rdx]
	vmovups	XMMWORD PTR [rcx], xmm0
	vmovups	xmm1, XMMWORD PTR [rdx+16]
	vmovups	XMMWORD PTR [rcx+16], xmm1
	vmovups	xmm0, XMMWORD PTR [rdx+32]
	vmovups	XMMWORD PTR [rcx+32], xmm0
	vmovups	xmm1, XMMWORD PTR [rdx+48]
	vmovups	XMMWORD PTR [rcx+48], xmm1
	vmovups	xmm0, XMMWORD PTR [rdx+64]
	vmovups	XMMWORD PTR [rcx+64], xmm0
	vmovups	xmm1, XMMWORD PTR [rdx+80]
	vmovups	XMMWORD PTR [rcx+80], xmm1
	vmovups	xmm0, XMMWORD PTR [rdx+96]
	vmovups	XMMWORD PTR [rcx+96], xmm0
	vmovups	xmm0, XMMWORD PTR [rdx+112]
	vmovups	XMMWORD PTR [rcx+112], xmm0
	vmovups	xmm1, XMMWORD PTR [rdx+128]
	sub	rcx, -128
	vmovups	XMMWORD PTR [rcx], xmm1
	vmovups	xmm0, XMMWORD PTR [rdx+144]
	vmovups	XMMWORD PTR [rcx+16], xmm0
	vmovups	xmm1, XMMWORD PTR [rdx+160]
	vmovups	XMMWORD PTR [rcx+32], xmm1
	vmovups	xmm0, XMMWORD PTR [rdx+176]
	vmovups	XMMWORD PTR [rcx+48], xmm0
	mov	rax, QWORD PTR [rdx+192]
	mov	QWORD PTR [rcx+64], rax
	ret	0

But the performance is only slightly better with AVX2 over SSE
(3.68ms).

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

#71087

FromMelzzzzz <Melzzzzz@zzzzz.com>
Date2020-01-04 08:20 +0000
Message-ID<YUXPF.63888$Kj.34060@fx21.am4>
In reply to#71084
On 2020-01-04, Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>> It is not easy, that is why I wrote tests...
>
>> You didn't test what I disassembled.
>
> Here's a little test:
>
> #include <iostream>
> #include <cstring>
> #include <cstdint>
> #include <chrono>
>
> using namespace std;
> using namespace chrono;
>
> size_t const SIZE = 200;
>
> struct S
> {
>      char c[200];
> };
>
> void fCopy( S *a, S *b )
> {
>      memcpy( a->c, b->c, SIZE );
> }
>
> int main()
> {
>      void (*volatile pfCopy)( S *, S * ) = fCopy;
>      S               a, b;
>      time_point<high_resolution_clock> start = high_resolution_clock::now();
>      for( size_t n = 1'000'000; n; --n )
>          pfCopy( &a, &b );
>      uint64_t ns = (uint64_t)duration_cast<nanoseconds>( 
> high_resolution_clock::now() - start ).count();;
>      cout << (double)ns / 1.0E6 << "ms" << endl;
> }
>
> Under Windows the execution-time of the loop is 3.96ms.
> Under Linux the execution time is 12.96ms.
> SSE simply rules here.
That's not a test of that code.

-- 
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]

#71089

FromBonita Montero <Bonita.Montero@gmail.com>
Date2020-01-04 09:25 +0100
Message-ID<qupi5b$in5$1@news.albasani.net>
In reply to#71087
>> #include <iostream>
>> #include <cstring>
>> #include <cstdint>
>> #include <chrono>
>>
>> using namespace std;
>> using namespace chrono;
>>
>> size_t const SIZE = 200;
>>
>> struct S
>> {
>>       char c[200];
>> };
>>
>> void fCopy( S *a, S *b )
>> {
>>       memcpy( a->c, b->c, SIZE );
>> }
>>
>> int main()
>> {
>>       void (*volatile pfCopy)( S *, S * ) = fCopy;
>>       S               a, b;
>>       time_point<high_resolution_clock> start = high_resolution_clock::now();
>>       for( size_t n = 1'000'000; n; --n )
>>           pfCopy( &a, &b );
>>       uint64_t ns = (uint64_t)duration_cast<nanoseconds>(
>> high_resolution_clock::now() - start ).count();;
>>       cout << (double)ns / 1.0E6 << "ms" << endl;
>> }
>> Under Windows the execution-time of the loop is 3.96ms.
>> Under Linux the execution time is 12.96ms.
>> SSE simply rules here.

> That's not a test of that code.

It is.

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

#71088

FromMelzzzzz <Melzzzzz@zzzzz.com>
Date2020-01-04 08:25 +0000
Message-ID<wZXPF.63889$Kj.21624@fx21.am4>
In reply to#71083
On 2020-01-04, Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>> That's not as easy to test as you might think.
>
>> It is not easy, that is why I wrote tests...
>
> You didn't test what I disassembled.
>

It is test of rep movs vs non temporal moves with SSE/AVX2.
non temporal moves with SSE/AVX2 wuold be slower.


-- 
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]

#71090

FromBonita Montero <Bonita.Montero@gmail.com>
Date2020-01-04 09:25 +0100
Message-ID<qupi6a$in5$2@news.albasani.net>
In reply to#71088
>> You didn't test what I disassembled.

> It is test of rep movs vs non temporal moves with SSE/AVX2.
> non temporal moves with SSE/AVX2 wuold be slower.

Then you're wrong in this part of the thread.

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

#71091

FromMelzzzzz <Melzzzzz@zzzzz.com>
Date2020-01-04 08:27 +0000
Message-ID<%%XPF.63890$Kj.11793@fx21.am4>
In reply to#71090
On 2020-01-04, Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>> You didn't test what I disassembled.
>
>> It is test of rep movs vs non temporal moves with SSE/AVX2.
>> non temporal moves with SSE/AVX2 wuold be slower.
>
> Then you're wrong in this part of the thread.
>

No I am not for block of that size gcc code is more efficient...

-- 
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]

#71092

FromBonita Montero <Bonita.Montero@gmail.com>
Date2020-01-04 09:36 +0100
Message-ID<qupiqh$h48$1@news.albasani.net>
In reply to#71091
>>> It is test of rep movs vs non temporal moves with SSE/AVX2.
>>> non temporal moves with SSE/AVX2 wuold be slower.

>> Then you're wrong in this part of the thread.

> No I am not for block of that size gcc code is more efficient...

You're at the wrong place in the subthread. What I said started here:
<qunp5o$17ci$1@gioia.aioe.org> - and everything below that posting
should be related to what I said there. But you're simply a stupid
person which doesn't undestand this.

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

#71094

FromMelzzzzz <Melzzzzz@zzzzz.com>
Date2020-01-04 08:41 +0000
Message-ID<YcYPF.73671$qQ.18234@fx19.am4>
In reply to#71092
On 2020-01-04, Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>>> It is test of rep movs vs non temporal moves with SSE/AVX2.
>>>> non temporal moves with SSE/AVX2 wuold be slower.
>
>>> Then you're wrong in this part of the thread.
>
>> No I am not for block of that size gcc code is more efficient...
>
> You're at the wrong place in the subthread. What I said started here:
><qunp5o$17ci$1@gioia.aioe.org> - and everything below that posting
> should be related to what I said there. But you're simply a stupid
> person which doesn't undestand this.

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


-- 
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]

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

Back to top | Article view | comp.lang.c++

csiph-web