Wednesday, January 18, 2017

Digest for comp.lang.c++@googlegroups.com - 9 updates in 5 topics

Ramine <toto@toto.net>: Jan 18 10:18PM -0800

Hello....
 
 
I have forgotten to update the readme files for my C++ Linux projects,
so the README files for my C++ Linux projects were just updated..
 
Please download again my C++ synchronization objects library for Linux
from here:
 
https://sites.google.com/site/aminer68/c-synchronization-objects-library
 
And download again my Scalable Parallel C++ Conjugate Gradient Linear
System Solver Library for Linux from here:
 
 
https://sites.google.com/site/aminer68/scalable-parallel-c-conjugate-gradient-linear-system-solver-library
 
 
Thank you,
Amine Moulay Ramdane.
Ramine <toto@toto.net>: Jan 18 10:16PM -0800

Hello,
 
 
I have forgot to update the readme files for my C++ Linux projects, so
the README files for my C++ Linux projects were just updated..
 
Please download again my C++ synchronization objects library for Linux
from here:
 
https://sites.google.com/site/aminer68/c-synchronization-objects-library
 
And download again my Scalable Parallel C++ Conjugate Gradient Linear
System Solver Library for Linux from here:
 
 
https://sites.google.com/site/aminer68/scalable-parallel-c-conjugate-gradient-linear-system-solver-library
 
 
Thank you,
Amine Moulay Ramdane.
Ramine <toto@toto.net>: Jan 18 09:16PM -0800

Hello...
 
 
My Scalable Parallel C++ Conjugate Gradient Linear System Solver Library
was ported to Linux , please download the zip file for Linux that ends
with "_linux" in its name.
 
Now it works with both Windows and Linux on (x86)
 
You can download it from:
 
https://sites.google.com/site/aminer68/c-synchronization-objects-library
 
 
Thank you,
Amine Moulay Ramdane..
Ramine <toto@toto.net>: Jan 18 09:31PM -0800

On 1/18/2017 9:16 PM, Ramine wrote:
 
> https://sites.google.com/site/aminer68/c-synchronization-objects-library
 
> Thank you,
> Amine Moulay Ramdane..
 
 
I correct:
 
You can download it:
 
 
https://sites.google.com/site/aminer68/scalable-parallel-c-conjugate-gradient-linear-system-solver-library
 
 
Thank you,
Amine Moulay Ramdane.
Ramine <toto@toto.net>: Jan 18 09:13PM -0800

Hello....
 
 
My C++ synchronization objects library was ported to Linux , please
download the zip file for Linux that ends with "_linux" in its name.
 
Now it works with both Windows and Linux on (x86)
 
You can download it from:
 
https://sites.google.com/site/aminer68/c-synchronization-objects-library
 
 
Thank you,
Amine Moulay Ramdane.
JiiPee <no@notvalid.com>: Jan 18 02:42PM

On 18/01/2017 11:37, David Brown wrote:
> /Logically/, the compiler will create a temporary here. But the
> compiler's optimisers will immediately hide it away
 
 
But I am still thinking.. and I have this problem that how can I be sure
it will always hide that away?
 
Say I create a loop which runs 10 million times per second and i call
that function. I know that today it hides away that temporary, but what
about next year when I get a new compiler version... is it guaranteed to
do the same?? How can I be sure it does? Or do I need to next year also
double check its still hiding it away? You see my problem?
 
 
thats why I would kind of rather have something like:
 
forceinline int foo() {....}
 
So I can be sure in all versions it will surely inline it. and thus the
program runs the same in different platforms.
 
I think this is a similar problem to "is the integer size the same in
all platforms... how can I be sure int is the same size in the
furutere?" (well i know how to do that, but its a similar problem)
David Brown <david.brown@hesbynett.no>: Jan 18 04:31PM +0100

On 18/01/17 15:42, JiiPee wrote:
> about next year when I get a new compiler version... is it guaranteed to
> do the same?? How can I be sure it does? Or do I need to next year also
> double check its still hiding it away? You see my problem?
 
I don't see why you are thinking of this as a problem.
 
Concentrate on writing /correct/ code. Put a little thought into how a
compiler might be able to optimise code - the more details the compiler
can see, the more efficient code it can produce. Learn to understand
and use the basic compiler flags for optimisation. Learn how to avoid
code constructs that appear to work on low optimisation but actually
have undefined behaviour that becomes apparent at higher optimisation.
 
Studying generated assembly is a good way to learn more about your
compiler, and to understand how it "thinks".
 
And then let the compiler do its job.
 
In some cases, different compiler versions will have regressions in
their speed, but it is not common. Usually they get better with newer
versions. And all compilers will get such basic stuff as this.
 
You only need to start worrying about the details of optimisation /if/
your code runs too slowly, and you have /measured/ it running too slowly
- or if you are writing such low-level code that lots of people will use
it in time-critical situations.
 
 
> forceinline int foo() {....}
 
> So I can be sure in all versions it will surely inline it. and thus the
> program runs the same in different platforms.
 
Compilers usually have extensions to give you that - you rarely need it.
You certainly don't need it here. Compilers generally do a better job
than humans at deciding what should be inlined.
 
> I think this is a similar problem to "is the integer size the same in
> all platforms...
 
No, that is about program correctness - not efficiency.
 
Bo Persson <bop@gmb.dk>: Jan 18 05:16PM +0100

On 2017-01-18 15:42, JiiPee wrote:
 
> I think this is a similar problem to "is the integer size the same in
> all platforms... how can I be sure int is the same size in the
> furutere?" (well i know how to do that, but its a similar problem)
 
If we don't know what the next platform is, it is hard to decide on a
one-size-fits-all solution. Surely, if you are going to port the code
both to a smart watch and to a mainframe, the inlining decision will be
different.
 
 
Bo Persson
Vir Campestris <vir.campestris@invalid.invalid>: Jan 18 09:01PM

On 18/01/2017 07:41, JiiPee wrote:
> check the assemply code to see what happened.... or time it. So that
> takes more development time to do that. Well, other option I have is to
> make a reference based function instead, but it just looks uglier.
 
You might like to read about "profile guided optimisation".
 
Things can be complex. If you inline functions it may be that your code
will no longer fit in the first level cache of the CPU. Or maybe the
second level. Or maybe even the RAM you have available.
 
I recall a guy from Microsoft saying that they build with optimise for
minimum size - because a page fault can ruin your day. (It will probably
take milliseconds to resolve, and you need a lot of performance
improvements to be worth that).
 
Andy
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.

No comments: