- Read again... - 1 Update
- The README files for my C++ Linux projects were just updated.. - 1 Update
- My Scalable Parallel C++ Conjugate Gradient Linear System Solver Library was ported to Linux - 2 Updates
- My C++ synchronization objects library was ported to Linux - 1 Update
- Why is inline function "not working" (like I expected)? - 4 Updates
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:
Post a Comment