I think a good C programmer should have a grasp on how assembly works. This can come in incredibly handy for debugging weird errors. Yes there are bugs that are weird enough to only become evident in assembly code. An understanding of assembly also makes memory management and pointers in C so much more understandable. Also, assembly reveals quite a bit about performance: Less instructions == faster code. Then there are some platform-specific things that aren't available[1] from C (at least the standard library) like SSE or MMX instructions. These can give you a big speedup (think of it as "micro-parallelization") if used correctly. Some things in glibc (mainly in string.h) are implemented using them, but as far as I know the standard library doesn't provide an interface to them and the compiler usually isn't smart enough to use them when appropriate. So if you're trying to squeeze the last bit of performance out of a program you'll often have no choice but implementing a bit of assembly code as well.
Concerning architecture: One might argue it's not neccessary but I think a good C programmer should at least have scratched the surface here. No deep understanding, but a bit of an overview of what's going on. That is - I think - the point where it no longer concerns you as a programmer. Architecture and Assembly really go hand in hand, since every architecture comes with its own assembly code (yes I know, some assemblers are abstracting that away sometimes). That is why some things work faster on, say SPARC than on x86. It also helps understand the limits we're given and what "64 bit" really means.
Understanding architecture doesn't really help writing better C code, but it explains things the compiler does, since in a pipelined architecture, the compiler will arrange assembly instructions, so there are as little stalls as possible and therefore gaining performance.
[1] I might be wrong on that though. Please correct me if I am.
Concerning architecture: One might argue it's not neccessary but I think a good C programmer should at least have scratched the surface here. No deep understanding, but a bit of an overview of what's going on. That is - I think - the point where it no longer concerns you as a programmer. Architecture and Assembly really go hand in hand, since every architecture comes with its own assembly code (yes I know, some assemblers are abstracting that away sometimes). That is why some things work faster on, say SPARC than on x86. It also helps understand the limits we're given and what "64 bit" really means.
Understanding architecture doesn't really help writing better C code, but it explains things the compiler does, since in a pipelined architecture, the compiler will arrange assembly instructions, so there are as little stalls as possible and therefore gaining performance.
[1] I might be wrong on that though. Please correct me if I am.