TR Forums

just brew it! wrote:

CPUs have gotten fast enough, and compilers good enough, that there is rarely a need to do anything in assembly language any more. C is used pretty much everywhere that assembly language would've been used "back in the day" -- OS kernels, device drivers, embedded systems, real-time.

The rare exceptions where assembly is still used are things like the optimized strncpy() I mentioned a few posts back. A frequently used library function like that can have a big effect on application performance, so it is worthwhile to provide code paths which are hand-optimized for specific instruction sets.

In hindsight, the secret to its continued success is the fact that it provides enough abstraction to be portable across architectures (if you code carefully), but still allows direct access to the hardware. In effect, it is almost a "high level assembly language".

Yeah in general use you don't and there is no basic need for masses of programmers to know the details (they sure could all use better practices though) but those edge cases are a bitch. Anything big and important had better have at least 1 guy with a clue and some clout to make changes when the usual giant blob of slop has a design problem. Low level design rears its ugly little head in the worst way sometimes, kinda like our cpu fun right now.

I can tell you a solid 6-figure legitimate career (bonus: not getting sucked into the management chain) that is not going away unlike most valley buzzword-bingo-revolutions with just two words: assembly + malware. The downside (mostly for the employer) is for every 100 people that claim to be capable, maybe 1 actually is. Plenty of illegitimate work too, with different risks of course. The legitimacy also depends on where you live and who you work for.

just brew it! wrote:

Waco wrote:

Once upon a time I had faith that all developers at least gave their application a cursory run through helgrind prior to deploying anything.

Working in the industry for 30+ years will convince you beyond a shadow of a doubt that at least 50% of software developers don't have a f*cking clue what they are doing.

JBI, every time I read one of your threads I'm more glad I never programmed professionally (college degree aside).

I would either be encountering the same BS, or (more likely) being one of the clueless programmers thinking they know what they're doing.

Vhalidictes wrote:

JBI, every time I read one of your threads I'm more glad I never programmed professionally (college degree aside).

I would either be encountering the same BS, or (more likely) being one of the clueless programmers thinking they know what they're doing.

Oh, and I neglected to mention another amusing aspect of the bug which inspired this thread. The dodgy C code in question was actually being called from a Python application, via the "C Foreign Function Interface" library. Everyone's initial reaction (including my own) when this bug was reported was along the lines of "How the f*ck did they get a Python application to throw a segfault?!??"

So it has the multi-threaded Python angle covered too! (@Buub)

just brew it! wrote:

Vhalidictes wrote:

JBI, every time I read one of your threads I'm more glad I never programmed professionally (college degree aside).

I would either be encountering the same BS, or (more likely) being one of the clueless programmers thinking they know what they're doing.

Oh, and I neglected to mention another amusing aspect of the bug which inspired this thread. The dodgy C code in question was actually being called from a Python application, via the "C Foreign Function Interface" library. Everyone's initial reaction (including my own) when this bug was reported was along the lines of "How the f*ck did they get a Python application to throw a segfault?!??"

So it has the multi-threaded Python angle covered too! (@Buub)

Back in the day when I still slung code I used C with Python, although I was mostly using Cython. It could work great for certain things, but if it went off the rails the bugs were interesting to diagnose. You basically learned to work within your limitations. Given the global interpreter lock that's notorious in Python, you get bonus points for running into race conditions in multi-threaded C code that's being invoked from Python.

chuckula wrote:

just brew it! wrote:

Buub wrote:

The C community is loathe to change the way things have always been.

The APIs, IMHO, are much more sane in C++, at least from this perspective. I'm not sure anyone willingly gets into templates, but at least they're logically consistent and can largely be approached from a consumption-only basis unless you're writing APIs or libraries.

The Boost library and C++11 (and later) rely very heavily on templates for the newer language features. It's really powerful stuff (and I'm still trying to wrap my head around it). C++11 code that takes full advantage of the new language features doesn't even look like "classic" C++ code any more; it is effectively a new language which just happens to be backward-compatible.

With the way C++ handles types, you really need templates to re-use any sort of generic data containers or other APIs that aren't directly tied to inputting and outputting very specific data structures. Of course the STL and Boost are big examples of APIs that provide containers & services to a wide range of program that will be using different data types where templates are a must in C++. Having said that, C++ gurus could tell me what the state of "generics" in C++ is since I know the basics but I don't keep up with all the newest features of the newest language revisions.

Guys, don't get me wrong. I am a hard-core C++ developer and even gave a talk on algorithms at CPPcon. My point was that templates are an "uglier" part of the C++ API, not that they aren't tremendously useful or powerful (they are). I was also asserting that the average user, who isn't developing APIs or libraries, only has to understand templates well enough to use templated code, not write new templates, so that relieves the pressure somewhat.

Buub wrote:

notfred wrote:

Not just the Linux kernel, most kernels are in C.

For what it's worth, the Windows kernel is actively moving to C++. But yes, most kernels are still C.

I thought the Windows NT kernel was C++ from the start. ???

In a kernel or driver there are certain CPU specific things that may need either assembly language or C functions that boil down to a known CPU instruction e.g. sync_synchronize() in GCC on ARM is a DMB and on x86 an MFENCE to solve memory ordering issues.

There's also usually a bootstrap bit at the start of the kernel that gets the processor in to a fit state for the rest of the kernel to run in a more generic language.

Buub wrote:

Guys, don't get me wrong. I am a hard-core C++ developer and even gave a talk on algorithms at CPPcon. My point was that templates are an "uglier" part of the C++ API, not that they aren't tremendously useful or powerful (they are). I was also asserting that the average user, who isn't developing APIs or libraries, only has to understand templates well enough to use templated code, not write new templates, so that relieves the pressure somewhat.

I would argue that understanding them well enough to decipher the cryptic error messages the compiler spews when you use an existing template incorrectly is about 3/4ths of the way to understanding them well enough to write them.

FlamingSpaceJunk wrote:

I thought the Windows NT kernel was C++ from the start. ???

AFAIK NT kernel is (mostly or all) C, while much of the user-space Windows code is C++.

C++ was not very mature at the time NT development began, so I would be surprised if it was used much (if at all) in the kernel back in the early days.

Waco wrote:

just brew it! wrote:

Waco wrote:

Once upon a time I had faith that all developers at least gave their application a cursory run through helgrind prior to deploying anything.

Working in the industry for 30+ years will convince you beyond a shadow of a doubt that at least 50% of software developers don't have a f*cking clue what they are doing.

I've been in it for just over a decade now...and I'm pretty sure it's closer to 95%.

On one hand, finding C developers these days is difficult. On the other, they tend to be self motivated and good at what they do (since it's no longer taught in many many CompSci programs). Memory and thread management is a foreign concept to all too many "developers".

That's pretty harsh! I would have said 90%. But it's been many years since I've worked with other developers. Because I don't have to.

If they don't teach them C do they teach at least assembly? How else to learn what a computer is actually doing??

Edit: and when I was working with other people it was either C++ or Java. I guess I would agree if you work with web developers you might find 95% of them are rubbish. Same as with Visual Basic in the '90s.

FORTRAN 90 FTW

anotherengineer wrote:

FORTRAN 90 FTW

Finding anyone who knows Fortran is pretty difficult too.

A few of our big codes that run a huge number of core hours are Fortran and we're running out of people who know it well enough to maintain it.

Pancake - no web developers in my world...just C/C++/Python/Fortran developers. It's amazing to me that some of the codes function at all.

Pancake wrote:

If they don't teach them C do they teach at least assembly? How else to learn what a computer is actually doing??

Bingo! A lot of people coming out of school with CS degrees these days have absolutely no clue what's going on under the hood. The prevailing attitude seems to be "hardware is fast enough and cheap enough now that we don't need to worry about details, just treat everything like an ideal abstract compute/storage/networking engine". With predictable results when the rubber meets the road.

Pancake wrote:

Edit: and when I was working with other people it was either C++ or Java. I guess I would agree if you work with web developers you might find 95% of them are rubbish. Same as with Visual Basic in the '90s.

True story from a previous job, where I was writing some embedded code that needed to access some services hosted in the Cloud:

Me: Your VM seems to be down. I can't reach any of the web services.
Web developer: It should be up. We restarted it about an hour ago.
Me: But it doesn't even respond to pings!
Web developer: What are "pings"?

This was the same project where management changed the system architecture just a few weeks before we were supposed to be done, necessitating that the embedded device talk directly to Amazon S3 services (instead of going through an intermediate server). The embedded dev team screamed; management (and the web devs) were like "No, it's easy, you just load this DLL and it does everything for you." The device was running a 100MHz soft-core RISC processor inside an FPGA... ummm, load a DLL? (See my comment above about people who don't understand what's going on under the hood.)

I was the unfortunate dev who was given the wonderful task of implementing an Amazon S3 client stack in the FPGA. From scratch. In 2 weeks. It did work eventually (missed the 2 week deadline, heh...), but man was it S-L-O-W. Go figure.

anotherengineer wrote:

FORTRAN 90 FTW

Much as COBOL is still used in certain segments of the business computing world, FORTRAN is still used a fair bit for scientific computing. Some of these legacy languages still have their niches.

I really enjoyed this thread. Thank you for starting it! Many belly laughs were had.

just brew it! wrote:

Buub wrote:

Guys, don't get me wrong. I am a hard-core C++ developer and even gave a talk on algorithms at CPPcon. My point was that templates are an "uglier" part of the C++ API, not that they aren't tremendously useful or powerful (they are). I was also asserting that the average user, who isn't developing APIs or libraries, only has to understand templates well enough to use templated code, not write new templates, so that relieves the pressure somewhat.

I would argue that understanding them well enough to decipher the cryptic error messages the compiler spews when you use an existing template incorrectly is about 3/4ths of the way to understanding them well enough to write them.

I thought you just randomly edit a line and compile again, about ten times, then ask someone else to fix it!

Honestly, compilers are getting a bit (a little bit) better at that verbose spewage. When we finally get concepts into the standard, that is supposed to help tremendously (instead of a complex amount of spewage, it can simply say something like "Error: class is not movable" or something like that.

hey I resemble these remarks

Waco wrote:

SecretSquirrel wrote:

DragonDaddyBear wrote:

This thread makes me appreciate you C-types even more. I wanted to get into programming and I didn't because every degree program I could find wanted 1) lots of calculus and 2) Java or some other higher-level language focus. I wanted to actually get into a program where I learned the CPU, assembly, etc. To be fair, I didn't look all that hard. But, while i was OK at math back in the day, I don't feel like relearning a bunch to do calc just to have a piece of paper that says I can write code.

Look for a Computer Engineering program, if you can find one. It won't get you out of the Calculus, but they tend to focus more on the low levels of computers. The trick is to find one that isn't just a renamed CompSci program or a renamed EE program.

--SS

I can vouch for Clemson's CompE program. It's not short on the math (and lots of it) but you'll walk away with a skillset that few can boast right out of school.

I miss Riggs Hall. Clemson's CompE program is no joke. I still have some of my textbooks from classes and refer to them occasionally. I remember one little blue textbook for an ECE class with more equations per page that some other pure Math texts have in entire chapters (If my memory serves correctly it was for Random Signal Analysis, which was an ECE class despite the name). Their CompSci program (the BS at least) isn't really a joke either. A fair bit of lower level programming, including C and lots of 3d graphics programming, like ray tracers and the like which forces an understanding of data structures and how algorithms interact with them. They've got the curriculum structured so that you actually build concepts over time using 3d Graphics as a focus so that everything ties together. They have some crossover classes with ECE too, like Intro to Operating Systems which were quite good. Taught by the Dean of CS if I remember.

ETA: Too bad that my career has kept me out of programming for over 6 years. I'd basically be starting over if I tried to go back as a programmer. I was never great at multi-threaded stuff, but I got very good at embedded programming in C especially dealing with constrained computing resources. Zen of Code Optimization always made more sense to me than dealing with threads for some reason. Probably why I enjoyed doing things like mode 13h for class projects.

Ikepuska wrote:

ETA: Too bad that my career has kept me out of programming for over 6 years. I'd basically be starting over if I tried to go back as a programmer. I was never great at multi-threaded stuff, but I got very good at embedded programming in C especially dealing with constrained computing resources. Zen of Code Optimization always made more sense to me than dealing with threads for some reason. Probably why I enjoyed doing things like mode 13h for class projects.

Doesn't have to be the case. If you've still got it, you've still got it. I took more than that away from the IT industry to work in environmental management then got back into programming about ten years ago because the software I would have had to use for environmental planning and management (proprietary and open source GIS) was so rubbish and hideously unusable by non-GIS experts I decided to write my own system from scratch.

just brew it! wrote:

Pancake wrote:

If they don't teach them C do they teach at least assembly? How else to learn what a computer is actually doing??

Bingo! A lot of people coming out of school with CS degrees these days have absolutely no clue what's going on under the hood. The prevailing attitude seems to be "hardware is fast enough and cheap enough now that we don't need to worry about details, just treat everything like an ideal abstract compute/storage/networking engine". With predictable results when the rubber meets the road.

Nothing new under the sun, then. When I entered college in the late 1990s there were plenty of us EEs and MechEs building and upgrading our own desktop PCs, and we harrassed the CS majors mercilessly because many of them could barely keep the distinction that RAM == Memory != Non-Volatile Storage. All they wanted to do was write code for a black box.

Waco wrote:

anotherengineer wrote:

FORTRAN 90 FTW

Finding anyone who knows Fortran is pretty difficult too.

A few of our big codes that run a huge number of core hours are Fortran and we're running out of people who know it well enough to maintain it.

Clearly not paying enough, then -- there are load of us out here

Topinio wrote:

Waco wrote:

Finding anyone who knows Fortran is pretty difficult too.

A few of our big codes that run a huge number of core hours are Fortran and we're running out of people who know it well enough to maintain it.

Clearly not paying enough, then -- there are load of us out here

I did some FORTRAN programming back in the day; one of the first languages I learned was FORTRAN IV (a.k.a. FORTRAN 66). Last time I encountered it in a professional setting was probably in the (early) '90s. Non-professionally, I remember helping someone here in the forums with some FORTRAN questions just a few years ago.

I do have to say, all else being roughly equal I probably wouldn't take a job programming in FORTRAN today. So yeah, there would need to be some additional incentives, financial or otherwise.

Topinio wrote:

Clearly not paying enough, then -- there are load of us out here

Government and salaries that make sense...don't go hand in hand.

I make about $60k less than I could in the free market. :/

Thread safety? Pfft, one of the code bases I work with is so hosed up that when we could no longer buy single core CPUs we had to get custom bios to disable all but one of the cores. It's not C though, rather more the sort of hodgepodge of C, C++, and bizarre macros that happens a lot in mature embedded-systems environments.

ludi wrote:

under the sun, then. When I entered college in the late 1990s there were plenty of us EEs and MechEs building and upgrading our own desktop PCs, and we harrassed the CS majors mercilessly because many of them could barely keep the distinction that RAM == Memory != Non-Volatile Storage. All they wanted to do was write code for a black box.

Too bad CE wasn't a thing back then, or we'd happily counter-troll with a discussion of the joys of NVRAM.

Of course, come to think of it, the sorts of things that use NVRAM for non-trivial stuff are still fairly new even if the core technology isn't.

NovusBogus wrote:

Thread safety? Pfft, one of the code bases I work with is so hosed up that when we could no longer buy single core CPUs we had to get custom bios to disable all but one of the cores. It's not C though, rather more the sort of hodgepodge of C, C++, and bizarre macros that happens a lot in mature embedded-systems environments.

Also tentacles, sounds like. In the Iä! Iä! sense.

NovusBogus wrote:

Thread safety? Pfft, one of the code bases I work with is so hosed up that when we could no longer buy single core CPUs we had to get custom bios to disable all but one of the cores. It's not C though, rather more the sort of hodgepodge of C, C++, and bizarre macros that happens a lot in mature embedded-systems environments.

Oh, I've seen that show too.

In one case at a previous job, we hit it in an API library supplied by one of our component vendors. Attempts to explain the issue to the vendor to get them to fix their code went nowhere. We didn't disable all the additional cores system-wide though; we figured out that we could prevent the explosions if we pinned just the threads which needed to access the broken API to a single core.

In a related vein, there are also Linux device drivers from big-name enterprise hardware vendors (not naming names here since I'm not sure if this info is under NDA) that blow up if you enable kernel preemption. Kernel preemption is great for reducing latency... but if you happen to be relying on one of the broken device drivers, it's a non-starter since it destabilizes the whole system.

just brew it! wrote:

In a related vein, there are also Linux device drivers from big-name enterprise hardware vendors (not naming names here since I'm not sure if this info is under NDA) that blow up if you enable kernel preemption.

Can you name the category of device or say if they are mainlined? Or draw a picture, what about Charades?

That seems like the kind of thing people tasked with squeezing performance out of Linux kernels might be interested in knowing.

FlamingSpaceJunk wrote:

just brew it! wrote:

In a related vein, there are also Linux device drivers from big-name enterprise hardware vendors (not naming names here since I'm not sure if this info is under NDA) that blow up if you enable kernel preemption.

Can you name the category of device or say if they are mainlined? Or draw a picture, what about Charades?

That seems like the kind of thing people tasked with squeezing performance out of Linux kernels might be interested in knowing.

Enterprise grade disk controllers seem to have a disproportionate number of firmware and driver issues. You'd think a component as fundamental to the enterprise market as data storage would do better.

On our platform (OpenVMS), our ctime() implementation actually allocates a mutex-locked, thread-specific buffer and then calls ctime_r() effectively deprecating ctime().

I'm not surprised at all and I don't think it's limited to disk controllers. The running joke is that the Wifi lot all microwaved their brain cells with some prototype hardware before they turned down the power. I was told cellular was even worse, but I'm not sure how that is possible.

As has been mentioned earlier, I'm sure it all boils down to the majority of developers not having a clue and companies end up producing garbage. Linus is a lot less tolerant of that in the Linux kernel

johnrreagan wrote:

On our platform (OpenVMS), our ctime() implementation actually allocates a mutex-locked, thread-specific buffer and then calls ctime_r() effectively deprecating ctime().

Why is a mutex needed when the buffer is thread-specific? That seems overly paranoid to me, and could even result in deadlocks if ctime() is used from a signal handler.

just brew it! wrote:

Enterprise grade disk controllers seem to have a disproportionate number of firmware and driver issues. You'd think a component as fundamental to the enterprise market as data storage would do better.

I'll second this. LSI/Broadcom/Avago has gotten a lot better in recent years but they had some pretty horrible firmware bugs for quite a while before they got fixed.

just brew it! wrote:

johnrreagan wrote:

On our platform (OpenVMS), our ctime() implementation actually allocates a mutex-locked, thread-specific buffer and then calls ctime_r() effectively deprecating ctime().

Why is a mutex needed when the buffer is thread-specific? That seems overly paranoid to me, and could even result in deadlocks if ctime() is used from a signal handler.

Over-locking, while worse than not locking at all, is at least a lot easier to catch when something goes wrong.