Monday, July 2, 2018

Digest for comp.lang.c++@googlegroups.com - 10 updates in 4 topics

Bart <bc@freeuk.com>: Jul 02 08:47PM +0100

On 02/07/2018 07:43, David Brown wrote:
 
> You have that ass-backwards. Once you have a good optimiser, you no
> longer have to concern yourself about trying to implement something like
> "max" efficiently - the compiler will handle it smoothly already.
 
In every program, in each place it's used, on each compile. That's the
point, and the disadvantage of having large chunks of a language
implemented in itself in a way that requires that prologue code to be
constantly recompiled.
David Brown <david.brown@hesbynett.no>: Jul 02 10:06PM +0200

On 02/07/18 21:47, Bart wrote:
> point, and the disadvantage of having large chunks of a language
> implemented in itself in a way that requires that prologue code to be
> constantly recompiled.
 
Computers are /good/ at doing repetitive, menial tasks. They are /good/
at re-compiling a "max" macro in a few microseconds. Yes, over time
this re-compilation waste will build up - perhaps to the tune of several
whole seconds of wasted time every single year!
 
Is that really so bad that it is worth your time implementing a "max"
operator that will only ever exist on one compiler that no one else
uses? Including test suites, documentation, etc.?
 
There are enough challenges in writing a good compiler, and enough
places where careful thought and design can make a real difference. And
there are enough other things in life to spend your time on. So if you
want to have fun writing a compiler, I'd recommend concentrating on the
important bits (unless you think implementing a max operator is fun - in
which case, go for it! But call it fun, don't pretend it is relevant to
performance). And if you are not having fun writing a compiler, get a
decent optimising compiler, learn how to use it, and stop worrying about
lost microseconds.
Bart <bc@freeuk.com>: Jul 02 09:44PM +0100

On 02/07/2018 21:06, David Brown wrote:
> at re-compiling a "max" macro in a few microseconds.  Yes, over time
> this re-compilation waste will build up - perhaps to the tune of several
> whole seconds of wasted time every single year!
 
So, when people say that C++ is slow to compile (compared to equivalent
code in other languages), then what is the reason?
 
--
bart
legalize+jeeves@mail.xmission.com (Richard): Jul 02 09:41PM

[Please do not mail me a copy of your followup]
 
Bart <bc@freeuk.com> spake the secret code
 
>So, when people say that C++ is slow to compile (compared to equivalent
>code in other languages), then what is the reason?
 
The megabytes of transitively included header files that have to be
re-parsed, semantically analyzed and digested every time you compile a
translation unit.
 
In languages like C# and Java, the necessary information is stashed by
the compiler in a binary form and referenced from "import statements"
(Java) or "using statements" (C#).
 
C++ Modules are an ongoing effort to bring such a binary specification
of interface declarations to C++ with an eye towards the same speed
improvements.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
Bart <bc@freeuk.com>: Jul 02 07:51PM +0100

On 02/07/2018 08:02, Wouter Verhelst wrote:
>> code, over and over again.
 
> Yeah, that's true, but who cares? If the compiler is slow during compile
> time so that it can produce a fast program, I couldn't care less.
 
Suppose it's unnecessarily slow?
 
> As far as I'm concerned, the compiler can spend an hour optimizing a
> simple "hello world" program if that means that program's runtime is cut
> in half. Yes, I'm exaggerating, but you get the point.
 
Do you really need the maximum possible speed for the 99.9% of builds
where you are only testing or debugging? That would be rather a lot of
wasted hours.
 
But some of these overheads can impinge on build speeds even with
optimisation turned off.
 
--
bart
David Brown <david.brown@hesbynett.no>: Jul 02 09:32PM +0200

On 02/07/18 10:42, Tim Rentsch wrote:
>> defined. [...]
 
> I see at least three other criticisms:
 
> (1) Doesn't cover all standard types;
 
I'm missing bool, which could easily be added. "max" doesn't make sense
for the complex types. Are things like size_t and wchar_t always
typedef'ed (or #define'd) to standard types, or could they be different
types outside the standard integer types? I'm not sure how they would
fit with a _Generic like this - but size_t at least should be there.
 
Any others that I am missing?
 
> (2) A bug in one of the types it does cover;
 
Whoops, so there is. I can't claim it was well-tested code - it was
showing an idea, rather than being recommended real code.
 
 
> (3) Falls down badly in cases where the two arguments have
> different types.
 
Yes, that's a challenge. It will be fine if "a" is at least as big a
type as "b", but not vice versa. The only way I can think of to solve
that problem would be nested _Generic's - perhaps with a utility
_Generic macro for giving a common type for arithmetic operations on two
different types. However it is done, it would be ugly.
Ian Collins <ian-news@hotmail.com>: Jul 03 08:39AM +1200

On 03/07/18 07:29, jacobnavia wrote:
> Le 01/07/2018 à 23:40, Vir Campestris a écrit :
>> Use the old syntax. Then you can type i +=2 to skip the alternate ones.
 
> Why is the index not included as info with the new syntax?
 
Not everything that can be iterated over has an index, sets and maps for
example.
 
--
Ian.
jacobnavia <jacob@jacob.remcomp.fr>: Jul 02 09:29PM +0200

Le 01/07/2018 à 23:40, Vir Campestris a écrit :
> Use the old syntax. Then you can type i +=2 to skip the alternate ones.
 
Why is the index not included as info with the new syntax?
 
Yes, you can figure it out, as several people pointed me to a simple
solution, so its not a big deal.
 
Of course you can do i += 2, but I ws thinking in terms of a filter
going through all records according to some criteria. An easy criteria
was using the index, but that was a very bad example.
 
Thanks
Manfred <noname@invalid.add>: Jul 02 08:42PM +0200

On 7/1/2018 10:58 PM, Alf P. Steinbach wrote:
>         cout << "The middle of main is that in Spain or this all in
> vain?\n";
>     }
 
I know, which requires:
a) n4659 11.6.3 sub(5.2).
b) n4659 15.2 sub6, with its good list of exceptions.
 
legalize+jeeves@mail.xmission.com (Richard): Jul 02 09:14PM

[Please do not mail me a copy of your followup]
 
Borneq <borneq@antyspam.hidden.pl> spake the secret code
 
>I have small project which uses LLVM.
>LLVM under Linux has 134 *.a files counting 5 gigabytes.
>I can't add everything to CodeBlocks project.
 
You're better off asking on a relevant LLVM developer's list.
 
<http://lists.llvm.org/mailman/listinfo>
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)