Agreed. For someone who has worked on C compilers, I don't see the allure of C++
-
Want to remove ads? Register an account and login to see fewer ads, and become a Supporting Member to remove almost all ads.
Programming Language Wars: Python/C/C++ et al.
- Thread starter MC3OZ
- Start date
You're describing utilities. There are also command-line plotting and data-analysis tools, but I'm not going to call that programming, either.
There's plenty of nice Python libraries. but Python fundamentally compromises your ability to do fast, memory-efficient programming - e.g. developing new things that don't already exist. Its loose typing (and general lack of compiletime error-detection) and lack of extensibility to its slow, memory-hungry internal types and data structures makes it a bad choice for large, complex, performance-critical tasks.
But if you just want to plot out some graphs from a small CSV file, go knock yourself out. Just don't spend time writing a million lines of actual code that you're going to have to rewrite.
Last edited:
Causalien
Prime 8 ball Oracle
In the scope of algorithm dev, signal processing and machine learning relevant to Tesla’s autonomous development, creating "new things" is done in Python. Because it's faster. And the end result is not that many actual lines of of code.
My nightmare C++ story. I was working on a product that used HP OpenView (a network management platform) on HP/UX (Unix), to incorporate management of IBM mainframes. One line of code read something like:
We were stuck for about a week. Sometimes things would be fine. Sometimes we'd get an error. Sometimes everything would just freeze up. It turned out that the constructor for SNAconnection would do all sorts of things, including popping up a dialog on the mainframe management screen in the machine room, asking for a password. Sometimes the operator would just type the password, and it would work. Sometimes they would cancel the dialog, and we'd get a non-helpful error message. Sometimes they'd just ignore it completely until it went away when we killed the hung program.
Code:
SNAconnection conn = new SNAconnection("Mainframe");I'm glad this now has it own thread, it spiralled into something much better than I expected....
My simplistic analogy of where we are at is .....
Building FSD is like building a house, when no one has ever built a house...
A company called Mobileye makes huts (AP 1.0), so the first step is to buy a hut....
The house construction begins with the raw materials we think we need HW2...
As the floor plan is rapidly changing, we use Python for house construction.....
This is the type of project where you can only learn by doing.... which would be the case if no one had ever built a house..
It is proving more difficult, the floor plans go though 4 iterations V1, V2, V3, V4 with walls being demolished and rebuilt each time..
Tesla realise we don't have enough materials in HW2... so Tesla acquire (design and build) HW3...
Current car software is an older version of the house using HW2 materials, with a bit of HW3 tacked on, it has limitations,,,,,
Autonomy day was a beta version of the house using HW3, and something closer to the final floor plan...
Since Autonomy Day they have further tweaked the floor plan....
At this stage Tesla is confident they have (close to) the final floor plan and that HW3 will be adequate, hence the move to use more C++.
(Fine tuning resource usage)
But they will not know, until the house is fully built....
If you what to know what the house looks like, Autonomy Day is a better guide the current software...
I expected some software expertise in this forum, but was surprised how much machine learning expertise we have...
I don't really have machine learning expertise, my impression is from general software development and might be wrong in some aspects...
My impression is based on a few things that seem to all line up, Autonomy Day, HW3, Stop signs, C++ developers being hired etc, this kind of guess can be wrong. And even if I guessed right, things can still go wrong....
My simplistic analogy of where we are at is .....
Building FSD is like building a house, when no one has ever built a house...
A company called Mobileye makes huts (AP 1.0), so the first step is to buy a hut....
The house construction begins with the raw materials we think we need HW2...
As the floor plan is rapidly changing, we use Python for house construction.....
This is the type of project where you can only learn by doing.... which would be the case if no one had ever built a house..
It is proving more difficult, the floor plans go though 4 iterations V1, V2, V3, V4 with walls being demolished and rebuilt each time..
Tesla realise we don't have enough materials in HW2... so Tesla acquire (design and build) HW3...
Current car software is an older version of the house using HW2 materials, with a bit of HW3 tacked on, it has limitations,,,,,
Autonomy day was a beta version of the house using HW3, and something closer to the final floor plan...
Since Autonomy Day they have further tweaked the floor plan....
At this stage Tesla is confident they have (close to) the final floor plan and that HW3 will be adequate, hence the move to use more C++.
(Fine tuning resource usage)
But they will not know, until the house is fully built....
If you what to know what the house looks like, Autonomy Day is a better guide the current software...
I expected some software expertise in this forum, but was surprised how much machine learning expertise we have...
I don't really have machine learning expertise, my impression is from general software development and might be wrong in some aspects...
My impression is based on a few things that seem to all line up, Autonomy Day, HW3, Stop signs, C++ developers being hired etc, this kind of guess can be wrong. And even if I guessed right, things can still go wrong....
Last edited:
This Reddit post is relevant when considering the adequacy of HW3.0.
Autopilot rewrite with 3d labeling is only starting to use FSD computer’s potential : teslamotors
Autopilot rewrite with 3d labeling is only starting to use FSD computer’s potential : teslamotors
engle
Member
Cython is another hybrid approach, generating and compiling C code on the fly from a dialect of Python.
However, because Python is dynamically typed, it's not generally practical to completely precompile all possible code paths, and it won't ever be as fast as mainstream statically typed languages, even if JIT-compiled.”
UC Berkeley uses Python in CS 61A, Java in 61B, and C in 61C. They are their CS major intro, data structures, and machine-level 13-week semester courses. Cal used to use Scheme, a Lisp derivative for 61A! (+ 40 2) evaluates to 42 isn’t that fun!?
UCLA on the other hand uses C++, C++, C for their equivalent 3 first CS major 10-week quarter courses.
I haven’t checked Stanford and USC.
I mention this only because Tesla probably has many Cal EECS geeks on their FSD team using their first love, Python. Cal is still ranked #1 in CS I believe, although overall UCLA is now ranked as #1 public university in USA.
However, because Python is dynamically typed, it's not generally practical to completely precompile all possible code paths, and it won't ever be as fast as mainstream statically typed languages, even if JIT-compiled.”
UC Berkeley uses Python in CS 61A, Java in 61B, and C in 61C. They are their CS major intro, data structures, and machine-level 13-week semester courses. Cal used to use Scheme, a Lisp derivative for 61A! (+ 40 2) evaluates to 42 isn’t that fun!?
UCLA on the other hand uses C++, C++, C for their equivalent 3 first CS major 10-week quarter courses.
I haven’t checked Stanford and USC.
I mention this only because Tesla probably has many Cal EECS geeks on their FSD team using their first love, Python. Cal is still ranked #1 in CS I believe, although overall UCLA is now ranked as #1 public university in USA.
adiggs
Well-Known Member
Part of the issue here in the Python / C performance comparison, is that there are two kinds of performance. I think of them as developer performance (productivity) and program performance. My experience has been that you are optimizing for one or the other at any given point in time.
I am a data scientist in real life. I've met a lot of data scientists in real life. Overwhelmingly (and this includes me), data scientists are not software engineers. Even though we express what we do in program code - we're really data analysts and we script our ideas. The key mental construct software engineers all study and have (my description) is object oriented programming (Classes, compiled programs, typed data structures - I think I've got that reasonably well articulated).
The data science community (mostly) doesn't study that stuff in school, and mostly when we do, it's an intro level class and doesn't follow through with a degree and then full time daily experience afterwards. The data science skill set is (mostly) orthogonal to the software engineering skill set.
Worse - object oriented programming is a paradigm of the world, and like all paradigms, it's hard to pick new ones up. I've been trying (without going to school or making a full time job of it) to acquire the software engineering paradigm. I work with 2 really skilled people with that background, and I'm still not building object oriented programs, after several years of exposure.
The data scientists are (mostly) busy studying the data frame programming object, data sets and their different definitions and manipulations, lots and lots of analytically oriented math, and then once graduated, continuing to work with these concepts on a full time daily basis afterwards.
It turns out that the data frame / data set / analytics mindset is ALSO a paradigm, and like all paradigms it's hard to pick up. My experience with software engineers is they don't get it (not that they can't get it). It can be learned, but when one's filters of the world are something you have to fight with, it's hard to even realize that your'e in a struggle in the first place.
What I have mostly witnessed is that the software engineers don't really have the deep data structure / data frame / math skills of the data scientists (or even necessarily understand how they are different), and the data scientists don't really have the object oriented development (and related skills) or even really understand how it's different from something like Python.
(Sidebar and humorous to me - though both SE's and DS's work a lot with data, they mostly both don't realize that there's a whole other career called data management focused on data quality and reusability of data that could help them out - it's really hard to get help from people making a career of doing something helpful, when you don't even recognize their existence).
All of this has to do with developer productivity / performance. It's important to be clear on any particular problem you're working on - if program performance is the primary consideration, then yeah - Python isn't your first choice. It also limits the range of people that can do the work. Similarly, if what you're doing is data analysis and if you're primarily worried about developer productivity, then Python (or R, SAS - some other data analytic languages) are your first choice, and again - limits the range of people that can do the work. You're probably also developing intermediate or advanced SQL skills too.
Partly because the languages express the ideas more easily, partly because these are the languages the people that do this work learn and work in daily, and partly because a lot of the time - the program running time consideration is just not all that important.
The original problem statement that started this thread, was the idea that the image recognition / scene development / stuff was being written in Python. That makes sense to me - in the beginning, this problem looks more like a data science / machine learning problem. And the library development and analysis techniques come from the land of supervised, unsupervised, and etc.. learning (aka data mining; data science; ..). These are analysis techniques, and the skills mostly come with Python, R, and similar language training when people are learning these analysis skills.
We also see this is a very high volume problem, with a lot of computation bottle necks, so reimplementation in a better performing language also makes a lot of sense to me. The benefit of doing developer solutions in one form, and building a production solution in a second form is you have natural access to the full range of skill sets that are routinely trained and practiced in industry. And these are big problems that need big teams to solve.
If you had ready access to plenty of people that could do the developer solution development in a software engineering language AND you had all of the cutting edge libraries and research being performed in that software engineering language (so you didn't have to create your own libraries and research from scratch), then sure - you could skip development in one and redevelopment for performance optimization.
I suspect every company working in this field is hard at working figuring out how to subdivide the problem in meaningful ways, that enables them to hire people that have the skills to work on that specific subdivision.
I am a data scientist in real life. I've met a lot of data scientists in real life. Overwhelmingly (and this includes me), data scientists are not software engineers. Even though we express what we do in program code - we're really data analysts and we script our ideas. The key mental construct software engineers all study and have (my description) is object oriented programming (Classes, compiled programs, typed data structures - I think I've got that reasonably well articulated).
The data science community (mostly) doesn't study that stuff in school, and mostly when we do, it's an intro level class and doesn't follow through with a degree and then full time daily experience afterwards. The data science skill set is (mostly) orthogonal to the software engineering skill set.
Worse - object oriented programming is a paradigm of the world, and like all paradigms, it's hard to pick new ones up. I've been trying (without going to school or making a full time job of it) to acquire the software engineering paradigm. I work with 2 really skilled people with that background, and I'm still not building object oriented programs, after several years of exposure.
The data scientists are (mostly) busy studying the data frame programming object, data sets and their different definitions and manipulations, lots and lots of analytically oriented math, and then once graduated, continuing to work with these concepts on a full time daily basis afterwards.
It turns out that the data frame / data set / analytics mindset is ALSO a paradigm, and like all paradigms it's hard to pick up. My experience with software engineers is they don't get it (not that they can't get it). It can be learned, but when one's filters of the world are something you have to fight with, it's hard to even realize that your'e in a struggle in the first place.
What I have mostly witnessed is that the software engineers don't really have the deep data structure / data frame / math skills of the data scientists (or even necessarily understand how they are different), and the data scientists don't really have the object oriented development (and related skills) or even really understand how it's different from something like Python.
(Sidebar and humorous to me - though both SE's and DS's work a lot with data, they mostly both don't realize that there's a whole other career called data management focused on data quality and reusability of data that could help them out - it's really hard to get help from people making a career of doing something helpful, when you don't even recognize their existence).
All of this has to do with developer productivity / performance. It's important to be clear on any particular problem you're working on - if program performance is the primary consideration, then yeah - Python isn't your first choice. It also limits the range of people that can do the work. Similarly, if what you're doing is data analysis and if you're primarily worried about developer productivity, then Python (or R, SAS - some other data analytic languages) are your first choice, and again - limits the range of people that can do the work. You're probably also developing intermediate or advanced SQL skills too.
Partly because the languages express the ideas more easily, partly because these are the languages the people that do this work learn and work in daily, and partly because a lot of the time - the program running time consideration is just not all that important.
The original problem statement that started this thread, was the idea that the image recognition / scene development / stuff was being written in Python. That makes sense to me - in the beginning, this problem looks more like a data science / machine learning problem. And the library development and analysis techniques come from the land of supervised, unsupervised, and etc.. learning (aka data mining; data science; ..). These are analysis techniques, and the skills mostly come with Python, R, and similar language training when people are learning these analysis skills.
We also see this is a very high volume problem, with a lot of computation bottle necks, so reimplementation in a better performing language also makes a lot of sense to me. The benefit of doing developer solutions in one form, and building a production solution in a second form is you have natural access to the full range of skill sets that are routinely trained and practiced in industry. And these are big problems that need big teams to solve.
If you had ready access to plenty of people that could do the developer solution development in a software engineering language AND you had all of the cutting edge libraries and research being performed in that software engineering language (so you didn't have to create your own libraries and research from scratch), then sure - you could skip development in one and redevelopment for performance optimization.
I suspect every company working in this field is hard at working figuring out how to subdivide the problem in meaningful ways, that enables them to hire people that have the skills to work on that specific subdivision.
Personally I had great success once rewriting vendor libraries, with our own code, a 10x improvement in speed and quality..... it is memorable as my decision was partially driven by desperation .....
I'm sure if something like that would help, Tesla and Elon are already on to it.
I was first taught Scheme. A superb language for learning some core concepts of computer science (not so much engineering).
But then after C and Java and some others I learned Perl and the rest is history
adiggs
Well-Known Member
And heck - I've been involved in the invention of a new classifier because the alternatives didn't work quite right for our classification problem. The thing is, there's a big difference between a one off re-write or invention like that, and starting with a base programming language and deciding to do effectively all of the research and development of those helper libraries yourself (or at least, your team).
And I'm with you - I figure Tesla and Elon are rewriting every library that is critical to performance and isn't up to snuff they need to. And they're finding people with the skills to do all of the above.
That's my shorthand - I'm not in the either / or is better camp; I'm in the all-of-the-above solution camp
Buckminster
Well-Known Member
Buckminster
Well-Known Member
Buckminster
Well-Known Member
Similar threads
- Article
