Arthur Ulfeldt Arthur Ulfeldt - 5 days ago 4
C Question

We have to use C "for performance reasons"

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 comparing numbers and all I have is thoughts and opinion. 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 :)

EDIT:


  • memory is not a serious constraint

  • portability is not a serious concern

  • this is not a real time system


Answer

"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 in Python (for example) 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.

Comments