- static guard locks - 5 Updates
- tdm gcc 5.1 slower than 4.7 - 1 Update
- A "better" C++ - 15 Updates
- A small quiz - 2 Updates
- A small quiz - 2 Updates
| Prroffessorr Fir Kenobi <profesor.fir@gmail.com>: Aug 27 11:12AM -0700 Im not sure if this is a problem of c++ only or it appleies to c, too Sometimes (usually?) when using static entities in functions the compiler puts special code which contains a lock acquire and release Thisd bloats the executable yet also slows down the code.. Im not quite sure 1)how serious this problem is? 2) in which cases it do apply? 3) how to avoid it in most easy way? 4) how to be sure my app do not contains such sh*t? |
| Paavo Helde <myfirstname@osa.pri.ee>: Aug 27 01:22PM -0500 Prroffessorr Fir Kenobi <profesor.fir@gmail.com> wrote in > 2) in which cases it do apply? > 3) how to avoid it in most easy way? > 4) how to be sure my app do not contains such sh*t? This is required by C++11 for ensuring thread-safe creation of statics in multithreaded applications. Your compiler probably has some switch or pragma to turn this feature off. For gcc I was able to find this option via google in ca 5 seconds. Cheers Paavo |
| Prroffessorr Fir Kenobi <profesor.fir@gmail.com>: Aug 27 11:59AM -0700 W dniu czwartek, 27 sierpnia 2015 20:22:45 UTC+2 użytkownik Paavo Helde napisał: > multithreaded applications. Your compiler probably has some switch or > pragma to turn this feature off. For gcc I was able to find this option via > google in ca 5 seconds. so how to turn it off ? i dont know the appriopriate naming to immediately find it |
| Prroffessorr Fir Kenobi <profesor.fir@gmail.com>: Aug 27 12:06PM -0700 W dniu czwartek, 27 sierpnia 2015 21:00:13 UTC+2 użytkownik Prroffessorr Fir Kenobi napisał: > > pragma to turn this feature off. For gcc I was able to find this option via > > google in ca 5 seconds. > so how to turn it off ? i dont know the appriopriate naming to immediately find it besides that..isnt it silly (worse than silly) for gcc to do that - it slows and bloats code that do not need that... does maybe someone know if it also applies to c? |
| Nobody <nobody@nowhere.invalid>: Aug 27 08:09PM +0100 On Thu, 27 Aug 2015 11:12:28 -0700, Prroffessorr Fir Kenobi wrote: > Thisd bloats the executable yet also slows down the code.. Im not quite > sure > 1) how serious this problem is? How frequently are those functions called? And if they're called from multiple threads, how much contention do you expect for the locks? If you don't need the functions to be re-entrant (i.e. you're not using threads or such functions are never called from more than one thread), with g++ you can use -fno-threadsafe-statics to remove the locks. > 2) in which cases it do apply? It occurs whenever you have a static local variable whose constructor requires the execution of code (i.e. the compiler can't just store the initial value in the data/bss segment, but must calculate it at run time), and the compiler can't somehow optimise the locks away. > 3) how to avoid it in most easy way? > 4) how to be sure my app do not contains such sh*t? Don't use static local variables. Put the variables at file scope so that they're guaranteed to be initialised before main() is entered. If you can't do that (e.g. because the initial value depends upon data which hasn't been initialised at that point), then the construction has to occur on the first call to the function, and the compiler has to allow for the possibility that multiple threads call the function concurrently (unless it has been told that this cannot happen; it's not as if it can deduce that by itself). |
| Prroffessorr Fir Kenobi <profesor.fir@gmail.com>: Aug 27 11:19AM -0700 i testet also other versions of tdm gcc 5.1 - slower 4.9 - slower 4.8 - slower 4.7 - faster 4.6 - faster 4.5 - compile, links, runtime exception on my code 4.4 - compile, links, runtime exception on my code 3.3 - compile but dont link on some symbols (primarely rawinput api i use, also __cxa_guard_acquire __cxa_guard_release calls) |
| Johannes Bauer <dfnsonfsduifb@gmx.de>: Aug 27 11:56AM +0200 On 26.08.2015 12:33, Juha Nieminen wrote: >> being as fast as C. > In my experience C++ achieves that beautifully. Classes generally do not incur any performance penalty over equivalent C code. (In fact, even virtual functions do not usually incur any measurable penalty. Not that you would need to use virtual functions very often anyway.) > Many things are actually more efficient in C++ than in C, due to the nature of C++. For example std::sort() is faster than qsort(), and one major reason for that is that the compiler can perform more optimizations based on the element type being sorted. Now you're shifting gears again, saying exactly what C++ people often say: Yes, we can have much cleaner code while having even BETTER performance. Then, when pressed against a real benchmark where C++ is weaker than C, you start crying and say "well we could have written a C variant that TECHNICALLY still is C++". You can't have it both ways. In my experience, working heavily with STL and containers or working with streams incurs a HEAVY performance penalty even when C++ advocates claim the opposite. Cheers, Johannes -- >> Wo hattest Du das Beben nochmal GENAU vorhergesagt? > Zumindest nicht öffentlich! Ah, der neueste und bis heute genialste Streich unsere großen Kosmologen: Die Geheim-Vorhersage. - Karl Kaos über Rüdiger Thomas in dsa <hidbv3$om2$1@speranza.aioe.org> |
| Ian Collins <ian-news@hotmail.com>: Aug 27 10:00PM +1200 Johannes Bauer wrote: > In my experience, working heavily with STL and containers or working > with streams incurs a HEAVY performance penalty even when C++ advocates > claim the opposite. Streams, yes, containers, not unless you pick the wrong one! -- Ian Collins |
| Wouter van Ooijen <wouter@voti.nl>: Aug 27 12:12PM +0200 Op 27-Aug-15 om 11:56 AM schreef Johannes Bauer: > you start crying and say "well we could have written a C variant that > TECHNICALLY still is C++". > You can't have it both ways. Yes we can have it both ways. If you are good you will use C++ to its best, and be at least as fast as C. If you are less confident, you can just use "C in C++" and still be as fast as C. The only way you (or we, or I) loose is when C++ features are used inappropriately. Wouter van Ooijen |
| Johannes Bauer <dfnsonfsduifb@gmx.de>: Aug 27 01:05PM +0200 On 27.08.2015 12:12, Wouter van Ooijen wrote: > Yes we can have it both ways. If you are good you will use C++ to its > best, and be at least as fast as C. If you are less confident, you can > just use "C in C++" and still be as fast as C. Imagine my programming language Q. In Q, you can write fantastically abstract, object-oriented code. The only Q compilers suck really bad and the language is very difficult to get optimized. Q, when used in its OO-style, regularly finishes last in all benchmarks. But Q has one redeeming features: In Q, one can include machine code by the language standard. Therefore it is possible to create a Q program that is at least as fast as ANY other implementation in any language. Therefore, Q has both the benefit of being the FASTEST while still being a super cool object-oriented language. Would you object to crowning Q the best of all programming languages? Of course you would. Because you *can't* have it both ways. Either you choose one set of features of the lanauge (nice, abstract notation) or another (performance). > The only way you (or we, or I) loose is when C++ features are used > inappropriately. This is a claim that is often used. That those benchmarks are just written by complete idiots who don't know how to use C++ well enough. If nothing else then this is a testament to the outrageous difficulty of getting C++ right (i.e. good performance while still being good OO). I wonder why nobody of the people who make those claims give it a shot and try to produce a benchmark that greatly illustrates how abstract C++ code can be written while still being as fast as C? Surely this would be a good demonstration of the language's abilities? Cheers, Johannes -- >> Wo hattest Du das Beben nochmal GENAU vorhergesagt? > Zumindest nicht öffentlich! Ah, der neueste und bis heute genialste Streich unsere großen Kosmologen: Die Geheim-Vorhersage. - Karl Kaos über Rüdiger Thomas in dsa <hidbv3$om2$1@speranza.aioe.org> |
| Johannes Bauer <dfnsonfsduifb@gmx.de>: Aug 27 01:07PM +0200 On 27.08.2015 12:00, Ian Collins wrote: >> with streams incurs a HEAVY performance penalty even when C++ advocates >> claim the opposite. > Streams, yes, containers, not unless you pick the wrong one! Or, apparently, if you *use* the container wrong. Somewhere earlier in this thread someone was making fun of people creating a vector and doing lots of push_back() operations. Because it is COMPLETELY obvious that that's a stupid idea, right? And, apparently, makes the performance go down the drain. Cheers, Johannes -- >> Wo hattest Du das Beben nochmal GENAU vorhergesagt? > Zumindest nicht öffentlich! Ah, der neueste und bis heute genialste Streich unsere großen Kosmologen: Die Geheim-Vorhersage. - Karl Kaos über Rüdiger Thomas in dsa <hidbv3$om2$1@speranza.aioe.org> |
| Melzzzzz <mel@zzzzz.com>: Aug 27 01:26PM +0200 On Thu, 27 Aug 2015 22:00:34 +1200 > > with streams incurs a HEAVY performance penalty even when C++ > > advocates claim the opposite. > Streams, yes, containers, not unless you pick the wrong one! I don't know why but when using g++ one have to do sync_with_stdio(false) in order to get good performance with streams. |
| Martin Shobe <martin.shobe@yahoo.com>: Aug 27 06:43AM -0500 On 8/27/2015 6:05 AM, Johannes Bauer wrote: > the best of all programming languages? Of course you would. > Because you *can't* have it both ways. Either you choose one set of > features of the lanauge (nice, abstract notation) or another (performance). False dichotomy. Another option is you get the nice, abstract notation when you don't need performance and performance when you do. Martin Shobe |
| Wouter van Ooijen <wouter@voti.nl>: Aug 27 02:05PM +0200 Op 27-Aug-15 om 1:05 PM schreef Johannes Bauer: > Therefore, Q has both the benefit of being the FASTEST while still being > a super cool object-oriented language. Would you object to crowning Q > the best of all programming languages? Of course you would. I don't recall anyone calling C++ the best of all (possible) programming languages? But on your 'gedankenexperiment': when that language is compared to machine code, it sure wins! (Which is exactly the C / C++ situation). > wonder why nobody of the people who make those claims give it a shot and > try to produce a benchmark that greatly illustrates how abstract C++ > code can be written while still being as fast as C? My attempt: "objects no thanks" https://www.youtube.com/watch?v=k8sRQMx2qUw Wouter van Ooijen |
| Johannes Bauer <dfnsonfsduifb@gmx.de>: Aug 27 03:19PM +0200 On 27.08.2015 14:05, Wouter van Ooijen wrote: >> the best of all programming languages? Of course you would. > I don't recall anyone calling C++ the best of all (possible) programming > languages? No, because it isn't. I never claimed it to be. Q clearly is. > But on your 'gedankenexperiment': when that language is > compared to machine code, it sure wins! (Which is exactly the C / C++ > situation). You're missing the point: I compare Q to ALL other programming languages and it beats them ALL in terms of performance. Also, it can be used to do OO, which is nice. >> try to produce a benchmark that greatly illustrates how abstract C++ >> code can be written while still being as fast as C? > My attempt: "objects no thanks" https://www.youtube.com/watch?v=k8sRQMx2qUw For MCUs you focus on memory and flash space consumption, which you show in that talk. However the amount of work you have to do as a programmer and the unintuitive highly templated copde (e.g. 28:30) results is not really something that is convincing. You worked *hard* to get results that you get for free in C++ and I find the gain (in your examples) a bit questionable. Using C++ just for the sake of using C++ isn't convincing reasoning. Cheers, Johannes -- >> Wo hattest Du das Beben nochmal GENAU vorhergesagt? > Zumindest nicht öffentlich! Ah, der neueste und bis heute genialste Streich unsere großen Kosmologen: Die Geheim-Vorhersage. - Karl Kaos über Rüdiger Thomas in dsa <hidbv3$om2$1@speranza.aioe.org> |
| Johannes Bauer <dfnsonfsduifb@gmx.de>: Aug 27 03:21PM +0200 On 27.08.2015 13:43, Martin Shobe wrote: >> (performance). > False dichotomy. Another option is you get the nice, abstract notation > when you don't need performance and performance when you do. Fair point! This is pretty much what I was trying to get at. You have a langauge that can take two different roles, but in many cases it isn't possible to fulfill both at once. In C++ advocacy that honesty is oftentimes missing and people claim that both is possible if only you're good enough at C++ programming. Cheers, Johannes -- >> Wo hattest Du das Beben nochmal GENAU vorhergesagt? > Zumindest nicht öffentlich! Ah, der neueste und bis heute genialste Streich unsere großen Kosmologen: Die Geheim-Vorhersage. - Karl Kaos über Rüdiger Thomas in dsa <hidbv3$om2$1@speranza.aioe.org> |
| Wouter van Ooijen <wouter@voti.nl>: Aug 27 03:38PM +0200 Op 27-Aug-15 om 3:19 PM schreef Johannes Bauer: >> situation). > You're missing the point: I compare Q to ALL other programming languages > and it beats them ALL in terms of performance. True, but not relevant. By that reasoning plain binary (or better yet: nand gates and solder!) beats everything. >> My attempt: "objects no thanks" https://www.youtube.com/watch?v=k8sRQMx2qUw Kudos for actually looking at it!! > For MCUs you focus on memory and flash space consumption, space, but also execution time > and the unintuitive highly templated copde (e.g. 28:30) results is not > really something that is convincing. You worked *hard* to get results > that you get for free in C++ and I find the gain (in your examples) a I think you mean C > bit questionable. Using C++ just for the sake of using C++ isn't > convincing reasoning. That talk was for a C++ audience, so I concentrated on how C++ can be used effectively on a small embedded system, which is quite unlike the 'mainstream' use of C++. The advantages of my approach are in composable library elements, which is very difficult to (effectively) do in C, and easy but inefficient in 'mainstream' C++. For instance, to blink a LED that is on an I2C exender chip, which is itself connected to two pins of another extender chip I write (with a slightly differnt version of my library): #include "targets/lpc1114fn28.hpp" typedef hwcpp::lpc1114fn28< 48 * hwcpp::MHz > target; typedef target::timing timing; typedef hwcpp::pcf8574a< hwcpp::i2c_bus_master_bb_scl_sda< target::scl, target::sda, timing::kHz< 100 > > chip1; typedef hwcpp::pcf8574a< hwcpp::i2c_bus_master_bb_scl_sda< chip1::p6, chip1::p7, timing::kHz< 100 > > chip2; int main(){ hwcpp::blinking< chip2::p4, timing >::blink(); } I use the same library elements (hwcpp::pcf8574a and hwcpp::i2c_bus_master_bb_scl_sda) twice, with different parameters. There is a catch of course: the library elements must be configured at compile time. But I am working on that :) Wouter |
| Bo Persson <bop@gmb.dk>: Aug 27 05:39PM +0200 On 2015-08-27 13:07, Johannes Bauer wrote: > creating a vector and doing lots of push_back() operations. Because it > is COMPLETELY obvious that that's a stupid idea, right? And, apparently, > makes the performance go down the drain. Yes, that was me. The silly thing was to convert a statically initialized, fixed size, array in C to a dynamically resized array in C++, and blame that on the language. Bad code runs slowly in any language. Bo Persson |
| Bo Persson <bop@gmb.dk>: Aug 27 07:33PM +0200 On 2015-08-27 18:06, Stefan Ram wrote: > A Conversation with Bjarne Stroustrup, Part I > by Bill Venners > October 13, 2003 They are if you use them the same way. They are not if you do: const int Array[1000000] = {0}; and std::vector V; for (i = 0; i != 1000000; ++i) V.push_back(i); So why do that in a benchmark? Bjarne's favorite is std::sort(V.begin(), V.end()); vs qsort(Array, sizeof(something), sizeof(something), compare); where std::sort is not only easier to use, but also A LOT faster because it is easily inlined and tuned by the compiler. Bo Persson |
| Bo Persson <bop@gmb.dk>: Aug 27 07:35PM +0200 On 2015-08-27 19:33, Bo Persson wrote: > std::vector V; > for (i = 0; i != 1000000; ++i) > V.push_back(i); ^^^ or V.push_back(0); as it were |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Aug 27 06:43PM +0100 On Thu, 27 Aug 2015 13:07:46 +0200 > creating a vector and doing lots of push_back() operations. Because it > is COMPLETELY obvious that that's a stupid idea, right? And, > apparently, makes the performance go down the drain. I agree with your views about streams, but if this is your best point about containers, then you have it wrong. The example to which you refer was not deprecating using push_back() on a vector (it is fine if you have reserved enough space in advance where the size is known at run time, and just as efficient as the C equivalent if you don't know the size in advance and therefore have to reallocate at intervals). In fact using push_back() or emplace_back() with reserve() is often the best way to do it because it avoids default constructing the elements of the container when constructing the container - you can do a single construction of each element 'in situ'. The thing that was being deprecated in the post to which you refer was comparing the performance of a statically sized C array with a C++ vector subject to dynamic resizing. There is nothing wrong with using a normal statically sized C array in C++ (I use them all the time) but if you are allergic to them there is also std::array. The advantage of std::array is that it suppresses pointer decay. C++ also allows you to do object construction in uninitialized memory using std::uninitialized_copy(), if you really need to. Chris |
| ram@zedat.fu-berlin.de (Stefan Ram): Aug 27 03:28AM What's wrong with the following code? The error is in the definition of f, and it's not about style but just about straight errors. #include <iostream> #include <ostream> decltype(auto)f(){int v=2;return(v);} int main(){::std::cout<<f()<<'\n';} One bonus point, if one can answer it without using a compiler. |
| ram@zedat.fu-berlin.de (Stefan Ram): Aug 27 04:06PM >The silly thing was to convert a statically initialized, fixed size, >array in C to a dynamically resized array in C++, and blame that on the >language. »Bjarne Stroustrup: ... I think a better way of approaching C++ is to use some of the standard library facilities. For example, use a vector rather than an array. ... vectors really are as fast as arrays.« A Conversation with Bjarne Stroustrup, Part I by Bill Venners October 13, 2003 |
| Victor Bazarov <v.bazarov@comcast.invalid>: Aug 27 08:38AM -0400 On 8/26/2015 11:28 PM, Stefan Ram wrote: > decltype(auto)f(){int v=2;return(v);} > int main(){::std::cout<<f()<<'\n';} > One bonus point, if one can answer it without using a compiler. Without much experience in C++11 yet, or C++14 for that matter, it does seem strange to me to see 'auto' as the argument to 'decltype' operator. V -- I do not respond to top-posted replies, please don't ask |
| Wouter van Ooijen <wouter@voti.nl>: Aug 27 03:07PM +0200 Op 27-Aug-15 om 5:28 AM schreef Stefan Ram: > decltype(auto)f(){int v=2;return(v);} > int main(){::std::cout<<f()<<'\n';} > One bonus point, if one can answer it without using a compiler. Does using google disqualify me? decltype(auto) forces decltype to use the same type-determining rules as auto. The important distinction between the plain decltype rules and the auto rules is that the latter can determine a type to be a reference, which is what happens here. Hence the code is effectively int & f(){ int v=2; return v; } What I am not sure of is whether v instead of (v) would still give the same effect? Wouter |
| 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