+TankdozerCavalry That's like saying C is faster than assembly. It isn't, idiomatic C++ may make it practically easier to write faster code but the compiler is doing all the work. Ultimately C gives you lower level, and greater control, which means you can hand tweak things to make the code even faster than the C++ compiler. A skilled assembly programmer will outperform any compiler given enough time. Likewise with a skilled C programmer and a C++ compiler. For example, Bartosz doesn't even use the full power of C. He doesn't use the restrict keyword in the opening example for instance - I can guarantee you this would've made the C implementation much faster than the C++ implementation.
@QuentinUK
8 жыл бұрын
+TankdozerCavalry For normal speaking select the cog icon (on the right, Settings) and then Speed. From the popup menu select 0.5
@rafaelmoura8688
8 жыл бұрын
the restrict keyword is supported in C++ by some compilers, and can be used with references too ( as __restrict by gcc and clang, and possibly MSVC), It is just not part of the standard yet, also LTO can help with that ( but I prefer using the keyword). And there is no advantage using the restrict keyword in that opening example, since the code is not using/loading the same 'memory address'/'element' more than 1 time in each loop, he is just iterating over it. Also even without the 'restrict' keyword it is possible to have the same behaviour by creating a 'const local temporary' to hold the value for you, then you get rid of reloading the same value. If you know your tools doesn't really meter if you're using C or C++ by the way you can go down to the metal in C++ as you do in C, you can use both languages together, you can inline ASM in both... Yes the C++ libraries have functions optimized for the hardware. But of course you can write even a better version in C (or C++ ) and its fun, but also you're better be not in a hurry. So I just don't believe that just the keyword can make it faster than some fancy implementation using special instructions for the target CPU ( and might be using the 'restrict' benefits too) as some library can provide.
@charlesd4572
8 жыл бұрын
The restrict keyword always has the advantage of allowing the compiler to assume that nothing else is pointing at that address - it cannot do this in any example unless you tell it so. The const keyword would help in cases where the memory is used for read only. The compiler in the given example will probably work that out anyways if compiled under optimisation. I have used the restrict keyword in both C++ and C using the VS compiler. The disassembly for optimised builds produces two different outputs for both. The C++ code is slower by about 5%. The symbolic code sets are almost identical but the number of operations is different after compilation. It appears that the compiler can make more assumptions about the C code than the C++. But this may vary with compilers.
@rationalcoder
7 жыл бұрын
Did you read his comment before replying? Did he reply to his own comment and delete it? Anyways, saying C++ is faster than C is NOT like saying C is faster than assembly; that would only make sense if C++ compiled down to C, which it doesn't. C++ is (almost) a super-set of C, with the C subset being just as fast as regular C (which is the rationale the GCC team gave for moving to C++). At the extreme low levels of optimization in C, you usually require some sort of non standard compiler extensions. At the same level, the same C compilers offer the same extensions to C++ code. Once you are in the world of compiler extensions, you have no more low level access with C than you would if you had used C++. A simple proof is that you can drop into assembly from both languages (given extensions). Also, any difference you see between compiled output between C programs compiled with a C vs C++ compiler are likely due to your compiler making a mistake, or your not being aware some clause in the C++ standard. That isn't to say that C doesn't have its place. C still dominates in binary size, provides us with a standard ABI, and is easier to implement a parser for.
@HaraldAchitz
8 жыл бұрын
great talk, and finally a talk I do not need to watch in 1.5 x speed since it is already in the right tempo!
@neonz2712
6 жыл бұрын
Someone in the crowd was complaining about him talking too fast, but 98% of these presentations are so slow that by the half way point you're begging for them to get to the point.
@kayakMike1000
3 күн бұрын
In a tragic accident during a conference recently, Bartoscz was tryning to explain something quickly and his lower jaw burst into flames after it broke the speed of sound. He is critical condition but scientists are currently attempting to reberse engineer his ability to speak so quickly.
@Emtron_Technologies
7 жыл бұрын
Excellent. practically implemented in Tiny13. This Guy is Awesome with his talking speed.
@eng.eduardo.gsousa
6 жыл бұрын
Good approach! Almost all time I've been listen C is faster than C++, mainly in embedded applications. But this Sir. clearly shows if we code correctly, the performance using C++ is better than using C. I'm surprised!
@charlesd4572
5 жыл бұрын
C++ is not faster than C. You code the compiler not the machine. It is the compiler that produces faster code - he makes no effort to explain this point. It's like saying C is faster than assembly because of the automated optimisation. A good assembly programmer given enough time will always outperform a compiler the same way a good C programmer will out perform a C++ compiler. Case in point in the video, he uses templates judiciously then doesn't afford his C code the same care when using macros. It's a loaded test.
@G33KN3rd
5 жыл бұрын
you _would_ be right except this guy's C code is garbage.
@ayoaloko1453
6 жыл бұрын
watched at 2x
@arkadiuszwadowski7993
5 жыл бұрын
I think there is one thing missed in these all comparisons... RAM usage. How much bigger are C++ specific static sections placed in RAM not in FLASH. I know it is most applicable in STM32/AVR uc mentioned in presentation but map file is always something we should worry about :)
@Voltra_
2 жыл бұрын
Finally, a talk with excellent speed
@kayakMike1000
3 күн бұрын
First example is compiler output, not language.
@kiiikoooPT
8 жыл бұрын
I'm an amateur newbie programmer, but that question about compile time, well for me I think is better to have a big compile time but a better output program, cause when it is finish you will no need to compile again, and your program will have better performance right?
@justinbassett8229
7 жыл бұрын
What you want is actually really low compile time for development so that it is easier to code and debug your code. Then, when you are ready to release your project, it's fine to take a long time to compile so hat you can have the highest performance code. The trend nowadays is that developer time is more valuable than the final program performance, so people tend to gravitate towards lower compile time, hence the prevalence of Python, Ruby, etc.
@kiiikoooPT
7 жыл бұрын
yes, the last compile is what i mean...
@fw3mbedded598
7 ай бұрын
But what about the RAM usage ? although program size shrinks but SRAM is very limited in MCUs . I am eager to know C++ performance on that part . Will be thankful if anyone explains !
@mc4ndr3
3 жыл бұрын
Have handrolled not null types been completely superceded by std::optional, & ref, && rvalues since this fine talk was presented?
@rpgamer1002
8 жыл бұрын
replace the firt for loop in the C code by a classic memset and the C version becomes way faster than the C++ version ;)
@rahulsrma26
7 жыл бұрын
memset will only take a char value to fill. which will work in this example but cannot be used for general purpose.
@rpgamer1002
7 жыл бұрын
Rahul Sharma A char is a byte basically.
@rahulsrma26
7 жыл бұрын
Correct. What I meant is that "memset" cannot be used to set value 3 to an int array or anything which is not 1 byte. You are right memset will work here but then you can also use it in c++ also.
@DanielMonteiroNit
6 жыл бұрын
memset it with 0x3030303, 4 bytes-a-time?
@jjurksztowicz
8 жыл бұрын
Very good talk.
@cathaldillon7493
8 жыл бұрын
Szurgpt gives an excellent talk but IMHO the cases he presents seem quite contrived. In relation to binary size: Bartosz makes the case early on that templates need to be used with care as they can have a significant impact on executable size. Therefore, it is fair to assume that the example he shows uses templates judiciously and skilfully. However, he appears to then use macros with little care in the corresponding C code. A good C programmer, who is concerned with the size of his/her executable, will not use a macro excessively (in many places) and will use a function instead (symbol insertion) in places where performance is not essential. This is essentially what the C++ compiler does with templates. And that is the point about abstraction, by commonly providing automation it leaves less control in the hands of the programmer to fine-tune his/her code. However, templates do add to compilation time (as stated in the video) and therefore testing time etc. So there is a trade off, the automation reduces development time but may add to fine-tuning/testing time. A good C programmer will do what the C++ compiler is doing with templates but without all the compiler faff. In terms of performance: The early array example does not take advantage of the restrict keyword. Using this in the pointer declaration can improve performance (for most, if not all, modern CPUs) by up to 50% when compiling with optimisation. I accept this will likely increase executable size but then the test was just for performance. So the code used in the test is not exploiting all C code options. The other thing that leaves me somewhat confused about the final example...is that if the only difference between the C++ and C code is the use of templates, and the C++ compiler will in places judge to insert a function call rather than inline, then this should adversely affect performance. Each function call requires additional cycles - at the very least the fetch and execute and the most, fetch, load and then execute depending on the system. The C code is only using macors therefore there is no additional work anywhere. So why, if the only difference is the additional function calls (due to the use of templates) between the compiled C and C++ code, why is the C++ code slightly faster? In theory should it not be slower? Obviously, Bartosz is a much more accomplished programmer/engineer than most (including myself) so I'd be interested to hear why my points are either incorrect or irrelevant.
@paulcosta8297
2 жыл бұрын
The falsehood and disparity of his comparisons reinforced my belief that C is faster than C++ and superior for embedded development.
@wanyxspe123
8 жыл бұрын
goto settings; settings: setVideoSpeed(0.5);
@adrianoldchannel2494
6 жыл бұрын
Lol. Wow. Is he trying to kill C lol. Awesome. That's one way to view that concept but I personally don't mine if it's dead or not because I hardly use it.
@asthegor
8 жыл бұрын
Just a simple question : why not testing on an intel chipset ?
@QuentinUK
8 жыл бұрын
+Dominique Lacombe ARM is much more popular for embedded.
@adrianoldchannel2494
6 жыл бұрын
Wonderful insight. I'm more use to GCC I had clang but I can't find it on my system I'm going to reinitialize the clang again as soon as I locate it.
@alvarohigino
2 жыл бұрын
I already knew what was his side when he put "C++ vs C", naturally everybody would put C first, for obvious reasons.
@nightsusmare8468
3 ай бұрын
polska gurom
@bormalbbs
7 жыл бұрын
6:33
@QuentinUK
8 жыл бұрын
C ⊂ C++.
@shrek22
6 жыл бұрын
C is a subset of C++ for all those that need a refresher here
@mrdarky3377
6 жыл бұрын
Patrick Wright Last time I check, idiomatic C code doesn't compile with c++ compiler.
@G33KN3rd
5 жыл бұрын
@@shrek22 C89 is a subset of C++, but not C99 nor C11.
@darthnegativehunter8659
5 жыл бұрын
he lies. you designed the code differently with awareness that it is different. not that the made the code and then found out it is different
@Mike.Garcia
5 жыл бұрын
Stupid talk... Let's optimise c++ and compare it to c
@Firefly_3161
5 жыл бұрын
C much more better for embedded over C++! No problems with heap and abstraction level is enough in C. So C++ only ++ a problems in embedded! P.S. for a first code example Are you really embedded programmer because using malloc in real robust embedded code strongly forbidden!!! P.P.S. You can use function memset in C instead of cycle!
@G33KN3rd
5 жыл бұрын
2:21 holy fuck, that's the worst C code I've seen... 1. Why are casting `malloc`?! 2. Why are you using `malloc` for an array? 3. Why are you using `unsigned` instead of `size_t`? 4. Why are you manually setting the array to 3 instead of using `memset`? This dude is writing garbage C code and then turns around and says "C++ is better!". 30:22 Instead of using a Macro for generic swapping, you could've used `uint8_t*` and an object size parameter all in a regular function. This guy has no clue how to C.
@mmestari
3 жыл бұрын
If you have constrained time to make a speech and have lot to talk about. Instead of speaking faster, speak at normal speed but cut out all the excess time-wasting memes and audience polls from your speech.
@Firefly_3161
5 жыл бұрын
Guys like this is a reason of NOKIA fails!
@yevhenukrainianer4781
5 жыл бұрын
why ?
@paulcosta8297
2 жыл бұрын
@@yevhenukrainianer4781 Because he makes a false, disparate straw man of C so he can incorrectly compare it to C++ and brainwash you into believing the latter is faster.
@yevhenukrainianer4781
2 жыл бұрын
@@paulcosta8297 why to believe if you always can check. He demonstrates code execution results. Why do you think this way?
@paulcosta8297
2 жыл бұрын
@@yevhenukrainianer4781 He compared shitty C code to extensively optimized C++ code. He did not compare equal C code to equal C++ code.
Пікірлер: 60