1. Incorrect. The CPU does not do "code generation" in any way akin to compiler code generation, it just cracks instructions into typically 1-2 uops.
It also does a few register optimisations. Exactly which ones depends on the chip and the vendor, but for example, register-to-register moves are sometimes implemented as manipulations of the architectural-to-physical register mapping tables.
And even this is only true on current x86 implementations. We don't know exactly how Jazelle DBX works (ARM won't say), but some other JVM-on-top-of-RISC translators do optimisation on the translated code. There's quite a bit of research, for example, on code-optimisation-by-finite-state transducer which has been translated into silicon.
First, a piece of terminology: The Intel term for what you call "decoded RISC microcode" is "uop". The "u" is meant to be a mu, but it's usually pronounced "u". It's short for micro-operation.
So there are essentially two kinds of optimisation available:
1. How the uops are scheduled. The CPU has a lot more freedom here than a typical RISC processor because the CPU did the code generation, rather than the compiler.
2. If the uop doesn't use a functional unit, don't generate any uops for it. The common case is register-to-register moves, which can be implemented by manipulating the architectural-to-virtual register allocation table.
Some Intel chips also have one more feature which could be argued as an optimisation: there is no L1 instruction cache. Instead of caching x86 instructions in memory, it caches sequences of uops, avoiding the decoding overhead for commonly-executed code.
The other thing is that programmers and compiler writers are told to avoid the more CISC-y instructions (e.g. LOOP, PUSHA/POPA), on the grounds that they are guaranteed to be slow compared to the RISC-y equivalents.
Hell, I remember using an Archimedes in 1988. Odd to think that my phone now has four of them.
Back to the topic, the border between RISC and CISC is a bit fuzzy these days. Every modern CISC chip is basically a dynamic translator on top of a RISC core. But even high-end ARM chips can do some of this with Jazelle.
To be fair, CISC does have a few performance advantages when power consumption isn't (as big) an issue. The code density is better on x86 (yes, even with Thumb), which does mean they tend to use instruction cache more effecitvely. ARM chips generally don't do out-of-order scheduling and retirement; that uses a lot of power, and is the main architectural difference between laptop-grade and desktop/server-grade x86en).
I'd like to see what a mobile-grade Alpha processor looks like. But I never will.
You unionize when labor laws are obviously being violated.
You get a lawyer when labor laws are obviously being violated. You unionise when you want to negotiate with management on behalf of the workforce as a whole, not just on behalf of yourself.
You also unionise when labor laws which don't yet exist (but should) are being violated. The law is often behind technology, so there will always be a place for this.
Gilliam has been trying to get funding for his completed script of Good Omens for over a decade. (But it looks like it's going to be done as a TV movie instead.)
If a job offered me a 100% raise, but I had to commute an hour each way, I'd say no.
It depends how you're commuting. Two hours of driving a day would send me crazy.
However, I do commute an hour each way every day by train. I get two hours a day to listen to podcasts, read books or papers, and generally do anything that doesn't take up more than one seat or annoy other people. I also managed to score an honorary appointment at the university campus, so I have access to a well-stocked library. My hours are flexible, and my dress code is nonexistent (beyond basic health and safety requirements).
But the best part is this: I get to go to work every day and work on potential cures for cancer.
I could probably get a 100% raise working in the finance sector, and the commute would be shorter. But I get to wake up each morning and feel like I'm going to do something that matters.
This is probably the most insightful comment I've seen on this thread so far. I wish I hadn't already commented, so I could mod you up.
Here it is again for those who didn't get it: Good people with CS degrees are largely self-taught. That's what university is for. It's a place for people who want to learn to teach themselves. The advantage is that you get some of the best thinkers in your chosen field to guide you through the self-teaching process. And most importantly, they nudge you (sometimes gently, sometimes not) to teach yourself material that you didn't know that you needed to know.
I wouldn't be surprised if your run-of-the-mill CS graduate wasn't as skilled as your average self-taught software engineer.
I interpret this as a commentary on the state of run-of-the-mill CS degrees, that they don't teach you anything that you can't learn yourself from "Java in 21 Days for Dummies". If that was a correct assessment, I agree with you. Good CS degrees are a different beast.
I love it how a CS degree gets you an "entry-level programming" job, but an engineering degree gets you an "advanced programming/development" job, as if someone will hire you as a team lead straight out of university.
If you want an "advanced development" job, a CS degree will do just as well as a SE degree in the long run. The advantage of CS is that it will work marginally better for you if you want to do R&D rather than just D.
Disclaimer: What I'm about to say is mostly experience, and not intended as a comprehensive review of the available evidence. In my defence, I'm not really responding to anything which claims to be "evidence".
The people who understand the languages and practice them daily know them best.
The Dunning-Kruger effect suggests otherwise. Personally, I've seen too many bad designs by people who really don't understand what they're doing to believe that this is a reliable rule.
People who use a programming language daily can be good at solving problems in that language. But they tend to be very poor at deciding which language is best for solving a particular problem, noticing when the language itself (or its interaction with something else) is causing the problem, or rationally deciding what problems actually need solving in the first place. People with no knowledge of the theory of what they are doing typically do not, to use P.J. Plauger's phrase, program on purpose.
I've seen an SQL query that runs for hours (written by someone who never studied CS but has written a lot of SQL) replaced with a ten-line merge which runs in seconds (by a CS PhD).
And by the way, it's not just non-CS-graduates who make these mistakes, although the mistakes made by CS graduates working outside their areas of expertise do tend to be more subtle. Python, for example, contains a lot of elementary mistakes in its design which would never be made by someone who actually understood programming language semantics. I don't mean to knock Guido "closures don't matter" van Rossum, because he is a smart guy. I could easily have picked Rob Pike, whose CS credentials are impeccable.
There's a lot to be said for just jumping in. There's also a lot to be said for understanding what you're doing. In the real world, you need both.
If you want to understand how and why a compiler works, and how to build one, CS is for you.
If you just want to use one, it's probably not.
"If you want to understand how English works and how it came to be, linguistics is for you. If you just want to be a writer, it's probably not."
"If you want to understand how music works and is put together, music theory is for you. If you just want to play an instrument, it's probably not."
Do you see the problem here? You can't call yourself a professional writer of English (or any other language for that matter) without some knowledge of the grammar, morphology, semantics and pragmatics of it. No, you don't need to be a linguist to the point that you can diagnose speech delay in children, or construct your own conlang. But you need to know how your language works, and you need to know it well.
As for your specific example, even if you never consider writing a compiler, many (if not most) programming tasks involve at least some work that is compiler-like. For example, any time you need to write code which reads a file which has some structure, or implement a network protocol, you're writing a parser. If you don't know you're writing a parser, you'll inevitably write a bad parser which will either cause your code to die an obscure death, be a maintenance headache for years to come, or require a rewrite by someone who did study CS.
Our economy is in the shitter and we're spending money building a menu for Mars?
Please quantify your objection. To help you with this, the current unit of government waste is bank bailouts, which replaced the previous unit (time spent in Iraq) in mid-2009.
Must have taken a whole ten minutes to replace CGA sprites with VGA.
Actually, it usually required substantial rewrites of the codebase. We're talking about an era where abstracting away the hardware wasn't as easy as you might hope without incurring a significant performance hit.
If you do not know it yet, that famous "I Have A Dream" speech by Martin Luther King is not permitted to be aired anywhere, unless you can obtain agreement from the copyright owners
Just to be clear on one point.
That this historically important speech can be effectively banned (except for fair use) is disturbing. That it is effectively banned is almost entirely due to his highly dysfunctional family.
In the Stone Age, "music", "art", "culture", "religion" and "medicine" were not distinct concepts, and were often practiced by the same people. These started splitting off into distinct fields during the Classical era. But we wouldn't say that music has been on the decline since the Stone Age just because there's very little medicine in it these days.
Of course theology is a minor subsection of the philosophy department. Philosophy, like everything, is becoming more specialised as time goes on.
And for the record, theologians study all sorts of things, including the culture, linguistics, history and anthropology of the Ancient Near East, or the history of Christianity. If you ignore those useless North American "bible colleges", the majority of this is good, solid research. There is more theology happening today than there has ever been. Hell, you don't even have to be a theist to be a theologian these days.
There are no rational reasons that I'm aware of to believe in God. I'd be pleased if you'd share some.
It partly comes down to how you define "God". If you define "God" in terms of classical theism, then there's no reason to presuppose the existence of such an entity.
However, that's not the only type of deity that's been followed over the milennia. To a Sun worshipper, the Sun is "God". Moreover, by any scientific test that you care to name, the Sun exists. Therefore, a Sun worshipper has every reason to believe in "God".
Or suppose that you define "God" as "that which mystics experience". As there's plenty of indication mystics experience something, it's perfectly rational to believe in "God". For this definition, "God" may be (and, indeed, most likely is) nothing more than an artifact of our psychology, but as ESR famously pointed out, that doesn't mean it's not worth pursuing.
Actually, it's not "perfectly copied". It follows the original story, but it updates the way the story is told. Some of the boring bits from HL have been skimmed a bit, the scale of the facility has been widened, and retcons from the later games were incorporated. (Barney is a full-fledged character, for example.)
Slashdot Mirror
1. Incorrect. The CPU does not do "code generation" in any way akin to compiler code generation, it just cracks instructions into typically 1-2 uops.
It also does a few register optimisations. Exactly which ones depends on the chip and the vendor, but for example, register-to-register moves are sometimes implemented as manipulations of the architectural-to-physical register mapping tables.
And even this is only true on current x86 implementations. We don't know exactly how Jazelle DBX works (ARM won't say), but some other JVM-on-top-of-RISC translators do optimisation on the translated code. There's quite a bit of research, for example, on code-optimisation-by-finite-state transducer which has been translated into silicon.
First, a piece of terminology: The Intel term for what you call "decoded RISC microcode" is "uop". The "u" is meant to be a mu, but it's usually pronounced "u". It's short for micro-operation.
So there are essentially two kinds of optimisation available:
1. How the uops are scheduled. The CPU has a lot more freedom here than a typical RISC processor because the CPU did the code generation, rather than the compiler.
2. If the uop doesn't use a functional unit, don't generate any uops for it. The common case is register-to-register moves, which can be implemented by manipulating the architectural-to-virtual register allocation table.
Some Intel chips also have one more feature which could be argued as an optimisation: there is no L1 instruction cache. Instead of caching x86 instructions in memory, it caches sequences of uops, avoiding the decoding overhead for commonly-executed code.
The other thing is that programmers and compiler writers are told to avoid the more CISC-y instructions (e.g. LOOP, PUSHA/POPA), on the grounds that they are guaranteed to be slow compared to the RISC-y equivalents.
In my defence, I did say "generally".
Hell, I remember using an Archimedes in 1988. Odd to think that my phone now has four of them.
Back to the topic, the border between RISC and CISC is a bit fuzzy these days. Every modern CISC chip is basically a dynamic translator on top of a RISC core. But even high-end ARM chips can do some of this with Jazelle.
To be fair, CISC does have a few performance advantages when power consumption isn't (as big) an issue. The code density is better on x86 (yes, even with Thumb), which does mean they tend to use instruction cache more effecitvely. ARM chips generally don't do out-of-order scheduling and retirement; that uses a lot of power, and is the main architectural difference between laptop-grade and desktop/server-grade x86en).
I'd like to see what a mobile-grade Alpha processor looks like. But I never will.
You unionize when labor laws are obviously being violated.
You get a lawyer when labor laws are obviously being violated. You unionise when you want to negotiate with management on behalf of the workforce as a whole, not just on behalf of yourself.
You also unionise when labor laws which don't yet exist (but should) are being violated. The law is often behind technology, so there will always be a place for this.
You could, but you aren't allowed more than 3oz of coke to wash it down.
I have two, and they are.
Interestingly, both Hogfather and Going Postal matched the characters I had in my head almost exactly. Especially Susan and Moist respectively.
(The Colour of Magic is best forgotten, though. In my head of, Rincewind is played by Rhys Ifans.)
Gilliam has been trying to get funding for his completed script of Good Omens for over a decade. (But it looks like it's going to be done as a TV movie instead.)
If a job offered me a 100% raise, but I had to commute an hour each way, I'd say no.
It depends how you're commuting. Two hours of driving a day would send me crazy.
However, I do commute an hour each way every day by train. I get two hours a day to listen to podcasts, read books or papers, and generally do anything that doesn't take up more than one seat or annoy other people. I also managed to score an honorary appointment at the university campus, so I have access to a well-stocked library. My hours are flexible, and my dress code is nonexistent (beyond basic health and safety requirements).
But the best part is this: I get to go to work every day and work on potential cures for cancer.
I could probably get a 100% raise working in the finance sector, and the commute would be shorter. But I get to wake up each morning and feel like I'm going to do something that matters.
Typical student, wanting the librarians to do your research for you.
This is probably the most insightful comment I've seen on this thread so far. I wish I hadn't already commented, so I could mod you up.
Here it is again for those who didn't get it: Good people with CS degrees are largely self-taught. That's what university is for. It's a place for people who want to learn to teach themselves. The advantage is that you get some of the best thinkers in your chosen field to guide you through the self-teaching process. And most importantly, they nudge you (sometimes gently, sometimes not) to teach yourself material that you didn't know that you needed to know.
I wouldn't be surprised if your run-of-the-mill CS graduate wasn't as skilled as your average self-taught software engineer.
I interpret this as a commentary on the state of run-of-the-mill CS degrees, that they don't teach you anything that you can't learn yourself from "Java in 21 Days for Dummies". If that was a correct assessment, I agree with you. Good CS degrees are a different beast.
I love it how a CS degree gets you an "entry-level programming" job, but an engineering degree gets you an "advanced programming/development" job, as if someone will hire you as a team lead straight out of university.
If you want an "advanced development" job, a CS degree will do just as well as a SE degree in the long run. The advantage of CS is that it will work marginally better for you if you want to do R&D rather than just D.
Disclaimer: What I'm about to say is mostly experience, and not intended as a comprehensive review of the available evidence. In my defence, I'm not really responding to anything which claims to be "evidence".
The Dunning-Kruger effect suggests otherwise. Personally, I've seen too many bad designs by people who really don't understand what they're doing to believe that this is a reliable rule.
People who use a programming language daily can be good at solving problems in that language. But they tend to be very poor at deciding which language is best for solving a particular problem, noticing when the language itself (or its interaction with something else) is causing the problem, or rationally deciding what problems actually need solving in the first place. People with no knowledge of the theory of what they are doing typically do not, to use P.J. Plauger's phrase, program on purpose.
I've seen an SQL query that runs for hours (written by someone who never studied CS but has written a lot of SQL) replaced with a ten-line merge which runs in seconds (by a CS PhD).
And by the way, it's not just non-CS-graduates who make these mistakes, although the mistakes made by CS graduates working outside their areas of expertise do tend to be more subtle. Python, for example, contains a lot of elementary mistakes in its design which would never be made by someone who actually understood programming language semantics. I don't mean to knock Guido "closures don't matter" van Rossum, because he is a smart guy. I could easily have picked Rob Pike, whose CS credentials are impeccable.
There's a lot to be said for just jumping in. There's also a lot to be said for understanding what you're doing. In the real world, you need both.
If you want to understand how and why a compiler works, and how to build one, CS is for you.
If you just want to use one, it's probably not.
"If you want to understand how English works and how it came to be, linguistics is for you. If you just want to be a writer, it's probably not."
"If you want to understand how music works and is put together, music theory is for you. If you just want to play an instrument, it's probably not."
Do you see the problem here? You can't call yourself a professional writer of English (or any other language for that matter) without some knowledge of the grammar, morphology, semantics and pragmatics of it. No, you don't need to be a linguist to the point that you can diagnose speech delay in children, or construct your own conlang. But you need to know how your language works, and you need to know it well.
As for your specific example, even if you never consider writing a compiler, many (if not most) programming tasks involve at least some work that is compiler-like. For example, any time you need to write code which reads a file which has some structure, or implement a network protocol, you're writing a parser. If you don't know you're writing a parser, you'll inevitably write a bad parser which will either cause your code to die an obscure death, be a maintenance headache for years to come, or require a rewrite by someone who did study CS.
Our economy is in the shitter and we're spending money building a menu for Mars?
Please quantify your objection. To help you with this, the current unit of government waste is bank bailouts, which replaced the previous unit (time spent in Iraq) in mid-2009.
So how many bank bailouts are we talking here?
Always bring some Vaseline to the Airports bathroom.
For some reason, the first thing I thought of was Larry Craig.
Anyhoo, make sure it's no more than 3oz of Vaseline.
Must have taken a whole ten minutes to replace CGA sprites with VGA.
Actually, it usually required substantial rewrites of the codebase. We're talking about an era where abstracting away the hardware wasn't as easy as you might hope without incurring a significant performance hit.
If you do not know it yet, that famous " I Have A Dream " speech by Martin Luther King is not permitted to be aired anywhere, unless you can obtain agreement from the copyright owners
Just to be clear on one point.
That this historically important speech can be effectively banned (except for fair use) is disturbing. That it is effectively banned is almost entirely due to his highly dysfunctional family.
Oh, please.
In the Stone Age, "music", "art", "culture", "religion" and "medicine" were not distinct concepts, and were often practiced by the same people. These started splitting off into distinct fields during the Classical era. But we wouldn't say that music has been on the decline since the Stone Age just because there's very little medicine in it these days.
Of course theology is a minor subsection of the philosophy department. Philosophy, like everything, is becoming more specialised as time goes on.
And for the record, theologians study all sorts of things, including the culture, linguistics, history and anthropology of the Ancient Near East, or the history of Christianity. If you ignore those useless North American "bible colleges", the majority of this is good, solid research. There is more theology happening today than there has ever been. Hell, you don't even have to be a theist to be a theologian these days.
It partly comes down to how you define "God". If you define "God" in terms of classical theism, then there's no reason to presuppose the existence of such an entity.
However, that's not the only type of deity that's been followed over the milennia. To a Sun worshipper, the Sun is "God". Moreover, by any scientific test that you care to name, the Sun exists. Therefore, a Sun worshipper has every reason to believe in "God".
Or suppose that you define "God" as "that which mystics experience". As there's plenty of indication mystics experience something, it's perfectly rational to believe in "God". For this definition, "God" may be (and, indeed, most likely is) nothing more than an artifact of our psychology, but as ESR famously pointed out, that doesn't mean it's not worth pursuing.
Oh, you must be young. The advent of VGA resulted in a huge number of re-releases of older games.
Actually, it's not "perfectly copied". It follows the original story, but it updates the way the story is told. Some of the boring bits from HL have been skimmed a bit, the scale of the facility has been widened, and retcons from the later games were incorporated. (Barney is a full-fledged character, for example.)
To be fair, this was a "spare time" project by fans, which means that schedules are inherently unreliable.
The good news is I won my bet about whether Black Mesa or Ep3 would come out first.