23

In this age of many languages, there seems to be a great language for just about every task and I find myself professionally struggling against a mantra of "nothing but C is fast", where fast is really intended to mean "fast enough". I work with very rational open-minded people, who like to compare numbers, and all I have are thoughts and opinions. Could you help me find my way past subjective opinions and into the "real world"?

Would you help me find research as to what if any other languages could be used for embedded and (Linux) systems programming? I very well could be pushing a false hypothesis and would greatly appreciate research to show me this. Could you please link or include good numbers so as to help keep the "that's just his/her opinion" comments to a minimum.

So these are my particular requirements

  • memory is not a serious constraint
  • portability is not a serious concern
  • this is not a real time system
nbro
  • 15,395
  • 32
  • 113
  • 196
Arthur Ulfeldt
  • 90,827
  • 27
  • 201
  • 284
  • 2
    It's going to be hard to find numbers that prove something that is actually false. – Otávio Décio Aug 03 '09 at 18:02
  • Premature optimization is the root of all evil: I've successfuly written embedded software in Python. In the end you have to balance the cost of writing in a lower-level language like C vs the benefit of RAD in a higher level language (and the cost in terms of performance). – jkp Aug 03 '09 at 18:07
  • 15
    would be cautious about the premature optimization argument. If processing power is limited, and a certain amount of work needs to get done in real-time or near real-time, and you choose a language that requires more processing power for the work than you have, you are royally screwed, because you now have to start over with a capable language. More info at http://weblogs.mozillazine.org/roc/archives/2005/11/immature_optimization.html – Robert Harvey Aug 03 '09 at 18:24
  • If memory, portability, and pauses (due to GC) are not an issue, then what are the reasons your coworkers give for wanting to use C? – Nosredna Aug 03 '09 at 22:22
  • Your question is too vague and unspecific. What are your embedded systems doing? – starblue Aug 04 '09 at 09:01
  • In general, a computationally intensive application will be AT LEAST 2X slower if you use anything other than C (unless you're crazy enough to write it in assembler). – Beep beep Aug 04 '09 at 20:12
  • 1
    Question is a little rambling in it's grammar and content. – Mark Rogers Jan 15 '10 at 19:36
  • 1
    A well written VB program can outperform a badly written C program. It's not the language that's fast (I could write a C compiler that generated horriblly slow code), it's how you use the language. – Skizz Mar 16 '10 at 10:51
  • 1
    "Premature optimization is the root of all evil" yet there is a fine line between premature optimization and premature pessimization. The latter should be avoided along with the former. Trying to write a raytracer on an embedded system and choosing Python, for instance, is already rather pessimistic. It's unrealistic that one can ever achieve such goals using an interpreter. – stinky472 Jun 27 '10 at 07:03
  • "In general, a computationally intensive application will be AT LEAST 2X slower if you use anything other than C" ... unless it's C++, then it can be ten times faster (ex: qsort vs std::sort, string processing, etc.) merely because it's easier to write efficient code. That said, in reality, a lot of less experienced C++ programmers don't pay attention to efficiency and write things 10 times slower than C because they carelessly pessimize their results (ex: deep copying data unnecessarily) and don't profile their code. – stinky472 Jun 27 '10 at 07:05
  • Look into [MirageOS](https://mirage.io/) if you want an example – Basile Starynkevitch Jan 08 '16 at 15:02

19 Answers19

49

In my experience, using C for embedded and systems programming isn't necessarily a performance issue - it's often a portability issue. C tends to be the most portable, well supported language on just about every platform, especially on embedded systems platforms.

If you wish to use something else in an embedded system, it's often a matter of figuring out what options are available, then determining whether the performance, memory consumption, library support, etc, are "good enough" for your situation.

Reed Copsey
  • 554,122
  • 78
  • 1,158
  • 1,373
  • 1
    Indeed. Embedded software tends to be written in C because that's how it's been done for years, and so embedded software engineers are more likely to be proficient in C than any other language. Accordingly, compiler producers are going to go for the language(s) which sell the best, namely C and possibly C++. – Steve Melnikoff Aug 03 '09 at 18:12
  • 1
    Of course, Python is written in C, as are many interpreted tools. With a little work you can use Python on many platforms. – Christopher Aug 03 '09 at 18:19
  • 3
    Yeah - Python can be. I've even used Lua (since it's pretty tiny in terms of overhead). It's the memory overhead and library support that can be an issue with things like pythong. – Reed Copsey Aug 03 '09 at 18:20
  • 5
    Yep - I agree with this entirely. At my former employer, there was of course a cultural ethos that was biased against anything other than C (and assembler), but the bottom line is that there are exceedingly few professional-grade toolsets for embedded systems that support anything but C. You *might* find toolset support for C++, and in the extremely rare case, Java. There are some vertically-stacked niche platforms for other languages (e.g., Erlang), but those are all but impossible to sell to management, particularly for existing systems. – Ben Collins Aug 03 '09 at 18:23
  • 1
    True dat -- if performance were your primary concern, then why stop at C? Write a first pass in C (compilers are pretty good, so that's a good starting point), and then go over the assembly by hand. Many systems have efficiency tricks you can do which aren't generally supported by the compiler. – Ken Aug 03 '09 at 18:26
  • @Ben Collins - GreenHills compiler has excellent support for C and C++, but it's expensive as rip. It is basically the Visual Studio of the embedded world in some aspects as far as powerful tools capability. – Jay Atkinson Aug 07 '09 at 02:38
  • "rue dat -- if performance were your primary concern, then why stop at C? Write a first pass in C (compilers are pretty good, so that's a good starting point), and then go over the assembly by hand." Generally the compiler will do a much better job at optimizing the code than you are, so writing assembly by hand does not necessary make the program faster... – Yunfei Chen Feb 21 '21 at 23:39
  • @Christopher most of the time I find Python to be too slow to use on most platform.... – Yunfei Chen Feb 21 '21 at 23:40
29

"Nothing but C is fast [enough]" is an early optimisation and wrong for all the reasons that early optimisations are wrong. If your system has enough complexity that something other than C is desirable, then there will be parts of the system that must be "fast enough" and parts with lighter constraints. If writing your code, for example, in Python will get the project finished faster, with fewer bugs, then you can follow up with some C or assembly code to speed up the time-critical parts.

Even if it turns out that the entire code must be written in C or assembly to meet the performance requirements, prototyping in a language like Python can have real benefits. You can take your working Python prototype and gradually replace parts with C code until you reach the necessary performance.

So, use the tools that let you get the development work done most correctly and most quickly, then use real data to determine where you need to optimize. It could be that C is the most appropriate tool to start with sometimes, but certainly not always, even in embedded systems.

nbro
  • 15,395
  • 32
  • 113
  • 196
Neil
  • 2,378
  • 1
  • 20
  • 28
  • 1
    Better still, prototype with English(text), flowcharts, data structure diagrams, etc, and then write the app once. Prototyping in any language knowing it will fail to meet your requirements is a really bad idea. Personally, I find C/C++ flow together very nicely and draw on the same skill set, while Java, Python etc. create a lot of learning interference because they are just different enough that C will punish you when you come back to it. "Football players who practice running thru tires get good at running thru tires". –  Jan 14 '14 at 06:38
  • " in Python will get the project finished faster" It will also run 100x slower and most likely become so resource consuming that it makes the programs glitchy and laggy to run on most run-time applications. Python is a no-no if you care about performance at all, and even then it is only a good option if you are not using it for production code, if you want to use python for production code, include at least a C framework.... – Yunfei Chen Feb 21 '21 at 23:32
  • "ou can take your working Python prototype and gradually replace parts with C code until you reach the necessary performance." Using a mixed language format generally makes code harder to debug not easier. And most of my collegues would complain if I asked them to maintain C code with pieces of Python code popping up in unexpected places... – Yunfei Chen Feb 21 '21 at 23:34
  • "It could be that C is the most appropriate tool to start with sometimes, but certainly not always, even in embedded systems." In embedded systems, there are 4 languages that can meet the performance requirements and two of them are fairly new namely, C , C++, Rust, and Go lang. This is of course ignoring ancient languages like Assembly, Machine language, Fortran, and Lisp.. – Yunfei Chen Feb 21 '21 at 23:37
18

Using C for embedded systems has got some very good reasons, of which "performance" is only one of the minor. Embedded is very close to the hardware, you need manual memory adressing to communicate with hardware. All the APIs and SDKs are available for C mostly.

There are only a few platforms that can run a VM for Java or Mono which is partially due to the performance implications but also due to expensive implementation costs.

Johannes Rudolph
  • 35,298
  • 14
  • 114
  • 172
14

Apart from performance, there is another consideration: you'll most likely be dealing with low-level APIs that were designed to be used in C or C++.

If you cannot use some SDK, you'll only get yourself in trouble instead of saving time with developing using a higher level language. At the very least, you'll end up redoing a bunch of function declarations and constant definitions.

nbro
  • 15,395
  • 32
  • 113
  • 196
Thorarin
  • 47,289
  • 11
  • 75
  • 111
9

For C:

  • C is often the only language that is supported by compilers for a processors.
  • Most of the libraries and example code is probability also in C.
  • Most embedded developers have years of C experience but very little experience in anything else.
  • Allows direct hardware interfacing and manual memory management.
  • Easy integration with assembly language.

C is going to be around for many years to come. In embedded development its a monopoly that smothers any attempt at change. A language that need a VM like Java or Lua is never going to go mainstream in the embedded environment. A compiled language might stand a chance if it provide compelling new features over C.

Gerhard
  • 6,850
  • 8
  • 51
  • 81
  • eLua is quite used in the wilderness of embedded devices though. – Kamiccolo Jan 08 '16 at 15:08
  • Databases have got ACID properties, FAT has been replaced by fail-safe ext4, HFS+ and NTFS, and similarly C must be phased out. Maybe not completely, just like FAT being always nearby, but not in sensitive places. Writing in C postpones progress. – OCTAGRAM Nov 23 '16 at 06:02
  • @OCTAGRAM: Why the downvote? ext4 was written in C. Writing in C it would seem from your example to have brought progress. Yes, C is not the right answer everywhere but for the embedded and OS environment it is a good match. – Gerhard Nov 23 '16 at 08:43
  • C must be compared to Ada, Modula-2, Pascal in the first place. You mention Java and Lua, and that is a strawman fallacy, quite dangerous. Wrt compiler availability, Ada and SPARK are available for AVR, MIPS and ARM, covering most embedded needs. The progress is ext4 itself, but its implementation language is a tragedy. – OCTAGRAM Nov 24 '16 at 01:33
8

There are several benchmarks on the web between different languages. Most of them you will find a C or C++ implementation at the top as they give you more control to really optimize things.

Example: The Computer Language Benchmarks Game.

nbro
  • 15,395
  • 32
  • 113
  • 196
Peter Olsson
  • 1,302
  • 3
  • 13
  • 19
7

It's hard to argue against C (or other procedure languages like Pascal, Modula-2, Ada) and assembly for embedded. There is a large history of success with those languages. Generally, you want to remove the risk of the unknown. Trying to use anything other than C or assembly, in my opinion, is an unknown. Having said that, there's nothing wrong with a mixed model where you use one of the Schemes that go to C, or Python or Lua or JavaScript as a scripting language.

What you want is the ability to quickly and easily go to C when you have to.

If you convince the team to go with something that is unproven to them, the project is your cookie. If it crumbles, it'll likely be seen as your fault.

Nosredna
  • 83,000
  • 15
  • 95
  • 122
6

There are situations where you need real-time performance, especially in embedded systems. You also have severe memory constraints. A language like C gives you greater control over execution time and execution space.

So, depending on what you are doing, C may very well be "better" or more appropriate.

Check out the following articles

nbro
  • 15,395
  • 32
  • 113
  • 196
Christopher
  • 8,815
  • 2
  • 32
  • 41
  • 1
    www.pythononachip.org is a project that runs the PyMite VM on microcontrollers with no OS, no MMU and as little as 8 KB of RAM. – dwhall Aug 03 '09 at 22:15
6

Ada is a high-level programming language that was designed for embedded systems and mission critical systems.

It is a fast secure language that has data checking built in everywhere. It is what the auto pilots in airplanes are programmed in.

At this link you have a comparison between Ada and C.

nbro
  • 15,395
  • 32
  • 113
  • 196
WolfmanDragon
  • 7,851
  • 14
  • 49
  • 61
  • 3
    I have used ADA in the past and would love to use it now, but I cannot find a version that will produce code to run in my 2K ROM/256 byte RAM environment. – uɐɪ Aug 04 '09 at 07:51
6

This article (by Michael Barr) talks about the use of C, C++, assembler and other languages in embedded systems, and includes a graph showing the relative usage of each.

And here's another article, fittingly entitled, Poor reasons for rejecting C++.

nbro
  • 15,395
  • 32
  • 113
  • 196
Steve Melnikoff
  • 2,620
  • 1
  • 22
  • 24
4

C is ubiquitous, available for almost any architecture, usually from day-one of a processor's availability. C++ is a close second. If your system can support C++ and you have the necessary expertise, use it in preference to C - it is all that C is, and more, so there are few reasons for not using it.

C++ is a larger language, and there are constructs and techniques supported that may consume resources or behave in unacceptable ways in an embedded system, but that is not a reason not to use the language, but rather how to use it appropriately.

Java and C# (on Micro.Net or WinCE) may be viable alternatives for non-real-time.

Clifford
  • 88,407
  • 13
  • 85
  • 165
3

You may want to look at the D programming language. It could use some performance tuning, as there are some areas Python can outperform it. I can't really point you to benchmarking comparisons since haven't been keeping a list, but as pointed to by Peter Olsson, Benchmarks & Language Implementations has D Digital Mars.

You will probably also want to look at these lovely questions:

nbro
  • 15,395
  • 32
  • 113
  • 196
he_the_great
  • 6,554
  • 2
  • 30
  • 28
2

I'm not really a systems/embedded programmer, but it seems to me that embedded programs generally need deterministic performance - that immediately rules out many garbage collected languages, because they are not deterministic in general. However, there has been work on deterministic garbage collection (for example, Metronome for Java: http://www.ibm.com/developerworks/java/library/j-rtj4/index.html)

The issue is one of constraints - do the languages/runtimes meet the deterministic, memory usage, etc requirements.

Nathan
  • 10,593
  • 10
  • 63
  • 87
  • Removing the GC doesn't fix the problem, malloc/free are non-deterministic. The D programming language allows you to disable the GC so it doesn't run during critical code. – he_the_great Aug 03 '09 at 21:36
  • 1
    Software for the lower end of embedded processors tends not to use malloc/free, but it is likely to use interrupts triggered by external events, which is unpredictable, and hence non-deterministic - regardless of the language used. – Steve Melnikoff Aug 04 '09 at 15:41
  • typically, malloc/free are disallowed in deterministic systems(or they are rewritten). @Steve: you can create deterministic interrupt handling, giving you bounds on time. – Paul Nathan Aug 04 '09 at 18:30
2

C really is your best choice.

There is a difference for writing portable C code and getting too deep into the ghee whiz features of a specific compiler or corner cases of the language (all of which should be avoided). But portability across compilers and compiler versions. The number of employees that will be capable of developing for or maintaining the code. The compilers are going to have an easier time with it and produce better, cleaner, and more reliable code.

C is not going anywhere, with all the new languages being designed to fix the flaws in all the prior languages. C, with all the flaws these new languages are trying to fix, still stands strong.

nbro
  • 15,395
  • 32
  • 113
  • 196
old_timer
  • 69,149
  • 8
  • 89
  • 168
1

Depending on the embedded platform, if memory constraints are an issue, you'll most likely need to use a non-garbage collected programming language.

C in this respect is likely the most well-known by the team and the most widely supported with available libraries and tools.

nbro
  • 15,395
  • 32
  • 113
  • 196
Sufian
  • 8,627
  • 4
  • 22
  • 24
1

Here are a couple articles that compare C# to C++ :

http://systematicgaming.wordpress.com/2009/01/03/performance-c-vs-c/

http://journal.stuffwithstuff.com/2009/01/03/debunking-c-vs-c-performance/

Not exactly what you asked for as it doesn't have a focus on embedded C programming. But it's interesting nonetheless. The first one demonstrates the performance of C++ and the benefits of using "unsafe" code for processor intensive tasks. The second one somewhat debunks the first one and shows that if you write the C# code a little differently then the performance is almost the same.

So I will say that C or C++ can be the clear winner in terms of performance in many cases. But often times the margin is slim. Whether to use C or not is another topic altogether. In my opinion it really should depend on the task at hand. But in embedded systems you often don't have much of a choice.

Steve Wortham
  • 21,740
  • 5
  • 68
  • 90
  • or you could say "shows that if you write the C# code a little differently then the performance is still slower". Not as slow as before, but nevertheless slower. Now, on my 3xcore, 4GB desktop PC that may not mean I'll ever notice a difference... but on a 10Mhz embedded CPU with 64Mb RAM the difference is likely to be tremendously significant. – gbjbaanb Aug 04 '09 at 18:32
  • Actually if you read that 2nd article he wasn't able to determine which was faster for this particular task (they were that close). But I agree -- C# has a lot more overhead and will not be nearly as impressive in low-powered embedded systems. – Steve Wortham Aug 04 '09 at 19:02
1

A couple people have mentioned Lua. People I know who have worked with embedded systems have said Lua is useful, but it's not really its own language per se but more of a library that can be embedded in C. It is targetted towards use in embedded systems and generally you'll want to call Lua code from C. But pure C makes for simpler (though not necessarily easier) maintenance, since everyone knows it.

Brian
  • 25,523
  • 18
  • 82
  • 173
0

The truth is - not always.

It seems .NET runtime (but any other runtime can be taken as an example) imposes several MBs of runtime overhead. If this is all you have (in RAM), then you are out of luck. JavaME seems to be more compact, but it still all depends on resources you have at your disposal.

nbro
  • 15,395
  • 32
  • 113
  • 196
EFraim
  • 12,811
  • 4
  • 46
  • 62
-2

C compilers are much faster even on desktop systems, because of how few langage features there are compared to C++, so I'd imagine the difference is non-trivial on embedded systems. This translates to faster iteration times, although OTOH you don't have the conveniences of C++ (such as collections) which may slow you down in the long run.

Engineer
  • 8,529
  • 7
  • 65
  • 105