9 ms·
It's not like C is any faster or more efficient than Rust or C++ Huh? C is certainly faster than C++. go-faster for you automatically (such as SSO in things l
by codesushi42 7y ago
It's not like C is any faster or more efficient than Rust or C++
Huh? C is certainly faster than C++.
go-faster for you automatically (such as SSO in things like strings, or constexpr for compile-time resolution).
That is a terrible example. You shouldn't be using the STL (i.e. std::string copying) for performance critical sections to begin with.
Very popular microcontrollers like the esp8266 or esp32 also have javascript runtimes.
First, esps are not low end microcontrollers at all. Second, no one uses JS runtimes for performance critical code on microcontrollers (e.g. JS will not give you direct memory access). What an absurd claim.
- pjmlp 7y agoIn what benchmarks?!?
- codesushi42 7y agoVirtual functions, runtime type information, STL, larger executable code size, etc... Memory footprint will be smaller on C without using C++ abstractions. Which is important for embedded systems.
- pjmlp 7y agoYou mean like a Commodore 64? https://youtu.be/zBkNBP00wJE https://youtu.be/zBkNBP00wJE
- codesushi42 7y agoYawn. Yes. But even C was considered too slow for something like a Motorola 68000 back in the day. Of course it's possible. Besides, C++ can be just as performant if you ignore a huge proportion of its language features and abstractions, but what's the point then? Just use C. And this is precisely why embedded engineers do so.
- pjmlp 7y agoThe point is that C will never have proper arrays, strings, bounds checking, real constants instead of magic defines, compile time programming, modules.
- codesushi42 7y agoYet somehow it has stayed relevant for more than 45 years. Go figure.
- pjmlp 7y agoOne cannot teach new tricks to old dogs. What has made relevant was the rise of FOSS UNIX clones and the GNU guidelines for using C. All major desktop OSes were already on the path of adopting C++ frameworks. BeOS, Windows, OS/2, Mac OS. Thankfully C has been shown the door on Apple, Google, Microsoft, Sony, Nintendo and ARM platforms. Others will follow. FOSS UNIX clones and old time embedded developers are the only ones keeping C relevant.
- codesushi42 7y agoAgain, yawn. Now you are conflating embedded systems with other things. And resorting to ad hominem attacks assuming that all C programmers must be old, tired dummies. Pathetic. Heard it all before, many times. C will be just fine whether you like it or not. I also heard there's a new JavaScript framework out. Go fetch.
- pjmlp 7y agoFirst of all, the only place worthy of JavaScript is the browser. Secondly, apparently you are talking about PIC class systems as embedded, given that even a lonely ESP32 has C++ SDK support. Thirdly, AUTOSAR now advises C++14 as certification language. Do you read Embedded Magazine? Most C proud devs are using C89 alongside proprietary language extensions for their target boards + Assembly, and very resistant to any kind of improvements, not even using unit tests or static analysis tools. Old dogs indeed, I bet that until 2030 the new C++ generations will take over the remaining holdouts.
- clappski 7y agoProbably the most important C++ ideal is that you don’t pay for what you don’t use, and you _still_ get a more expressive language than C if you don’t use those features. Your cons: - Virtual functions. Don’t use them if you don’t want to incur an extra indirection. - STL. Don’t use it if you don’t want to. - Large binary size. Don’t spin up hundreds of template instances, problem solved. - No RTTI? Literally a compiler switch away. Some pros: - constexpr - true type safe generic programming (at the cost of code size if you get crazy with it and like TMP) - type safe no-overhead containers (std::array, std::tuple) - RAII ownership semantics (I.e. std::unique_ptr) - Can still emit a C ABI - Multi-paradigm at a language level, rather than procedural with other paradigms bolted on ad-hoc The reason C++ (IMHO) is always a better choice than C is that if you don’t want to incur the cost of feature X, drop down to how you would do it in C and it works exactly the same and you can still use the zero-cost C++ features that will never land in C.
- codesushi42 7y agoI would agree with this assessment in most cases. The problem is it's hard to determine which language features perform worse than C. But usually the cost of being wrong is low or inconsequential for modern hardware. But it is not true for embedded systems. And the industry disagrees too, and continues to use C because of this.
- kllrnohj 7y ago> But it is not true for embedded systems. And the industry disagrees too, and continues to use C because of this. What resource constrained embedded systems even exist? Fucking lightbulbs run JavaScript these days. SmartCards have been running Java for 20 years. What is the actual market you're so up in arms about that you think is choosing C on technical merits instead of purely inertia? What is this "performance constrained embedded" market to you?
- codesushi42 7y agoWhat is this "performance constrained embedded" market to you? The very definition of embedded systems? I would say it is more much likely the many folks who work on embedded systems in C are right and do so with technical merit. And it is much more likely that it is you who is wrong. Which is quite clear as someone who seems to advocate using JS on embedded hardware for serious tasks. A detail that is seriously amusing in its own right.
- kllrnohj 7y ago> Huh? C is certainly faster than C++. It literally isn't. Quite often the reverse is true, as C++ gives you better tools for compile-time optimizations. > That is a terrible example. You shouldn't be using the STL (i.e. std::string copying) for performance critical sections to begin with. I think you're confusing the example with a recommendation to use the STL? std::string is just an example of SSO. The concept is generally applicable and used in more places than just the STL. Although "You shouldn't be using the STL for performance critical sections to begin with." is also complete fucking bullshit anyway. There's nothing wrong with the performance of eg std::array. Or unique_ptr. Or vector. Or a variety of other things in the STL. You're not outperforming any of those with raw C. It's not 2003 anymore so stop acting like it.
- codesushi42 7y agoIt is 2019 and even game programmers still avoid STL for performance reasons. And optimization is taken to another level from that on embedded systems. I hate to remind you again, but it is 2019 and C is still very relevant on embedded systems. And Javascript, not so much. Snicker
- pjmlp 7y agoSurely not the same game programmers that use Unreal with its C++ GC.
- codesushi42 7y agoWhat does that have to do with anything? Yes, those same game programmers avoid STL. No one is advocating replacing C++ with C on capable hardware, troll.
- kllrnohj 7y ago> It is 2019 and even game programmers still avoid STL for performance reasons. No they don't. They avoid parts of the STL. GDC round-table as far back as 2001 had 40% of shipping games using the STL: http://www.tantalon.com/pete/gdc01_round_table_report.htm http://www.tantalon.com/pete/gdc01_round_table_report.htm Many of the containers in the STL have performance problems. Yes avoid those (and avoid the god-awful iostream). But large chunks of the STL have no performance issues at all, and re-inventing it is just a waste of your time. Games don't avoid things like std::vector for performance issues, they use their own thing because they want even more features.