Question C, C++ or Assembly ?

Status
Not open for further replies.
Oct 11, 2023
8
0
10
Hi,


very simple question : what is the best language to make the most optimized software possible ?

The idea is to make a full on software, with user interface and everything, that works with the less possible ressources/hardware so something that could be super fluid even on a 20 years old PC basically.

So I was wondering which of the 3 is the best ?

I know Assembly can be used to make very compatible things (example of RollerCoaster Tycoon) and I know C so I know you can control memory which seems to be a good way to control ressources/perfomances, compared to Python for example, but I know C is usually more to create OS so i would say C++ because here i'm trying to create a software.
 
What language do you and/or your team know the best?
Hello,

i only know Python, and a little bit of HTML/CSS and very little of C.

This is a very long term project for something that is not "needed", it's more a personal project so I have time to learn the needed language, which is why I asked the question.
 
Hello,

i only know Python, and a little bit of HTML/CSS and very little of C.

This is a very long term project for something that is not "needed", it's more a personal project so I have time to learn the needed language, which is why I asked the question.
Then it doesn't matter...pick one.
(probably not assembly)

As above, the language is just a tool.
 
Then it doesn't matter...pick one.
(probably not assembly)

As above, the language is just a tool.
Why not assembly ?

Yes i get that it's just a tool but i feel like if you have a precise goal (for me : use the least ressources possible), some are more adapted to reach this goal, which is why I asked my question !

Seems like there is one assembly for Intel, and one for ARM (Apple/Raspberry) so i guess there is no solution to make something VERY ressource efficient like assembly but compatible on everything ?
 
Last edited:
Why not assembly ?

Yes i get that it's just a tool but i feel like if you have a precise goal (for me : use the least ressources possible), some are more adapted to reach this goal, which is why I asked my question !
Because writing a GUI based application in assembly is magnitudes harder than with other languages.

"least resources possible".....that is very much undefined.
Linux, Windows, Apple?
GUI or console based?
What will this unknown thing be doing?
 
Instead of trying to make the "most optimized" software, set requirements for what kind of hardware you want this to run on and how fast it needs to perform first. Then program to that.

If you can't clearly define those two first, then you're going to be endlessly chasing your tail. And no, you can't say "as fast as possible" as a requirement for the second one because it's not empirically testable.

Also keep this close to heart (a quote from Donald Knuth):
The real problem is that programmers have spent far too much time worrying about efficiency in the wrong places and at the wrong times; premature optimization is the root of all evil (or at least most of it) in programming.

Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.

Also what's more important than having your software be fast is having software be correct. Would you rather use a program that's faster, but crashes randomly within a half hour, or one that's slower, but runs forever?
 
Instead of trying to make the "most optimized" software, set requirements for what kind of hardware you want this to run on and how fast it needs to perform first. Then program to that.

If you can't clearly define those two first, then you're going to be endlessly chasing your tail. And no, you can't say "as fast as possible" as a requirement for the second one because it's not empirically testable.

Also keep this close to heart (a quote from Donald Knuth):


Also what's more important than having your software be fast is having software be correct. Would you rather use a program that's faster, but crashes randomly within a half hour, or one that's slower, but runs forever?
Yup. Roughly 95-98% of all projects is getting the design correct. Making sure that all logic has been tested on paper and that everything works as intended. Only the final 2-5% is actually writing the code. And the specific language isn't chosen until everything else is ready.
 
Because writing a GUI based application in assembly is magnitudes harder than with other languages.

"least resources possible".....that is very much undefined.
Linux, Windows, Apple?
GUI or console based?
What will this unknown thing be doing?
This is undefined for now but MacOs or Windows for sure.

GUI.

Basically entering data, it would be a freight forwarder software so no big calculation to do.
 
Instead of trying to make the "most optimized" software, set requirements for what kind of hardware you want this to run on and how fast it needs to perform first. Then program to that.

If you can't clearly define those two first, then you're going to be endlessly chasing your tail. And no, you can't say "as fast as possible" as a requirement for the second one because it's not empirically testable.

Also keep this close to heart (a quote from Donald Knuth):


Also what's more important than having your software be fast is having software be correct. Would you rather use a program that's faster, but crashes randomly within a half hour, or one that's slower, but runs forever?

Yup. Roughly 95-98% of all projects is getting the design correct. Making sure that all logic has been tested on paper and that everything works as intended. Only the final 2-5% is actually writing the code. And the specific language isn't chosen until everything else is ready.
Okay thank you to you both, I will try to get all the "theorical" ready and the get into it.
 
This is undefined for now but MacOs or Windows for sure.

GUI.

Basically entering data, it would be a freight forwarder software so no big calculation to do.
Given better defined requirements, I could probably have something deployed in a week, based on some commonly available platform.

Something like this does not need "OMG!! MOAR OPTIMIZATION!!!"

Also, this is not a "new" thing. What do other companies use?
Buy their prebuilt solution.
 
Professional Software Engineer here: Compilers are good enough at optimizing where your overall design is going to have a much greater impact then any specific lines of code.

Don't bother with assembly; any C/C++ compiler is going to do a better job then you can.

If writing a GUI app, stick with C++ and your choice of windowing software. Try to avoid using any "C-isms" and try and stick to modern C++ best standards and practices.

If writing a console application or anything that doesn't need anything more then the most basic GUI AND you care that much about performance, then you can go straight C. Try and comply with at least C99 coding standards and avoid abusing the API; small performance boosts are what make so many applications unstable bug ridden messes.
 
  • Like
Reactions: kanewolf
Simple answer....
Machine language(aka assembly) written by a competent programmer.

Many years ago, in a previous life, I had to make an app written in cobol run better on a computer that was not very capable. Think some 40 years ago.
The only way was to rewrite in assembly language.
Higher level languages use compilers to change the high level code ultimately into assembly language machine instructions.
These compilers are very good, but not as good as machine language code written by a good programmer. Still, compiled code is going to be much faster than interpreted code like Python.

The downside with lower level languages is maintenance in the future by one who did not write the code in the first place.
 
Professional Software Engineer here: Compilers are good enough at optimizing where your overall design is going to have a much greater impact then any specific lines of code.

Don't bother with assembly; any C/C++ compiler is going to do a better job then you can.

If writing a GUI app, stick with C++ and your choice of windowing software. Try to avoid using any "C-isms" and try and stick to modern C++ best standards and practices.

If writing a console application or anything that doesn't need anything more then the most basic GUI AND you care that much about performance, then you can go straight C. Try and comply with at least C99 coding standards and avoid abusing the API; small performance boosts are what make so many applications unstable bug ridden messes.
The other point that is not being mentioned is the maintenance tail.
Creating a functional/validated/in-operations software project is one thing. Being able to support, upgrade, enhance it for 5 years, 10 years is a completely different, but related problem. Assembly will NEVER be as maintainable as higher level languages. Also assembler limits you to a specific hardware platform. Granted X86 is pretty ubiquitous, but what if you want a table app ? You can't reuse ANY code. You have to start from scratch.
 
These compilers are very good, but not as good as machine language code written by a good programmer.
Wrong. I would go so far to say outside of *very* specific circumstances it is even unacceptable to be manually dropping in individual assembly operations these days. People do not appreciate how good optimizing compilers have gotten...or how bad 99.99% of people write assembly.

Basically, I will ensure anyone who utters the phrase "I can do it faster in assembly" will be staffed as far from a keyboard as humanly possible.
 
@Flayed

I would not consider "cool features" as a consideration for choosing a programming language.

Explicitly what are those features and why are they "cool"?

Inherently, I do understand your meaning and intent.

However, some examples and supporting details would be much more helpful.

Trusting that you work with C#, what features are more useful to you and why?
 
C# is a very well designed language that has many (but not all) of the feature set you can find in C++, without some of the headaches and dangers you can run into with the other C derived languages. It's not quite as fast as C/C++, but still on part with most other high-level languages.

If I need a simple GUI application that isn't performance sensitive, C# is actually my preferred language of choice. For anything that cares about performance, I favor C/C++.
 
@Flayed

I would not consider "cool features" as a consideration for choosing a programming language.

Explicitly what are those features and why are they "cool"?

Inherently, I do understand your meaning and intent.

However, some examples and supporting details would be much more helpful.

Trusting that you work with C#, what features are more useful to you and why?
I don't work with C# I took a class in college a while back. I liked the data validation rules that let you specify what is allowed to be input into a form easily. There is also a ton of stuff in the .Net framework you can use which is nice.
 
C# is a very well designed language that has many (but not all) of the feature set you can find in C++, without some of the headaches and dangers you can run into with the other C derived languages. It's not quite as fast as C/C++, but still on part with most other high-level languages.

If I need a simple GUI application that isn't performance sensitive, C# is actually my preferred language of choice. For anything that cares about performance, I favor C/C++.
The problem with C# is it requires a runtime framework to use. A big issue with this is that most certainly you'd want the .NET Framework, which limits your OS options to just Windows. While there's an open source implementation that you could run on Linux, it's likely not on par with the .NET, though I haven't really looked too deeply into this.

Requiring a runtime framework is also not on the table for embedded devices too. Especially since these are expected to be low power device and being able to shave off whatever milliamps you can tends to force certain languages to be used for the actual apps.

Also in terms of optimization, having software that only includes what it needs is a cheap and easy one. Needing a software framework where you may not need 80% of its features is not ideal.
 
The problem with C# is it requires a runtime framework to use. A big issue with this is that most certainly you'd want the .NET Framework, which limits your OS options to just Windows. While there's an open source implementation that you could run on Linux, it's likely not on par with the .NET, though I haven't really looked too deeply into this.

Requiring a runtime framework is also not on the table for embedded devices too. Especially since these are expected to be low power device and being able to shave off whatever milliamps you can tends to force certain languages to be used for the actual apps.

Also in terms of optimization, having software that only includes what it needs is a cheap and easy one. Needing a software framework where you may not need 80% of its features is not ideal.
It does go without saying that anything Embedded will run C (or if you have upscale embedded HW, C++); that's the world I primarily live in. I'm currently supporting a project that run on a Cortex A53 on an embedded system, that sends/receives messages from two GUI apps that can run on either Windows or Linux (and yes, doing one on each OS *works*). C/C++ is the *only* valid choice if you live in this world; you care about both the performance and portability.

But for non-performance sensitive GUI apps? C# as a language is well designed, simple to use, and free of many of the pitfalls of C/C++. Mono on Linux isn't bad so far as portability goes, but portability is a concern if you want to live on multiple platforms. But the framework does remove a lot of the low-level implementation you need to do to implement similar features in C/C++, which makes C# a heck of a lot quicker to get something up an running, and (assuming the framework or reimplementation is supported on your platform) does ensure portability with minimal effort.
 
Status
Not open for further replies.