- Refactoring dilemma - 8 Updates
- Const on pass-by-value formal args - 1 Update
| "Öö Tiib" <ootiib@hot.ee>: Jun 28 04:51PM -0700 > C++ is known for its zero-overhead abstraction. I'm trying to figure > out if there's something I'm doing wrong or if the compilers I've tried > are not able to provide abstraction for free in this area. Huh? I felt I asked why you aim for size over speed, you tell something that is not from this world. Zero overhead? That means C++ produces ideal assembler? You misunderstood. It is zero overhead principle ... aim ... goal. Actual compilers can not translate code into ideal assembler. There is always some overhead. Now even if there was a super compiler then the ideally short assembler for most algorithms has some speed overhead compared to ideally fast assembler for same algorithm (that has some size overhead). So zero overhead in both senses would be still simply impossible. So why you value size over speed? |
| woodbrian77@gmail.com: Jun 28 06:50PM -0700 On Wednesday, June 28, 2017 at 6:52:12 PM UTC-5, Öö Tiib wrote: > > are not able to provide abstraction for free in this area. > Huh? I felt I asked why you aim for size over speed, you tell something > that is not from this world. There's a link between size and speed: int main (){return SUCCESS;} > Zero overhead? That means C++ produces ideal assembler? You misunderstood. > It is zero overhead principle ... aim ... goal. Actual compilers can not > translate code into ideal assembler. There is always some overhead. The question is if there's unnecessary overhead. This is quote from earlier in the thread: "And further: What you do use, you couldn't hand code any better." In one case, my use of variadic templates yields larger results from compilers than if I don't use variadics. But in two other cases, compilers appear to produce better results. Supporting both options as you suggested earlier would be a headache for me. I don't have resources to support lots of options right now. Rebbe Nachman said, "All the world is just a narrow bridge -- the most important thing is not to be afraid." I have to figure out one of these options to use for the time being. Is Russia attacking Ukraine with cyberattacks? Rebbe Nachman was from Ukraine if I remember right. > assembler for same algorithm (that has some size overhead). So zero > overhead in both senses would be still simply impossible. > So why you value size over speed? Maybe someone with g++ 7.2 or clang 5 could build the two approaches and report the results. Brian Ebenezer Enterprises - If you like bread, you should love the Ukraine -- its the bread basket of the world. http://webEbenezer.net |
| Gareth Owen <gwowen@gmail.com>: Jun 29 06:20AM +0100 > There's a link between size and speed: > int main (){return SUCCESS;} There is. But it sure isn't smaller == faster. |
| Ian Collins <ian-news@hotmail.com>: Jun 29 05:47PM +1200 > cd onwards > make example > Then post here what the two sizes are. Thanks. The code doesn't compile with Clang5 (or at least the library it uses) In file included from ./SendBuffer.hh:2: ./ErrorWords.hh:30:13: error: no matching member function for call to 'append' whatStr.append(s); ~~~~~~~~^~~~~~ ... Also string_view is still in std::experimental. -- Ian |
| "Öö Tiib" <ootiib@hot.ee>: Jun 29 06:25AM -0700 > > Huh? I felt I asked why you aim for size over speed, you tell something > > that is not from this world. > There's a link between size and speed: There is very rough correlation but no relation. > int main (){return SUCCESS;} Programs that do nothing useful are not what we discuss I hope. > > It is zero overhead principle ... aim ... goal. Actual compilers can not > > translate code into ideal assembler. There is always some overhead. > The question is if there's unnecessary overhead. Yes, non-ideal assembler has always some unnecessary overhead. > This is quote from earlier in the thread: > "And further: What you do use, you couldn't hand code any better." That is again principle, the goal to pursue, the philosophy how to go, not something that actual C++ compilers have somehow magically achieved already. > appear to produce better results. > Supporting both options as you suggested earlier would be a headache > for me. I don't have resources to support lots of options right now. The cheapest is just to do nothing if you ask that from me. > important thing is not to be afraid." I have to figure out one of these > options to use for the time being. Is Russia attacking Ukraine with > cyberattacks? Rebbe Nachman was from Ukraine if I remember right. To my knowledge current cryptoworm (where Ukraine got lot of damage) seem modified versions of EternalBlue and EternalRomance. Those two are exploits from bigger set of hacking tools that were developed by the National Security Agency of United States Department of Defence and that last year leaked onto the Internet by hackers. Microsoft has already patched the holes of those exploits but unfortunately in countries like Ukraine and Russia there are significant usage of pirated versions of Windows. Anyway it sounds like nonsense to accuse Russians of those worms. > > So why you value size over speed? > Maybe someone with g++ 7.2 or clang 5 could build the two > approaches and report the results. So ... why you ignore speed? |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Jun 29 04:19PM +0100 On Wed, 28 Jun 2017 18:50:40 -0700 (PDT) > There's a link between size and speed: > int main (){return SUCCESS;} Your argument seems to be that faced with two binaries compiled from the same source code which are of different size, the smaller one is going to be the faster. However, some speed optimizations such as loop unrolling will increase binary size, but run faster. There is often a size and speed trade off to be made. For example, with gcc code compiled with -Os will be smaller than code compiled with -O2, but is likely to run slower: -Os contains most of -O2 except those optimizations which increase code size, and includes some addition code size reducing options. If small binary size is more important to you than speed, the first thing to do is to use -Os optimization. But you need to question yourself why you prefer small size to speed. |
| woodbrian77@gmail.com: Jun 29 10:45AM -0700 On Thursday, June 29, 2017 at 12:47:39 AM UTC-5, Ian Collins wrote: > ~~~~~~~~^~~~~~ > ... > Also string_view is still in std::experimental. I think that's the problem. On FreeBSD (TrueOS) with clang 4 it builds fine. String_view isn't in experimental for clang 4. Thanks for the info. Brian Ebenezer Enterprises http://webEbenezer.net |
| woodbrian77@gmail.com: Jun 29 03:03PM -0700 On Thursday, June 29, 2017 at 10:20:02 AM UTC-5, Chris Vine wrote: > If small binary size is more important to you than speed, the first > thing to do is to use -Os optimization. But you need to question > yourself why you prefer small size to speed. If the transformation I made produced larger results in all cases, I'd probably give up on the variadic option. But in two cases, the compilers seemed to handle it well and in one case not. That's my basis for hoping that the third case is an aberration and eventually can be straightened out. Brian Ebenezer Enterprises - "Do not be conformed to this world, but be transformed by the renewing of your mind." Romans 12:2 http://webEbenezer.net |
| Manfred <noname@invalid.add>: Jun 29 06:47PM +0200 On 6/13/2017 12:57 AM, Stefan Ram wrote: > the interface and a region for the implementation: > int f( int x ) /* interface */ > { const x; return 2 * x; } /* implementation */ The ancient (and still valid) C syntax comes to mind: int f( x ) const int x; { return 2 * x; } (the syntax is valid C11, where the 'const' part only applies to modern C, while the identifier-list syntax dates back from the beginning of time) |
| 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