- "inline" works properly for me, Visual C++ 2015. - 22 Updates
- Health issues ? - 3 Updates
| woodbrian77@gmail.com: Jan 17 05:58PM -0800 On Tuesday, January 17, 2017 at 1:51:23 PM UTC-6, red floyd wrote: > > service is my main contribution. > So basically, your contribution to this group is shilling > your own software, I have thousands of lines of high quality open source code here: https://github.com/Ebenezer-group/onwards G-d has used many people from this newsgroup and other forums to help me develop the software. I think I have one of the best programming languages and architectures for developing an on line code generator. As I see it, my code generator is another feather in C++'s cap. Do Go, D or Rust have on line code generators? > and bitching about everyone else's choice > of words. I nag those who swear here. Think of it as a virtual clean room. Brian Ebenezer Enterprises http://webEbenezer.net |
| Juha Nieminen <nospam@thanks.invalid>: Jan 18 07:16AM >> defined in headers. > That it is "just a hint" is 100% correct, but that doesn't have anything > to do with the linker. It has everything to do with the linker. Why do you think that you have to specify the 'inline' keyword if you ever implement a function in a header file that gets included in more than one source file? As for actually inlining, the compiler is completely free to ignore that keyword completely and have it play no part in its optimization decisions. |
| Juha Nieminen <nospam@thanks.invalid>: Jan 18 07:22AM > for me it does not make any sense for the compiler NOT to do this like: > ret = {x + y}; // (*) If the compiler sees the function's implementation from the place where it's being called, it will probably inline it, but not because you wrote the keyword 'inline'. (And, in fact, some modern compilers will even try to inline functions across compilation units during linking.) The compiler is free to inline the function even if there is no 'inline' keyword. The compiler is free to *not* inline the function even if the keyword is there. Where 'inline' does make a tangible difference (and must do so because the standard mandates it) is when the same function implementation appears in more than one compilation unit (which most typically happens when the implementation is in a header file that gets included in more than one source file). Without the 'inline' keyword you would get a linker error for multiple symbols; with the keyword the linker will just use one of them and discard the rest. |
| JiiPee <no@notvalid.com>: Jan 18 07:41AM On 18/01/2017 07:22, Juha Nieminen wrote: > The compiler is free to*not* inline the function even if the > keyword is there. and free to use the argument temporaries as well. But if I have a loop where I run some function 10 millions times this might become significant whether it inlines or not. And does the compiler understand this? Does it take account that I am running that inline code in such a loop? But it surely cannot always know what is the size of the loop. This is why I think it would be better to have a "pure inline" keyword which ALWAYS inlines. Because otherwise I have to go and 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. Values get() { return values; } this does not make any overhead but calling it looks a bit ugly: vals.get()[5]; instead of: vals.get(5); |
| David Brown <david.brown@hesbynett.no>: Jan 18 09:26AM +0100 > https://github.com/Ebenezer-group/onwards > G-d has used many people from this newsgroup and other > forums to help me develop the software. No, he has not - at least not from this newsgroup. I can't answer for "other forums". If /you/ have had help and learned more about C++ from this newsgroup, then that's great. Helping each other and teaching each other is one of the main purposes of the group. But speaking for myself, if I give someone in a newsgroup some useful ideas or tips, it is to help the /people/ in the group. It is /not/ to help people's software or their projects. Do you understand the difference? Personally, I think your software has little use and I think your "this is all about God" attitude drives away any developers or users who might be interested - I certainly would not waste my time helping with the development. But I am quite happy to respect that /you/ feel your project is important and useful, and I am quite happy to help /you/ if I had C++ tips or ideas to give you. Do you understand the difference here? And /God/ has not "used" me, or anyone else here. /You/ are free to think he has - but you are /not/ free to attribute all the help you have received from /people/ to your invisible friend. If someone helps me, I thank /them/ - I don't thank the bogeyman. > architectures for developing an on line code generator. > As I see it, my code generator is another feather in C++'s > cap. Do Go, D or Rust have on line code generators? Until you have established a community and support around your software, it is nothing more than a small personal project. And you will never establish such a community until you drop the narcissism and megalomania. You are /not/ God's prophet and later-day Noah sent to save the world from Java by bringing back his people to the true C++ way. You are someone who has an idea for a C++ application that you feel is important, and you are having a hard time selling that idea to others. When you understand that, and begin to think about what it will take to get a community around your idea, then you can make progress. And here is a free tip for you /and/ your project - drop every hint of religion, politics, nationalism, sexism and other bigotry from your website, your project and your posts. (Honestly - I write this for your own good, and the benefit of your project, not to attack you or your beliefs. It is also for the good of this newsgroup - I would much rather see you write posts based on your C++ knowledge and experience, than more nonsense about how your "middleware writer" is the best idea since sliced bread and will save the world.) >> of words. > I nag those who swear here. Think of it as a > virtual clean room. This is not a "virtual clean room". Other people don't think so - why do /you/ think you have the right to impose bizarre rules on the language people use here? If someone were using seriously bad language, then it would be fine to make an occasional post asking them to stop. Knee-jerk reactions and auto-responder posts are never helpful. |
| David Brown <david.brown@hesbynett.no>: Jan 18 09:32AM +0100 On 17/01/17 22:29, JiiPee wrote: >>> measure time how long it takes to be sure. >> Or you could simply look at the generated machine code. > yes true. but have not done that really before. It is definitely worth getting familiar with viewing generated assembly. You won't want to do it for everything - in particular, you will want to stick to small test functions. It can quickly get overwhelming for larger bits of code. The details are going to be beyond you for a while, but you can get some ideas pretty quickly, such as whether a function is inlined or not. Probably the most convenient way to do this is with the online compiler at <https://gcc.godbolt.org/#>. It also lets you test out a wide variety of compilers. I recommend using "-O1" switch when you are viewing the assembly - too low optimisation makes it hard to follow the code because everything goes on the stack, and too high makes it hard to follow the re-organisation of the code structure. |
| Ian Collins <ian-news@hotmail.com>: Jan 18 09:34PM +1300 > https://github.com/Ebenezer-group/onwards > G-d has used many people from this newsgroup and other > forums to help me develop the software. If you believe in a deity, at least learn how to spell it. >> of words. > I nag those who swear here. Think of it as a > virtual clean room. A virtual clean room where you can insult whole countries with impunity? yeah, right. -- Ian |
| JiiPee <no@notvalid.com>: Jan 18 08:38AM On 18/01/2017 08:32, David Brown wrote: > viewing the assembly - too low optimisation makes it hard to follow the > code because everything goes on the stack, and too high makes it hard to > follow the re-organisation of the code structure. sure, thanks will check that |
| JiiPee <no@notvalid.com>: Jan 18 08:50AM On 18/01/2017 08:32, David Brown wrote: > viewing the assembly - too low optimisation makes it hard to follow the > code because everything goes on the stack, and too high makes it hard to > follow the re-organisation of the code structure. When I do this (-O1): inline int square(int num) { return num * num; } int foo(int q) { int a = square(q); return a * 2; } it only gives : foo(int): imul edi, edi lea eax, [rdi+rdi] ret looks like the square() disappears? Where is it? because if I do without inline I get the same foo: square(int): imul edi, edi mov eax, edi ret foo(int): imul edi, edi lea eax, [rdi+rdi] ret |
| Melzzzzz <mel@zzzzz.com>: Jan 18 09:54AM +0100 On Wed, 18 Jan 2017 21:34:45 +1300 > > G-d has used many people from this newsgroup and other > > forums to help me develop the software. > If you believe in a deity, at least learn how to spell it. Just imagine how huge your ego must be when you believe that creator of universe is personally interested in you ;) -- press any key to continue or any other to quit... |
| Robert Wessel <robertwessel2@yahoo.com>: Jan 18 02:55AM -0600 >vals.get()[5]; >instead of: >vals.get(5); There's nothing in the standard that *requires* any particular code generation by the compiler. That being said, some compilers have a "stronger" hint than the standard "inline", MSVCs "__forceinline", for example. And even that has exceptions (for example, MSVC will not normally inline recursive functions, or ones that are called virtually, or if a pointer to the function is made) - so it's still just a hint, albeit a strong one. In gcc, "__attribute__((always_inline))" will do something similar. But most compilers use some heuristics to decide what to inline. Often (usually) an inline (either explicit, or the implicit one with an inline member function) impacts that assessment. Things like number of uses, size of the function, whether or not it's called in a loop, are all things likely to be taken into account. Often other ways to influence the mechanism exist (often command line parameters or #pragmas). |
| Robert Wessel <robertwessel2@yahoo.com>: Jan 18 03:00AM -0600 > imul edi, edi > lea eax, [rdi+rdi] > ret The compiler is free to inline anything it likes. In this case, it's a very short function, and the actual inlined code is shorter than an actual call to the out-of-line function. Win all around. |
| JiiPee <no@notvalid.com>: Jan 18 09:17AM On 18/01/2017 09:00, Robert Wessel wrote: > imul edi, edi > lea eax, [rdi+rdi] > ret oh I see this imul edi, edi is doing the square. So in inline and non-inline versions the foo() is the same. |
| JiiPee <no@notvalid.com>: Jan 18 09:28AM On 18/01/2017 08:32, David Brown wrote: > Probably the most convenient way to do this is with the online compiler > at<https://gcc.godbolt.org/#>. I tried my proglem: class A { public: int a[20]; inline int get(int num) { return a[num]; } }; int foo(int q) { A a; return a.a[1] * 2; } ... and then with: int foo(int q) { A a; return a.get(1) * 2; } and they gave the same assembly, so I guess my fear for using index function parameter so that it would create a temporary is not really what happens. Seems like it does not create that temporary num-index. |
| Robert Wessel <robertwessel2@yahoo.com>: Jan 18 03:40AM -0600 >oh I see this >imul edi, edi >is doing the square. So in inline and non-inline versions the foo() is the same. Yes. This appears to be x86-64 Unix code. The calling convention for that ABI would pass the first (integer) parameter in rdi (since this is only a 32 bit parameter, only edi, the low half of rdi, is used). It's multiplied by itself (the imul instruction), then rax, the return register for that ABI, (again, the low half of that, eax, is actually used for the 32 bit value being returned) is loaded with twice the value in rdi (the lea* adds edi to itself and stores the result in eax). The code then returns to the caller. Since you omitted the inline in the second example, the compiler was obligated to create the actual callable square() function, since it might get used from elsewhere. It *could* have called square() from foo() in that case (and it might if you set the optimization level to "debug"), but as I mentioned, in this case the inlined code is actually shorter than the call instruction it would have had to generate, so it inlined it anyway. In many cases the descision is much more complex. Consider an function tagged "inline". If it's only called *once*, it's probably worth inlining in any case. If it's called more than once, if it's more than a small function, it may excessively increase code size from multiple copies being inlined. That increases cache pressure and negatively impacts performance. OTOH, even a large function may see substantial performance gains from inlining if it can be significantly specialized based on the actual parameters. Consider: int foo(int a) { blah0; if (a==1) {blah1; blah2; blah3;} else if (a==2) {blah4; blah5; blah6;} else {blah7; blah8; blah9;} blah10; } A call of "foo(2)" can be inlined as simply: {blah0; blah4; blah5; blah6; blah10;} with out the (now) dead code in the other two conditional legs, or any of the actual conditional branches. While the removal of the call overhead is important, the main advantage inlining provides is the ability to specialize the function to the point of call. *lea is "load effective address", and it's frequently (ab)used to do simple arithmetic. |
| Bo Persson <bop@gmb.dk>: Jan 17 07:37PM +0100 On 2017-01-16 20:48, JiiPee wrote: > //.. and do something with a. > } The question was about int getSum(int a, int b) { return a + b; } which any sensible compiler will inline as a + b, unless you explicitly ask it NOT to inline any functions. You can find a good example of what an optimizing compiler really does, if you look here: http://stackoverflow.com/a/11639305/597607 Note that there are no "inline"s in that code. Bo Persson |
| red floyd <dont.bother@its.invalid>: Jan 17 11:51AM -0800 > Developing and hosting the C++ Middleware Writer (CMW) as a free > service is my main contribution. So basically, your contribution to this group is shilling your own software, and bitching about everyone else's choice of words. Fuck off. |
| JiiPee <no@notvalid.com>: Jan 17 07:53PM On 17/01/2017 18:37, Bo Persson wrote: > return a + b; > } > which any sensible compiler will inline as a + b yes but are you sure? I have this kind of thing in my real code where I want to have an inline function with index parameters to arrays index. But a bit worried if it creates temporaries. But I guess I have to measure time how long it takes to be sure. |
| Vir Campestris <vir.campestris@invalid.invalid>: Jan 17 09:50PM On 17/01/2017 21:29, JiiPee wrote: > yes true. but have not done that really before. About time you did. (I'm working on a MIPS CPU at the moment, and I've never used one before. I couldn't _write_ MIPS assembler the way I could half a dozen others, but I can read it. Even the branch delay slots...) Andy |
| David Brown <david.brown@hesbynett.no>: Jan 18 12:30PM +0100 On 18/01/17 10:40, Robert Wessel wrote: >> is doing the square. So in inline and non-inline versions the foo() is the same. > Yes. > This appears to be x86-64 Unix code. Yes. The godbolt server runs on x86-64 Linux, so that's what most of its compilers generate. But it has compilers for ARM, MIPS, PPC, and several other cpus as well if that's of interest. (I've snipped the rest of your post - it's all good stuff, but I don't need to comment on it.) |
| David Brown <david.brown@hesbynett.no>: Jan 18 12:37PM +0100 On 18/01/17 10:28, JiiPee wrote: > and they gave the same assembly, so I guess my fear for using index > function parameter so that it would create a temporary is not really > what happens. Seems like it does not create that temporary num-index. /Logically/, the compiler will create a temporary here. But the compiler's optimisers will immediately hide it away - in cases like this it can happen even when you don't specify optimisation options to the compiler. The compiler is always free to generate whatever object code it likes, as long as the visible results are the same as if it had created all the temporaries, called all the functions, etc. |
| JiiPee <no@notvalid.com>: Jan 18 02:36PM On 18/01/2017 09:40, Robert Wessel wrote: > This appears to be x86-64 Unix code. its x86-64 gcc 6.3 |
| GreyCloud <mist@cumulus.com>: Jan 17 11:50AM -0700 >> Retired. And all of my cruise missiles work fine. > I doubt it, sounds like you've been put out to pasture. > Likely, you have health issues. Nope, I was very expensive and the gov. offered me a retirement package I couldn't refuse. > We're robots, programmed by Nature to play "The Stay Alive Game"; > including: Breathing, Pissing, Shitting, Breeding, etc. > Pick the LeastWorst option, and hope for the LeastWorst luck. Everyone in the world would be better off if Trump kicked the private bankers out of this country and go back to the original Bank of Congress... no interest on loans, the way it used to be. -- My problem is that I don't have enough middle fingers. |
| David Brown <david.brown@hesbynett.no>: Jan 17 10:20PM +0100 > I probably would have written - Please stop posting here > for a month or two. Possibly in a month or two we would > have the same problem, but I also believe people can change. You have made it perfectly clear that /you/ are unwilling to change, no matter how much some of your habits annoy other people. Why do you think this muppet Jeff will change? |
| Vir Campestris <vir.campestris@invalid.invalid>: Jan 17 09:51PM On 17/01/2017 21:18, Cholo Lennon wrote: > Just add him to your kill file (his posts are so hilarious that, just > for now, he is still in my white list!) I've killfiled him. It seems ever so quiet now... I put up with sausages and Christianity. Their posters have value. 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