Saturday, October 22, 2022

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

JiiPee <kerrttuPoistaTama11@gmail.com>: Oct 22 08:47AM +0300

On 21/10/2022 22:05, Lynn McGuire wrote:
> I am always concerned about speed.
 
Me also if needed. But... for example in a user interface programming
speed it not important. I mean, when opening a dialog box takes 0.0001
seconds or 0.0002 seconds makes no difference :). And I am mostly doing
this kind of programming, when small things are processed.
Bo Persson <bo@bo-persson.se>: Oct 22 06:31PM +0200

On 2022-10-21 at 20:59, Lynn McGuire wrote:
 
> And yes, I will be able to tell rather quickly if the cast is working
> properly or not.  I am minimizing usage though as I prefer char * and
> std::string.
 
If it is always 8 bytes, I would use memcpy between two buffers and skip
the pointer indirection.
 
The memcpy based implementation of C++20 bit_cast, as shown here
 
https://en.cppreference.com/w/cpp/numeric/bit_cast
 
is known to inline and optimize into
 
mov rax, From
 
for 64-bit values on common 64-bit compilers.
Lynn McGuire <lynnmcguire5@gmail.com>: Oct 22 03:03PM -0500

On 10/22/2022 12:47 AM, JiiPee wrote:
> speed it not important. I mean, when opening a dialog box takes 0.0001
> seconds or 0.0002 seconds makes no difference :). And I am mostly doing
> this kind of programming, when small things are processed.
 
I am porting a 700,000 line Fortran 77 + 50,000 line C++ engineering
software application to pure C++. I am trying to not lose any speed in
the process.
 
Thanks,
Lynn
Lynn McGuire <lynnmcguire5@gmail.com>: Oct 22 03:05PM -0500

On 10/22/2022 11:31 AM, Bo Persson wrote:
 
> is known to inline and optimize into
 
> mov rax, From
 
> for 64-bit values on common 64-bit compilers.
 
Nope, that is a lot of extra work for the thousands of places that this
interaction occurs.
 
Thanks,
Lynn
Lynn McGuire <lynnmcguire5@gmail.com>: Oct 22 05:34PM -0500

On 10/22/2022 11:31 AM, Bo Persson wrote:
 
> is known to inline and optimize into
 
> mov rax, From
 
> for 64-bit values on common 64-bit compilers.
 
But, I will keep it in mind for the future.
 
Our memory sharing technology was developed back in the late 1970s when
we were having severe memory problems on the mainframes. Over the
years, we used it all over the place. We create 300 to 20,000 (depends
on size of the simulation) memory blocks that we use all over the place
for each software run.
 
Thanks,
Lynn
Paul N <gw7rib@aol.com>: Oct 22 05:19AM -0700

For those who don't follow comp.theory, I think it is worth pointing out that Ben is trying to deal with PO by encouraging no-one to reply to him. This probably explains the posts here claiming that "Ben agrees" with things it's quite clear he does not agree with, either because PO thinks he can get away with it or to try to tempt Ben back into replying.
 
 
olcott <polcott2@gmail.com>: Oct 22 02:20PM -0500

On 10/22/2022 7:19 AM, Paul N wrote:
> For those who don't follow comp.theory, I think it is worth pointing out that Ben is trying to deal with PO by encouraging no-one to reply to him. This probably explains the posts here claiming that "Ben agrees" with things it's quite clear he does not agree with,
 
*You are a liar or did not bother to pay attention*
*You are a liar or did not bother to pay attention*
*You are a liar or did not bother to pay attention*
*You are a liar or did not bother to pay attention*
 
These references are on comp.theory:
 
On 10/17/2022 10:23 AM, Ben Bacarisse wrote:
> D(D) would not halt unless H stops the simulation.
> H /can/ correctly determine this silly criterion (in this one case)
 
*This is the "silly" criterion that Ben is referring to*
 
On 10/17/2022 12:11 AM, olcott wrote:
 
--
Copyright 2022 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer
olcott <polcott2@gmail.com>: Oct 22 05:10PM -0500

On 10/22/2022 7:19 AM, Paul N wrote:
> For those who don't follow comp.theory, I think it is worth pointing out that Ben is trying to deal with PO by encouraging no-one to reply to him. This probably explains the posts here claiming that "Ben agrees" with things it's quite clear he does not agree with,
 
*You are a liar or did not bother to pay attention*
*You are a liar or did not bother to pay attention*
*You are a liar or did not bother to pay attention*
*You are a liar or did not bother to pay attention*
 
These references are on comp.theory:
 
On 10/17/2022 10:23 AM, Ben Bacarisse wrote:
> D(D) would not halt unless H stops the simulation.
> H /can/ correctly determine this silly criterion (in this one case)
 
*This is the "silly" criterion that Ben is referring to*
 
On 10/17/2022 12:11 AM, olcott wrote:
 
--
Copyright 2022 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer
Marcel Mueller <news.5.maazl@spamgourmet.org>: Oct 22 09:21AM +0200

Am 21.10.22 um 13:44 schrieb Juha Nieminen:
> if the keyword 'inline' appears before that function implementation or
> not. I thought that gcc just ignores that keyword when making inlining
> decisions. (After all, why wouldn't it?)
 
Well, excessive inlining could be counterproductive. It causes the code
to blow up and this impacts the efficiency of the CPUs instruction cache
and probably more important the branch target buffer.
 
I have observed a similar effect at the data cache level. I had an in
memory database application. At some point we decided to deduplicate
strings to conserve memory. We expected this to significantly reduce the
memory footprint and slightly decrease performance due to the
deduplication effort. Well, that was not true. It reduced the memory
footprint and the application was /faster/ afterwards. The impact of the
large B-tree for deduplication was less than the benefit of the
increased cache efficiency.
 
So it could be relevant how many callers exist. For an externally
visible function this is unpredictable. So the size limit for automatic
inlining is probably smaller.
 
In fact the effect of inlining is only that large because the calling
convention is inefficient at least on x86/x64. I observed noticable
improvements in speed and executable size in the past by choosing mainly
register based function calls w/o standard stack frames.
Unfortunately it is not always possible, to do so. While this works well
with Windows (and OS/2), by just passing an appropriate compiler option,
it is unusable on Linux because the standard header files do not declare
the calling convention of the standard library functions. So nothing
works anymore if you change the default.
 
 
> It appears that gcc uses a different inlining strategy when dealing
> with local and global functions (that have no 'inline' keyword).
 
I guess it does for good reasons.
 
 
Marcel
scott@slp53.sl.home (Scott Lurndal): Oct 22 03:05PM


>Well, excessive inlining could be counterproductive. It causes the code
>to blow up and this impacts the efficiency of the CPUs instruction cache
>and probably more important the branch target buffer.
 
Indeed, and that is exactly why GCC refused to inline the function.
(Note, using the gcc attribute always_inline will always inline
the function, regardless of internal GCC heuristics).
 
 
>it is unusable on Linux because the standard header files do not declare
>the calling convention of the standard library functions. So nothing
>works anymore if you change the default.
 
Do note that the standard unix/linux ABI for x86_64 always passes the
first six arguments in registers when they fit. There is no need
to 'declare calling conventions' because there is only one.
JiiPee <kerrttuPoistaTama11@gmail.com>: Oct 22 09:55AM +0300

In a class when defining an assignment operator:
 
operator=(const Obj& other)
 
, if one uses the Copy-and-swap idiom to copy @other to this:
 
Obj copy(other);
copy.swap(*this);
 
, this is obviously really good looking and elegant etc. But just
wondering how much slower it would be than a straight/old (not so
elegant/risky):
 
this->a = other.a;
this->b = other.b;
...
 
? I was just checking, if doing swap(), then needs to make 2 or 3 times
more copy operations in total complare to old way for simple data types
(int, float, double, bool...). If one has many of these, then is it
gonna be much slower?
 
Or... is the compiler gonna optimize out these extra integer/double copy
operations?
Andrey Tarasevich <andreytarasevich@hotmail.com>: Oct 22 02:16AM -0700

On 10/21/2022 11:55 PM, JiiPee wrote:
 
> this->a = other.a;
> this->b = other.b;
> ...
 
With what kind of class? What is `a` and `b`?
 
If this is a flat class, then of course straightforward copying will be
faster, since it requires only one copying, while copy-and-swap will
copy the same data twice (or even thrice). The larger the class - the
slower in comparison the copy-and-swap is going to be.
 
If this is a "deep" class that handles resources, which need to be
copied, then in general case expenses spent on releasing the old
resources and cloning new ones in copy constructor or assignment
operator will dwarf the overhead brought in by swapping.
 
--
Best regards,
Andrey.
Sam <sam@email-scan.com>: Oct 22 07:50AM -0400

JiiPee writes:
 
> how much slower it would be than a straight/old (not so elegant/risky):
 
> this->a = other.a;
> this->b = other.b;
 
For a simple class, copy/swap is an overkill. But for a complex class that
contains many objects that also have their own bookkeeping, or their own
special needs, then copy/swap offers a simple way to remove a lot of code
duplication.
 
For example: if, for whatever reasons, a and b have a deleted assignment
operator, but have functional copy/move semantics.
JiiPee <kerrttuPoistaTama11@gmail.com>: Oct 22 04:02PM +0300

On 22/10/2022 14:50, Sam wrote:
> For a simple class, copy/swap is an overkill.
 
could test how much slower it is. But its simple and elegant. And no
need to then repeat code.
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)