Path: csiph.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: Ian Collins <ian-news@hotmail.com>
Newsgroups: comp.lang.c++
Subject: Re: Examples of current platforms/architectures where sizeof(void*) >
Date: Sun, 12 Sep 2021 12:11:34 +1200
Lines: 117
Message-ID: <iq4utmFh2ruU1@mid.individual.net>
References: <sgglb9$c02$1@dont-email.me> <sh5bum$1s93$1@gioia.aioe.org> <sh7o2u$1f1k$1@gioia.aioe.org> <sh7v70$17kg$1@gioia.aioe.org> <sh85jr$1u8$1@dont-email.me> <sha37n$7s5$1@gioia.aioe.org> <shaaei$4aq$1@dont-email.me> <ipstvqFgmbiU3@mid.individual.net> <shbkec$rr9$1@dont-email.me> <ipt4vcFgmbiU4@mid.individual.net> <shck71$ctj$1@dont-email.me> <ipu5u5FgmbiU6@mid.individual.net> <shcrsh$19n$1@dont-email.me> <ipvdufFgmbiU7@mid.individual.net> <she43m$ssj$1@dont-email.me> <shf3f6$ulu$1@dont-email.me> <shf7db$td7$1@gioia.aioe.org> <shfgke$lvf$1@dont-email.me> <shgq1m$id4$1@dont-email.me> <shio80$rg$1@dont-email.me> <shj1l6$b41$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Trace: individual.net stcI+ZU1YqTLiRndpXqkxA8wrRFMwxfnMzblrGsQl0m9dHEgbH
Cancel-Lock: sha1:49KzpGTQlKGmDjRALi6nNRmrjo8=
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
In-Reply-To: <shj1l6$b41$1@dont-email.me>
Content-Language: en-US
Xref: csiph.com comp.lang.c++:81187

On 12/09/2021 07:56, Bart wrote:
> On 11/09/2021 18:15, David Brown wrote:
>> On 11/09/2021 01:33, Bart wrote:
>>> On 10/09/2021 12:47, David Brown wrote:
>>>> On 10/09/2021 11:10, Juha Nieminen wrote:
>>>
>>>>> However, gcc -O0 is quite useful in development. For starters, when you
>>>>> are interactively debugging (eg. with gdb, or any of the myriads of
>>>>> debuggers in different IDEs), you usually don't want things like your
>>>>> functions being inlined, loops unrolled, compile-time arithmetic
>>>>> (other than, of course, that of constexpr/consteval functions), etc.
>>>>
>>>> I always compile with debugging information, and I regularly use
>>>> breakpoints, stepping, assembly-level debug, etc.  I /hate/ having to
>>>> deal with unoptimised "gcc -O0" code - it is truly awful.  You have vast
>>>> amounts of useless extra code that hides the real action.  In the
>>>> assembly, the code to load and store variables from the stack, instead
>>>> of registers, often outweighs the actual interesting stuff.
>>>> Single-stepping through your important functions becomes far harder
>>>> because all the little calls that should be inlined out of existence,
>>>> become layers of calls that you might have to dig through.  Most of the
>>>> what you are looking for is drowned out in the noise.
>>>
>>> I agree with JN. With optimised code, what you have may have little
>>> relationship with the original source code. If you're trying to trace a
>>> logic problem, how do you map machine code to the corresponding source?
>>>
>>
>> It's a /lot/ easier with -O1 than -O0.  Or you use the debugger.
> 
> Oh, you mean look at the ASM manually? In that case definitely through
> -O0. If I take this fragment:
> 
>       for (int i=0; i<100; ++i) {
>           a[i]=b+c*d;
>           fn(a[i]);
>       }
> 
<snip listings>
> 
> So which one gets the prize?

The one which runs correctly the fastest!

You appear to be stuck in the "C as a high level assembler" mindset. 
This shouldn't be true for C and definitely isn't true for C++.

Optimised code often bears little resemblance to the original source and 
the same source compiled with the same compiler can be optimised in 
different ways depending on the context.

<snip>

> But it's still not as easy to follow as either of mine.
> 
> So, yes, decent tools are important...

They are, and decent appears to have different meanings to different 
people!  From my perspective a decent compiler will correctly compile my 
code, provide excellent diagnostics and a high degree of optimisation.

>>> Or more importantly, how does the debugger do so?
>>
>> The compiler generates lots of debug information, and the debugger reads
>> it.  How else would it work?
> 
> Have a look at my first example above; would the a[i]=b+c*d be
> associated with anything more meaningful than those two lines of assembly?

Does it matter?

>>> And for source code, what difference should it make whether the
>>> generated code is optimised or not?
>>>
>>
>> Because it is not always correct!
>>
>> Sometimes the issue is on the lines of "Why is this taking so long?  I
>> had expected less than 0.1µs, but it is taking nearly 0.2µs."  You need
>> to look at the assembly for that.
> 
> That's the kind of thing that the unit tests Ian is always on about
> don't really work.

Unit tests test logic, not performance.  We run automated regression 
tests on real hardware to track performance.  If there's a change 
between builds, it's trivial to identify the code commits that caused 
the change.

>> I don't have a problem with compile speed.
> 
> Then just scale up the size of the project; you will hit a point where
> it /is/ a problem! Or change the threshold at which any hanging about
> becomes incredibly annoying; mine is about half a second.

Correct, so you scale up the thing you have control over, the build 
infrastructure.  It's safe to say that no one here has their own C++ 
compiler the can tweak to go faster!  Even with your tools, you have to 
sacrifice diagnostics and optimisations for speed.

> Just evading the issue by, insteading of getting a tool to work more
> quickly, making it try to avoid compiling things as much as possible,
> isn't a satisfactory solution IMO.

A build system is more than just a compiler, there are plenty of other 
tools you can deploy to speed up builds.

> It's like avoiding spending too long driving your car, due to its only
> managing to do 3 mph, by cutting down on your trips as much as possible.
> It's a slow car - /that's/ the problem.

Poor analogy.  A better one is your car is slow because it only has a 
single cylinder engine, so you can make it faster with a bigger cylinder 
or more of them!

-- 
Ian.