Earlier quoted context omitted.
That requires special Hardware in contrast to C code.
Intel will not sell you an x86 processor without a GPU capable of compute these days.
That will affect a raspberry pi user how?
Should you learn C to “learn how the computer works”?
371–380 of 381 posts
Re: Should you learn C to “learn how the computer works”?
#372Earlier quoted context omitted.
> which is fine given Python is a scripting language at heart This is exactly the problem, and it's actually kind of rare to get an example of what you're talking about to show up in the very comments you're using to explain the problem! Very validating, that is. For the other folks reading this, imagine trying to work with someone who thinks these things. Imagine how unwilling to change their bad habits they'll be,…
Are you claiming Python _isn't_ a scripting language? If it isn't then what the heck is it?!? What I find generally from Python developers who have lived an breathed the language for many years is that they accept there are fundamental failings and acknowledge the better means to workaround those. In reading back through your comments, it seems you are blinkered by those with the benefit of working in other languages…
Python is an object oriented programming language, not a "scripting" language. "Scripting" implies writing "scripts" (e.g. #!/usr/bin/python), but that's not it's only (or primary) use case, and in fact creates the problems I've been talking about above.
Python the language has plenty of flaws. This conversation was never about Python however, it was about the bad habits C programmers bring to Python enterprise development, and how I struggle to work with C programmers because of those good-in-c-but-bad-in-python habits. I was curious if anyone else experienced these problems, and then you arrived and became a perfect example of the attitudes I encounter regularly from C programmers working in Python.
I have no problems with C, it's obviously one of the most (if not the most) important programming languages of our time. My problem is with the habits some C programmers have brought to my Python projects.
Re: Should you learn C to “learn how the computer works”?
#373Earlier quoted context omitted.
Register renaming was invented to give assembler code generated from C enough variables in the forms of processor registers, so that calling functions wouldn't incur as much of a performance penalty. The UltraSPARC processor is a stereotypical example, a RISC processor designed to cater to a C compiler as much as possible: with register renaming, it has 256 virtual registers!
Register renaming is older than C (the first computer with full modern OoOE was the 360/91 from 1964). It has more to do with scheduling dynamically based on the runtime data flow graph than anything about C (or any other high level language).
Agreed with your historical information, but the comment about function calls and calling conventions is not without merit. If you have 256 architectural registers you still can't have more than a couple callee-save registers (otherwise non-leaf functions need to unconditionally save/restore too many registers), and so despite the large number of registers you can't really afford many live values across function calls, since callers have to save/restore them. Register renaming solves this problem by managing register dependencies and lifetimes for the programmer across function calls. With a conventional architecture with a lot of architectural registers, the only way you can make use of a sizable fraction of them is with massive software pipelining and strip mining in fully inlined loops, or maybe with calls only to leaf functions with custom calling conventions, or other forms of aggressive interprocedural optimization to deal with the calling convention issue. It's not a good fit for general purpose code.
Another related issue is dealing with user/kernel mode transitions and context switches. User/kernel transitions can be made cheaper by compiling the kernel to target a small subset of the architectural registers, but a user mode to user mode context switch would generally require a full save and restore of the massive register file.
And there's also an issue with instruction encoding efficiency. For example, in a typical three-operand RISC instruction format with 32-bit instructions, with 8-bit register operand fields you only have 8 bits remaining for the opcode in an RRR instruction (versus 17 bits for 5-bit operand fields), and 16 bits remaining for both the immediate and opcode in an RRI instruction (versus 22 bits for 5-bit operand fields). You can reduce the average-case instruction size with various encoding tricks, cf. RVC and Thumb, but you cannot make full use of the architectural registers without incurring significant instruction size bloat.
To make the comparison fair, it should be noted that register renaming cannot resolve all dependency hazards that would be possible to resolve with explicit registers. You can still only have as many live values as there are architectural registers. (That's a partial truth because of memory.)
There are of course alternatives to register renaming that can address some of these issues (but as you say register renaming isn't just about this). Register windows (which come in many flavors), valid/dirty bit tracking per register, segregated register types (like data vs address registers in MC68000), swappable register banks, etc.
I think a major reason register renaming is usually married to superscalar and/or deeply pipelined execution is that when you have a lot of physical registers you run into a von Neumann bottleneck unless you have a commensurate amount of execution parallellism. As an extreme case, imagine a 3-stage in-order RISC pipeline with 256 registers. All of the data except for at most 2 registers is sitting at rest at any given time. You'd be better served with a smaller register file and a fast local memory (1-cycle latency, pipelined loads/stores) that can exploit more powerful addressing modes.
Re: Should you learn C to “learn how the computer works”?
#374Re: Should you learn C to “learn how the computer works”?
#375Earlier quoted context omitted.
I don't see how C passes 2 (it's notorious as a language where it takes 200 lines to make a HTTP request) or 3 (it has arbitrary textual macros, so there's all sorts of "cleverness" e.g. GObject). And I'd regard 4 and 5 as false as even C-with-IDE is less productive than e.g., to return to the same example, OCaml-without-IDE.
I am willing to concede that OCaml is a small language (Having not used it, I dont have any evidence for or against). As for C, I was looking at small purely from the views of a new comer who is using a book to come upto speed with a language. You can write the programs from c books as is in a simple text editor and just compile / run them. C Books dont spend a huge amount of focus on arbitrary textual macros so in p…
I'm not trying to push OCaml specifically, I'm just using it as an example of a "normal" language. I'd consider most languages (e.g. Python, TCL, Ruby, Java, Lisp, Haskell...) to be "smaller" than C; indeed the only languages I can think of that feel "bigger" are C++ and Perl.
Re: Should you learn C to “learn how the computer works”?
#376Earlier quoted context omitted.
Are you claiming Python _isn't_ a scripting language? If it isn't then what the heck is it?!? What I find generally from Python developers who have lived an breathed the language for many years is that they accept there are fundamental failings and acknowledge the better means to workaround those. In reading back through your comments, it seems you are blinkered by those with the benefit of working in other languages…
Python is an object oriented programming language, not a "scripting" language. "Scripting" implies writing "scripts" (e.g. #!/usr/bin/python), but that's not it's only (or primary) use case, and in fact creates the problems I've been talking about above. Python the language has plenty of flaws. This conversation was never about Python however, it was about the bad habits C programmers bring to Python enterprise devel…
It's clear you've had an unpleasant experience in the past. It's sounds like maybe you were burned in that experience and dumped the blame on a particular group.
Re: Should you learn C to “learn how the computer works”?
#377As someone who felt that C was the path to knowledge for how modern computer systems "work", Forth and QEMU have become my "stretch challenge" for those with the motivation to tinker. For me, working thru the resources on the OSDev wiki by taking jonesforth and linking it with the bootstrap from the "Writing an OS in Rust" tutorial ( https://os.phil-opp.com/ ) really showed me how far C is from the hardware, and how…
Do you have the source to your OS bootstrap code + jonesforth? I'd love to play around with that.
It's hard to share, unfortunately, but I would recommend trying it out yourself regardless. The journey was more rewarding than the destination, at least for me.
In my case, the destination was a very simple Forth interpreter that read input from the serial port and sent a single packet over the virtual NIC interface. There are so many ways to go, that just happened to be my choice.
Re: Should you learn C to “learn how the computer works”?
#378Earlier quoted context omitted.
I'm not going to play anymore metaphor/semantic games. It's nice that you did that project, but it's not at all necessary for someone to engage in that in order to understand performance issues.
You're the one that raised the metaphor, but okay? I'm not saying that you can't do performance work without having done that. Just that you'll be at a disadvantage since you're at the mercy of whatever your HW vendor decides to disclose to you. If you know this stuff you can work back from from first principals. With a high level memory architecture of a system(say tiled vs direct rendering GPU) you can reason about…
You're the one that raised the metaphor, but okay
And your response was absurd. You don't rebuild a transmission in order to run a shop. You don't even rebuild a transmission as an engineer creating cars, you shop that out to an organization specializing in the extremely difficult task of designing and building transmissions. I wanted to avoid this waste of time, but here we are.
As for the rest of your comment about reasoning about performance, none of that requires the work you did. Again, neat project (for you), but completely unnecessary in general.
Re: Should you learn C to “learn how the computer works”?
#379Earlier quoted context omitted.
Here's the C99 standard: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf There are no occurrences of the words "stack" or "heap" in this document. What the spec actually discusses is "storage durations". Now, in many cases you can say, well, "automatic storage duration" means it's on the stack, but that's not something C has any opinions about. If you want to know about the stack and the heap, saying "learn…
People don’t learn C by learning the spec, and virtually every c implementation and runtime I know, it uses a stack and heap. Oddly you seem to recognize this, so I’m not sure what your point is.
Most languages do that internally. It's not a reason you should learn C in particular while you're trying to get an understanding of heaps and stacks.