Raspberry Native C and Speed Tests

[ejolson]

Python can not interface to the high-frequency hardware.

It depends on exactly what one means by that.

Python cannot interface to any hardware directly so a Python programmer will call libraries which can be written in C which will be just as fast when executing as C itself is.

Any slowness of Python is in calling the libraries and interpreting the Python bytecode once that library has returned. If most of the time it stays within the C library it can handle things just as fast as C itself can. If it does a lot of calling, returning and executing Python it will be slower.

A Python program could build up a bitmap for a GPIO connected LCD and than blat that out. If it does that by bit-banging each GPIO signal change in Python then it will be slow, though surprisingly quick for the amount of bit-banging it's doing. If it bit-bangs bytes via a Python SPI library it will be faster, if it passes the entire bitmap to a C library that can blat it out as quickly as any C program could.

It's a bit like 3B+ wired ethernet; capable of 1GBe but not sustained, only in bursts.

So it's not that it can't interface to high-frequency devices; it depends on what that high-frequency hardware demands.

As far as I can tell, everyone agrees.

What I still find amazing is how well C works for hardware device drivers that assembly is seldom needed. Most of Linux is device drivers and most of those device drivers are written in portable C which can be compiled for many different processor architectures.

[achrn]

C = 125 MHz
Python = 70Khz

Hence C best for use in professionals.

How I choose the programming language :

1.Fastest
2. Use little system resource

Actually, I think that's why a hobbyist might choose C. I'd expect actual professionals, driven by a need to earn actual money from their craft, would be much more pragmatic and will factor in 'how much effort will this take me' to the decision.

Personally, I despise python (whoever thought white-space should have meaning, and that different whitespace shall have different meaning wants their head examining). However, even though I hate myself every time I do it, I still use Python, because it will often get the job done more quickly. If it really doesn't matter whether the computer gets the answer in 0.001 seconds or 0.01 seconds, and it does matter whether the code is ready to run today rather than in nine days time, then plenty of options beat 'native C'.

Get it done today and get paid and move on to the next thing is likely to be more important than whether it uses a bit less system resource, whether that's getting paid directly if you're a contractor on effectively piecework, or an employee whose annual review some time in the future will depend upon some more arcane measure of your productivity or performance.

Personally, I'd rather hack it together in Perl, anyway.

[jahboater]

I'd expect actual professionals, driven by a need to earn actual money from their craft, would be much more pragmatic and will factor in 'how much effort will this take me' to the decision.

Throughout my career as a software engineer, C was used 99% of the time.
It was not chosen for its high speed. It was always simply the de-facto choice and never discussed.

Time to market is improved when all the programmers in the team are fluent in the chosen language.
Yes, language X might well be more productive, but its not always worth taking the time for everyone to learn it, when there is an alternative.

I always liked C perhaps because you never have to "fight" the language to get difficult things done. Even nowadays with much more stringent checking, its still easy to be precise when dealing with external hardware for example.
You have exact control and choice over how data is stored and used; in many languages its not at all clear at all how a simple intreger is stored.

There is vast precedent for writing large scale systems software in C (operating systems, compilers, you name it).

[jahboater]

What I still find amazing is how well C works for hardware device drivers that assembly is seldom needed. Most of Linux is device drivers and most of those device drivers are written in portable C which can be compiled for many different processor architectures.

Yes, indeed, and that was exactly the reason it was created - to rewrite an operating system that was written in assembler into a portable high level language. Most languages are not designed with that in mind.

[timrowledge]

C is basically a jumped up PDP-8 assembler with delusions of grandeur. As it happens,that is a quite useful thing to use for a lot of purposes.
It’s horribly inefficient as a way of describing complex problems *unless* it is the only way you have to deal with it; then it’s a case of doing the best you can.
When you have better tools you should use them.

[ejolson]

C is basically a jumped up PDP-8 assembler with delusions of grandeur. As it happens,that is a quite useful thing to use for a lot of purposes.
It’s horribly inefficient as a way of describing complex problems *unless* it is the only way you have to deal with it; then it’s a case of doing the best you can.
When you have better tools you should use them.

The DEC PDP-8 is a simple accumulator architecture without a hardware stack which is a very difficult match for the C programming language. Did you mean the PDP-11 by any chance?

[achrn]

I'd expect actual professionals, driven by a need to earn actual money from their craft, would be much more pragmatic and will factor in 'how much effort will this take me' to the decision.

Throughout my career as a software engineer, C was used 99% of the time.
It was not chosen for its high speed. It was always simply the de-facto choice and never discussed.

Time to market is improved when all the programmers in the team are fluent in the chosen language.
Yes, language X might well be more productive, but its not always worth taking the time for everyone to learn it, when there is an alternative.

I think that's a different case to the case under discussion - in your scenario it's not the lone programmer that chooses what language to use.

I don't believe it is (any more?) the case that 99% of code produced is in 'native C', which in this thread seems to be being read as C core language plus only standard libraries. I'm not sure 99% of code was ever written on just C and the standard library - doing every gui from scratch every time...?

[jahboater]

C is basically a jumped up PDP-8 assembler with delusions of grandeur.

When did you last use C for real projects?

Please take an unbiased look at C18 or C2x.

[Heater]

C is basically a jumped up PDP-8 assembler with delusions of grandeur.

When did you last use C for real projects?

Please take an unbiased look at C18 or C2x.

I really don't like C being described as any kind of assembler either. It's just wrong.

The thing is that there are hundreds of machine architectures, and consequently 100's of assembly languages. Assembly language programs written for one machine architecture will not run on another. There is no portability.

A high level language like C abstracts away all those architectural differences as much as possible and allows code to be easily moved from machine architecture to machine architecture. Portability is a main objective here. Especially in the case of C, it was created to make Unix portable.

That abstraction and portability is a fundamental and very significant language distinction. Ergo, it's just wrong to describe C as an assembler.

Now, one might view C as a very low level language compared to many. Which is true. Even compared to languages that came before it. One might use "assembler" as a derogatory term in that respect. But I feel that is misplaced derision. C is gloriously simple, it has just the features it needed to get the job it was designed for done. It performed it's duty admirably and continues to do so.

I've looked at C18. I was happy to find it is minimally changed from the C we know and love. The big mistake along the way was variable length arrays, a feature now deprecated after they realized their mistake.

[ejolson]

C is basically a jumped up PDP-8 assembler with delusions of grandeur.

When did you last use C for real projects?

Please take an unbiased look at C18 or C2x.

I really don't like C being described as any kind of assembler either. It's just wrong.

The thing is that there are hundreds of machine architectures, and consequently 100's of assembly languages. Assembly language programs written for one machine architecture will not run on another. There is no portability.

A high level language like C abstracts away all those architectural differences as much as possible and allows code to be easily moved from machine architecture to machine architecture. Portability is a main objective here. Especially in the case of C, it was created to make Unix portable.

That abstraction and portability is a fundamental and very significant language distinction. Ergo, it's just wrong to describe C as an assembler.

Now, one might view C as a very low level language compared to many. Which is true. Even compared to languages that came before it. One might use "assembler" as a derogatory term in that respect. But I feel that is misplaced derision. C is gloriously simple, it has just the features it needed to get the job it was designed for done. It performed it's duty admirably and continues to do so.

I've looked at C18. I was happy to find it is minimally changed from the C we know and love. The big mistake along the way was variable length arrays, a feature now deprecated after they realized their mistake.

It's not clear to me that variable length arrays were a mistake nor that the people guiding the C18 standard are wiser than before, just different. As indicated by complex numbers and variable-length arrays, previous committees included people using C for scientific computing. Removing such things now appears to reflect a dominance by people in industry using C for IoT and device drivers. In my opinion, adding, removing and changing features in a language standard results in no standard at all.

Although C is notable for its use in the original Unix R7 kernel, it was designed as a general programming language by its creators. That is why the Kernighan and Ritchie C compiler had full support for the PDP-11 hardware floating-point unit. That is why Unix user space, including the C compiler itself, was also written in C.

Times have changed. However, in the race to the bottom, it is worth remembering the design goals as stated in the preface of The C Programming Language:

C is a general-purpose programming language which features economy of expression, modern control flow and data structures, and a rich set of operators. C is not a "very high level" language, nor a "big" one, and is not specialized to any particular area of application. But its absence of restrictions and its generality make it more convenient and effective for many tasks than supposedly more powerful languages.

Perhaps as a result of the mandate to use the right language for the right task often proclaimed from the highest ivory towers, we now enjoy a multitude of domain-specific programming languages. At the same time, I believe there is an ever increasing need for the general-purpose programming language that C was intended to be.

[jahboater]

The big mistake along the way was variable length arrays, a feature now deprecated after they realized their mistake.

VLA's are not deprecated.

Like complex arithmetic and threading, they are optional.
This was to allow conforming compilers to be implemented on small embedded processors.

The presence of __STDC_NO_VLA__ indicates lack of support, in which case just use alloca().

An important feature of the C standards is that they take considerable care to ensure that the vast amount of existing code will still work.
So (compared to C++ say) new features are introduced slowly and carefully over long periods of time, and nothing is removed.

[ejolson]

The big mistake along the way was variable length arrays, a feature now deprecated after they realized their mistake.

VLA's are not deprecated.

Like complex arithmetic and threading, they are optional.

Thanks for the update. That sounds much more reasonable.

[timrowledge]

C is basically a jumped up PDP-8 assembler with delusions of grandeur.

When did you last use C for real projects?

Please take an unbiased look at C18 or C2x.

Today. And no, not going to happen.

[timrowledge]

The DEC PDP-8 is a simple accumulator architecture without a hardware stack which is a very difficult match for the C programming language. Did you mean the PDP-11 by any chance?

PDP-11? Yeah, quite possibly.

[timrowledge]

I really don't like C being described as any kind of assembler either. It's just wrong.

When one has to manually handle memory, and poke at things with pointers, then it really isn’t much more helpful than bare assembler. I work on dynamic code generators and virtual machine design; I do actually have a bit of experience in using C and ‘real’ assemblers, and generating machine instructions etc. My opinion may not match yours but it is based on a fair bit of experience. It is permissible to disagree.

[Heater]

When one has to manually handle memory, and poke at things with pointers, then it really isn’t much more helpful than bare assembler.

I can sympathize with that point of view. C is, intentionally, a very low level language. Created to do what one can do in assembler, for the most part. It's original reason for being was to be able to rewrite Unix in a portable manner after all.

BUT, my point is: that very portability, being a language independent of machine instruction details, is a huge distinction between it and any assembler. So huge that it is not right to refer to it as a "portable assembler" or whatever. It's a different category entirely.

I would add that the portability C provides is incredibly helpful compared to assembler. Unix would never have become so widespread without it. Nor Linux or Windows or hundreds of other operating systems and countless other programs.

I work on dynamic code generators and virtual machine design; I do actually have a bit of experience in using C and ‘real’ assemblers, and generating machine instructions etc. My opinion may not match yours but it is based on a fair bit of experience.

I too have a lot of experience in writing a lot of assembler. Mostly for embedded systems. And a lot of time writing in C and other HLLs. I have seen the pain and expense of migrating products from assembler to C so that they can live on when their processors become obsolete or it's time to move to something better. For this reason I cannot fathom how C can be described as any kind of assembler. "Portable assembler" is a contradiction in terms.

It is permissible to disagree.

I do like a good disagreement. Although I don't think we disagree much.

[pica200]

C has nothing to do with assembly languages. C is a high level language (and one of the lowest level of high level languages). With assembly you have to write every single instruction yourself and keep the registers in mind. You also have to know the ABI. It's a pain and should not be used unless there is a good reason for it like hardcore optimizations or exception handling. Mostly when C doesn't allow you the control you need anymore.

C allows you to describe with actual words and syntax what the CPU should do. No registers or ABI to worry about. You don't need to describe in very little detail what you want. The compiler will break it down into the pieces of instructions the CPU needs.

You see they are completely different and "portable assembler" is not right.

Personally i don't like the kinds of languages like Java because they teach a false way of how computers work due to being so far away from metal but that's just my opinion.

[jahboater]

I really don't like C being described as any kind of assembler either. It's just wrong.

When one has to manually handle memory, and poke at things with pointers, then it really isn’t much more helpful than bare assembler.

Well, it provides portability, an English like problem orientated syntax, high level optimization, diagnostics (static analysis), strong ISO standards etc.

But then any beginning CS student knows that, and I am sure Tim's comments are tongue-in-cheek.

[hippy]

With assembly you have to write every single instruction yourself and keep the registers in mind.

A professional Assembly programmer will soon create macros and the like to save themselves from having to write every instruction by hand and move from Assembly to Macro Assembly and, in that respect, C can be viewed as the Ultimate Macro Assembler.

I have used the B Knudsen Data (http://www.bknd.com/) C compilers for PICmicros in that way. Others have developed macros which allow C-styled code to be used within the Macro Assembler itself.

That doesn't mean C is an Assembler, but some embedded programmers do use it that way. They are simply representing what would be their Assembler in C language style, rather than in native Assembler because it's convenient, so much easier to knock out, comprehend and debug.

It also offers some degree of portability; change the #include files for register and bit definitions, and the same C-style code will often compile and run on other CPU's in the same family, even others.

[pica200]

With assembly you have to write every single instruction yourself and keep the registers in mind.

A professional Assembly programmer will soon create macros and the like to save themselves from having to write every instruction by hand and move from Assembly to Macro Assembly and, in that respect, C can be viewed as the Ultimate Macro Assembler.

I have used the B Knudsen Data (http://www.bknd.com/) C compilers for PICmicros in that way. Others have developed macros which allow C-styled code to be used within the Macro Assembler itself.

That doesn't mean C is an Assembler, but some embedded programmers do use it that way. They are simply representing what would be their Assembler in C language style, rather than in native Assembler because it's convenient, so much easier to knock out, comprehend and debug.

It also offers some degree of portability; change the #include files for register and bit definitions, and the same C-style code will often compile and run on other CPU's in the same family, even others.

That still requires you to understand the ABI and only hides register allocation. It's not a replacement for proper C and it only does exactly what you tell it to do unlike a compiler which can do some optimizations (i would generally consider this good but it might be bad if you need consistent code or have timing requirements).

Too many macros can do the exact opposite actually and make the code hard to debug and understand especially for others. Building some kind of "meta language" with macros is the exact kind of usage that can get out of hand/messy quickly.

[Heater]

hippy,

It also offers some degree of portability; change the #include files for register and bit definitions, and the same C-style code will often compile and run on other CPU's in the same family, even others.

Only some degree?

That is ignoring the countless architectures that Linux and other operating systems work on. Not to mention tens of thousands of C programs that run with them.

I was once contracted to recreate an old program that consisted of tens of thousands of lines of assembler in C. For the purpose of enabling the product to transition from Intel 8086 to Motorola 68000 where it could be further expanded. No we did not use any funky macros. Nice project, no documentation and few code comments, in Swedish! Later I was called in to port that C code to Power PC for a new generation of hardware and later again to run under Linux on ARM. That code ended up being usable on Windows, Mac and Linux PC's as well, for simulations.

I can safely say C code is very portable. Doing all the above would not have been possible in assembler.

[jahboater]

A modern compiler is not a macro processor!!!!!

[hippy]

hippy,

It also offers some degree of portability; change the #include files for register and bit definitions, and the same C-style code will often compile and run on other CPU's in the same family, even others.

Only some degree?

That is ignoring the countless architectures that Linux and other operating systems work on. Not to mention tens of thousands of C programs that run with them.

I was meaning in the context of using C in the manner of an Ultimate Macro Assembler.

Where code like that below written for one CPU in a family can often be compiled for others in the family merely by changing the #include, without having to have abstraction layers, conditional code or multiple routines to handle the functionality.

Code: Select all

byte GetChar() {
  do { } while PIR1.RCIF == 0;
  return RCREG;
}

A modern compiler is not a macro processor!!!!!

That won't ever stop people using C compilers as if they are, considering it as such for them.

[hippy]

That still requires you to understand the ABI and only hides register allocation. It's not a replacement for proper C and it only does exactly what you tell it to do unlike a compiler which can do some optimizations ...

Well yes; that's exactly how it's used when used as the Ultimate Macro Assembler.

I'm not claiming this is a "replacement for proper C" just describing how some people do use C as the Ultimate Macro Assembler. The people doing that are defining their own ABI so they will understand it, often won't have a fixed ABI, will be far more ad-hoc than that.

The ways things are is very different when looked down at from a C or high-level language programmer's perspective and when looked up at from a low-level Assembly language programmer's perspective. It's very different when dealing with 'a computer' and a very limited microcontroller.

[jamesh]

Do assembler programs get automagically optimised?

That's one reason why C isn't assembler - the compiler can optimise code. Also, it's not targeted at a specific architecture. Being able to poke registers does not mean assembler.

Anyone who says it's just a glorified assembler is simply wrong. Which is fine, you are entitled to be wrong. Just accept that people know you are wrong and you will continue to be wrong. Simples.