Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

To become a good C programmer (2011)

fabiensanglard.net

Post reply on HN
Print view View original

71–80 of 135 posts

Re: To become a good C programmer (2011)

#71

Post by nickitolas »

dooglius wrote: post #64
nickitolas wrote: post #62

Earlier quoted context omitted.

Give me an example of where C is allowed to optimize your data layout and/or locality. Afaik it is incredibly restrictive in this sense, because of how well defined it is. The less things it gives as guarantees with regards to layout the more wiggle room it would have, and languages like C cannot do some things that languages with a gc can do that can improve cache locality.

It's not, that's the point, the language/compiler cannot interfere with the programmer fine tuning data structures to suit the underlying architecture.

I thought the discussion was around compiler optimizations? That's the point

Re: To become a good C programmer (2011)

#72

Post by Mike345845 »

GuB-42 wrote: post #49
wwweston wrote: post #28

One of the things I tend to think about these days is return on investment. I spent several years at the beginning of my career being a bad and then mediocre C programmer, and once I found a few other languages, I got the sense that being a mediocre-to-good programmer in these languages would be much easier, and that seems to have been borne out. Late into a career investing in other areas, what's the advantage of be…

C is still king in embedded systems. It is also great at making you aware of the machine. In C, very little is happening behind the scene. If you want something to happen, you need write some code. Objects will not initialize themselves, allocated memory will not free itself, no smart reference mechanisms, just explicit pointers. This understanding of the machine will help understanding why higher level langages beha…

> It is also great at making you aware of the machine. In C, very little is happening behind the scene.

This is not true. It hasn't been true for decades. C is an abstract high level language on modern processors.

https://queue.acm.org/detail.cfm?id=3212479

Re: To become a good C programmer (2011)

#73

Post by dooglius »

zenhack wrote: post #68
nomel wrote: post #61

Earlier quoted context omitted.

> CPU performance has completely outstripped memory perf, so memory hierarchies and locality are everything > they don't show up in the language at all... requires knowing things that the code wouldn't suggest at all I'm utterly confused at this. It's trivial to layout memory as you please, where you please, very directly, in C. Set a pointer to and address and write to it. Better yet, I can define a packed struct th…

> Set a pointer to and address and write to it. Better yet, I can define a packed struct that maps to a peripheral, point it to its memory address from a data sheet, and have a nice human readable way of controlling it: MyPIECDevice.sample_rate = 2000. Just make sure you don't forget `volatile` in the right places. A lot of codebases end up just using their own wrappers written in asm for this kind of thing, because…

I definitely agree with all your criticisms of the memory semantics in C, and I would love a language that fixed these flaws, but the "ideal" low-level language is still a lot closer to C than it is to anything else. I also think that C, being low-level, is much better poised to deal with experimental ISA designs than higher-level languages. For instance, one mechanism of manual cache control could be that you set bit 63 in a pointer to indicate that loads/stores from should place the corresponding cacheline in a high-priority. That's pretty trivial with a pointer in C, but a lot harder with say a C++ reference.

Re: To become a good C programmer (2011)

#74

Post by porknubbins »

Mike345845 wrote: post #72
GuB-42 wrote: post #49

Earlier quoted context omitted.

C is still king in embedded systems. It is also great at making you aware of the machine. In C, very little is happening behind the scene. If you want something to happen, you need write some code. Objects will not initialize themselves, allocated memory will not free itself, no smart reference mechanisms, just explicit pointers. This understanding of the machine will help understanding why higher level langages beha…

> It is also great at making you aware of the machine. In C, very little is happening behind the scene. This is not true. It hasn't been true for decades. C is an abstract high level language on modern processors. https://queue.acm.org/detail.cfm?id=3212479

True, but if it is still possible to be a C programmer who can more or less imagine what assembly will be generated (at lower levels of optimization at least) by their C code, then isn't the real issue that x86 assembly abstracts away a lot of hardware info about caches, pipelines, microcodes etc? In that case how can a low level exist on x86?

Re: To become a good C programmer (2011)

#75

Post by cozzyd »

wwweston wrote: post #28

One of the things I tend to think about these days is return on investment. I spent several years at the beginning of my career being a bad and then mediocre C programmer, and once I found a few other languages, I got the sense that being a mediocre-to-good programmer in these languages would be much easier, and that seems to have been borne out. Late into a career investing in other areas, what's the advantage of be…

The C ABI is still king.

Re: To become a good C programmer (2011)

#76

Post by kragen »

wwweston wrote: post #28

One of the things I tend to think about these days is return on investment. I spent several years at the beginning of my career being a bad and then mediocre C programmer, and once I found a few other languages, I got the sense that being a mediocre-to-good programmer in these languages would be much easier, and that seems to have been borne out. Late into a career investing in other areas, what's the advantage of be…

If you are troubleshooting software problems in any language (except, usually, Java), sooner or later you dig down and hit C or C++. In those cases knowing C means you can solve the problem.

There are a lot of libraries written in C, like, thousands in Debian alone. You can use them from any language, but sometimes you need to write a little bit of glue C to get that to work. Sometimes it's less painful to just write your program in C++ or Objective-C so you don't have to debug your glue C.

If you want to write a library that can be used from any language, basically your options are C, C++ (but realistically its C subset), and Rust. Getting things to work all the time is easier in Rust than in C or C++. Getting things to work some of the time is easier in C.

But for most of these things it's probably adequate to be a mediocre C programmer. Unless your mediocrity is manifested in spending a week on tracking down a bug that should have taken an hour, maybe.

Re: To become a good C programmer (2011)

#77

Post by sn9 »

anaphor wrote: post #8

"C Interfaces and Implementations" is another one that comes highly recommended. https://sites.google.com/site/cinterfacesimplementations/

This book is fantastic to tackle for anyone comfortable with C at the level of K&R. A great second book on C.

And one of the few examples of literate programming one might come across!

Re: To become a good C programmer (2011)

#78

Post by dooglius »

nickitolas wrote: post #71
dooglius wrote: post #64

Earlier quoted context omitted.

It's not, that's the point, the language/compiler cannot interfere with the programmer fine tuning data structures to suit the underlying architecture.

I thought the discussion was around compiler optimizations? That's the point

I didn't read it as such. The point behind what I and the parent are saying is, the programmer is going to do much better at optimal memory layout than an optimizer can, and C allows manual control while languages which can mess with memory layout necessarily cannot.

Re: To become a good C programmer (2011)

#79

Post by firethief »

kragen wrote: post #76
wwweston wrote: post #28

One of the things I tend to think about these days is return on investment. I spent several years at the beginning of my career being a bad and then mediocre C programmer, and once I found a few other languages, I got the sense that being a mediocre-to-good programmer in these languages would be much easier, and that seems to have been borne out. Late into a career investing in other areas, what's the advantage of be…

If you are troubleshooting software problems in any language (except, usually, Java), sooner or later you dig down and hit C or C++. In those cases knowing C means you can solve the problem. There are a lot of libraries written in C, like, thousands in Debian alone. You can use them from any language, but sometimes you need to write a little bit of glue C to get that to work. Sometimes it's less painful to just write…

> Getting things to work all the time is easier in Rust than in C or C++. Getting things to work some of the time is easier in C.

I think this is a good generalization of the learning curves of the languages, but not necessarily productivity for an experienced developer. Rust has modern amenities like pattern matching, generics and a package manager.

Re: To become a good C programmer (2011)

#80

Post by madmax96 »

zenhack wrote: post #68
nomel wrote: post #61

Earlier quoted context omitted.

> CPU performance has completely outstripped memory perf, so memory hierarchies and locality are everything > they don't show up in the language at all... requires knowing things that the code wouldn't suggest at all I'm utterly confused at this. It's trivial to layout memory as you please, where you please, very directly, in C. Set a pointer to and address and write to it. Better yet, I can define a packed struct th…

> Set a pointer to and address and write to it. Better yet, I can define a packed struct that maps to a peripheral, point it to its memory address from a data sheet, and have a nice human readable way of controlling it: MyPIECDevice.sample_rate = 2000. Just make sure you don't forget `volatile` in the right places. A lot of codebases end up just using their own wrappers written in asm for this kind of thing, because…

>If you care about these issues there's a lot of rules lawyering you have to do to be sure your code isn't going to break if the compiler is cleverer than you are.

>A modern take on C should be much more explicit about semantically meaningful memory access.

If you are working on concurrent code close to the hardware you’re going to either have to accept a less efficient language or engage in rule lawyering. Unfortunately, granting the compiler license to perform the most mundane optimizations interferes with concurrent structures. Fortunately, with C there are rules to lawyer with, and they actually are simple. No matter what, rules will always need learned.

Post reply on HN