I think the authors of SICP realized there were other models out there, and I think they might disagree with the statement that lambda calculus have almost nothing to do with how computers work.
Sussman was a co-author on several papers, the titles of which approximated: "Lambda: The ultimate goto instruction." I think Sussman and Abelson know a lot more about cs than you give them credit for.
*sigh* Slashdot headline misleading... Film at 11.
Here, the 256-bits refers to the instruction word, not the data-word size. These are completely different things. If you're going by this, then your x86 could be considered up to a 48-bit machine or so. The TMTA chips are still 32 or 64 or 48 or something like x86 is. this is just going to mean that because it's VLIW, it can do 8 ops per cycle per pipeline stage instead of 4. Cool, but not any more revolutionary than anything else TMTA has done.
Umm, actually, Pentiums and their later brethren ahve 36-bit physical addressing off-chip. Logical addressing-wise, I'm not sure. I never understood x86.
A) Because Transmeta is VLIW, they don't speculatively execute. That's the whole point, Instruction Fetch/Decode (two of the bottlenecks in traditional architectures) have been more or less eradicated because it's so simple. So, really, that point is completely not true. At the moment, my lab group has a chip whose instruction size is about 5-600 bits (I can never remember). Impressive, until you realize that it isn't.
B) The translation doesn't have to be that great. They're still performing fairly competitively with Intel chips.
C) Pentiums don't play well enough. Transmeta can simulate fairly well a several hundred megahertz (probably about 4-500) Pentium III. Also, Intel is notoriously bad at doing such things. Their memory is not written down on how to make such chips, but only remembered in the minds of the workers. It would be VERY hard for them to do that, actually.
D) Transmeta based solutions have often employed other cool ideas in terms of power consumption: Better LCD's that don't need backlights, e.g. Not perfect, but getting there.
E) Transmeta's solution is so amazing that, even if it hasn't revolutionized the world, it has changed the course of Intel's strategy non-trivially. Plus, it's awesomely cool.
Wow, I haven't been flamed for a while. Thanks for the opportunity. AWK was designed by people at Bell Labs. That counts. As was UNIX. That counts. That is two, in and of itself. These people didn't just happen to be working by themselves in the same building. They were bouncing the ideas off of everyone in their department, no doubt. That lunch table must have been exciting.
I will admit that I had not remembered qed, and I gracefully cede that point.
In reference to your point that "there's not much difference... between three and one." I obviously disagree. There is a difference between one student working on his own to make a kernel that he wants to use and three people working in the context of a department where they are creating a whole new system as a group, even if each individual piece was made separately. That's not a lone inventor, that's modularization.
As far as I can tell, these people have, respectively "invented" Linux, Perl and Vim, which are respectively marginal improvements (in certain senses) of UNIX, AWK, and ed/sed. They all at least have various philosophical similarities to what I have described as their predecessors.
These three inventions were all made by Bell Labs. Bell Labs was supported only by the telephone monopoly, aka the biggest corporation in the world. I'd say that that is a far cry from a "lone inventor." What it once took a genius years to do, it eventually takes anyone no time at all. You understand the laws of motion (probably) and gravity, which is more than can be said of anyone living in the 12th Century. You can create new applications of those problems, but that doesn't make you the inventor of them. Even if you recast them and re-write them.
I think that they are unclear and do not properly explain the situation. Remember, you're writing so people can UNDERSTAND the code, not so that you can impress them with how smart you are. Instead, strive for a comment like this:
i++;/*changes the value stored in the space referred to by i to be the sum of the old value stored in the space referred to by i and the constant 1. Note: In C, this may cause what is known as a "silent overflow" if the value is too large, and go so far as to make a large positive value into a larger negative one. Oh my!
This way, people who read your code not only understand your program, but all programs. I really think that each function you write should repeat a semester's worth of computer science theory and programming practice, so that anyone who reads your code will learn from it. Remember, not everyone knows idioms, and why should they? And since we all write open source on slashdot, many novices are going to have their introduction to any computing environment by looking at the code you write at any point.
Actually, Stanford does have a java class. CS193J. Being part of the 193 series, which exists to teach tools, it cannot count towards a degree in computer science. Also, the third quarter of programming (object-oriented and large software projects) is taught in java, and the optimizing compilers class was this year, too. -Dan
Why could that possibly matter? Do you care if you have a Transmeta or Intel chip to run x86 ops, aside from sheer performance? Or put this way, so what if it's dynamically translated?
Secondly, picojava (?) chips do this. You can buy the core from Sun, and put them on your own chips. So, they actually do exist, but because they're all stack-based and in other ways fairly odd, you could probably do better with a dynamic translator than a silicon implementation, especially once you factor in volume. -Dan
Umm, adders are actually linear in size of transistors (at least without special logic). I think that a 16 bit adder would take on the order of 500 transistors, not 4 billion. No chip, yet, has 1 billion transistors (that I know of). B) That's why people have bool's already. Also, if you only assign 1's or 0's to the ints, then it can drop them down. This is how auto-vectorization works. E) This isn't a matter of upping the word, it's a matter of virtualization, which is a useful abstraction.
I disagree from an architectural standpoint. In an ideal world, we'd all have 8-bit machines. All our arithmatic would be insanely fast; we'd be able to use combinational logic to allow two probagation levels for ANY operation (add, sub, mul, div, sqrt, log, etc). That's because it's cost effective to do so; a minimal set of possible outcomes. I'm not completely sure, but I'll speculate that it's possible to arbitrarily generate an arbitrarily sized number from just these 8 bits; though most likely it would be programatically (even if done via micro-code), and thus would be non-optimal for larger than 8-bit data-sets. So obviously, as we've been able to, we've increased the data-length throughout history as we've demonstrated a need.
8 bits?! Why 8 bits? You make it sounds like this is atomic, when it's not. At all. If you're going to go for the theoretical minimum, go for 1 bit. The CM-1 used 1 bit processors, and could do everything. But why 8 bit?! That's sort of whack.
Another important factor (which is presumably obvious in concept) is that a higher word-size has a greater probability of wasted space. A 1-bit boolean, for example, wasts 63bits.. Booleans are very common, and though they can easily be consolidated in c-struct's, such is rarely the case, since there are memory alignment issues (and flat-out laziness on the part of programmers). The wasted word-space also affects the instructions. Rarely do you actually see 64bit aligned CPU-instructions (except in VLIW or in places that the data-word-size was irrelevant). Such a situation would have massive implications towards performance. But one serious consideration is that the population of 64bit constants using a 32bit instructional word is expensive. Now you have to perform at least 3 (probably 4 or 5) instructions just to load a constant. Suddenly "a++" starts to look scary (at least when non-optimal compilers are used). In all cases sub-word-size'd instructional arguments are permissable to the delight of compiler designers, but there are still classes of problems that thwart this.. Namely memory addressing...
A) consolidate in c-structs? Programmer laziness? Don't bash the programmer, at all. That's just cruel. The programmer shouldn't have to. That's the compiler's job. However, that can often slow down the code, when it has to mask all the bits, op, then mask all the bits again. So, just using one word for a boolean makes sense. Surely, though, a compiler could do what it wans. B) Constants get loaded into a different segment than the code, so they won't be in the code, most likely. Unless they're ints or somesuch, in which case you can just use an add-immediate to move them in, and in almost all cases (as you YOURSELF very specifically state) they won't take up more than one immediate. C) "a++ looks scary"? Umm, a++ will still take one operation (add $rx, $rx, 1). What are you even talking about? Not to mention that compilers optimize. D) You can still have 32 bit data values in a 64 bit computer by loading the words from memory differently, so don't think that suddenly EVERYTHING has to be in memory as a 64 bit value just because your architecture is that. E) On a 32 bit architecture (at least, real ones), the 4 gig memory limit (2 on certain ones, e.g. MIPS) is per process, not per system. Thus, you can have many processors, each of which have 4 gigs of memory allocated and using running on a computer with 512K of memory. It would be slow, but that's the beauty of software.
The cost, in fact, will be in the middle. The cost will be on the order of n^8 or so, I think. Where n is the number of bits. -Dan PS: That is, in fact, huge.
Yes. I can give you an excellent reason. The upper 50 or so bits of a 64 bit processor's words are largely 0. Except for addresses, in which cases they're still mostly the same. Basically, you don't need a 64 bit address space for most applications, but the (growing) number of exceptional apps make it worth it. But when was the last time you heard of an application needing 16 Billion GB of data on hand? It's been a while.
Those 16 Billion GB of data fill up 64-bit. Say you had a 256-bit processor? You could count to a LARGE number. Whoop-de-frickin'-doo. When was the last time you needed to count to that large a number? Or one of your programs did? Probably very rarely.
SIMD uses aside (which have been mentioned elsewhere in responses to this), you don't need that much. In fact, 256 bits would decrease performance. Why? Because when you tried to pull that information in out of memory to the cache, or from disk to the memory, you'd have more time spent waiting for these bits to be transferred around. In fact, this sucks the most because almost all of those bits will be 0 (unless you're dealing with small negative numbers, in which case they'll all mostly be 1).
Numbers that are this big are used so infrequently that you can use bignums (used in lisp, for example) to represent them without taking much of a performance hit at all in the common case, and the exceptional case (VERY rare) will only be maybe twice as slow, which makes the average case faster.
Thus, if you want a slower computer, go design a 256-bit processor, by all means. -Dan
In fact, I'm fairly sure you're wrong. Well, sort of. You're probably right when you say that a processor with larger word size will be faster than those with smaller. However, it will also be more expensive.
Equivalently, you could have, for the same price, a 64 bit processor or a 32 bit processor which has more functional units, more cache, a faster clock, etc. What this means is that if you need 64 bit, it's better. If you don't, it probably isn't. Why do we need 64 bits? That, my dear friends, is the 64-thousand dollar question.
To deal with (precise) numbers larger than 4 billion. Do we need to? Well, sort of. It can be useful for polygons and stuff, but the "32-bit" architectures, largely, already have the SIMD instructions (MMX, Altivec, etc.) which will do this.
Basically, I think that the reason that many people are moving to 64 bit is that it doesn't cost much, and you could conceivably use it. Also, it makes compiling easier if everybody has the same processor. But by and large, I don't really think most people should care.
BTW, if anybody gets on my ass for this, 64 bits can't be for that much performance. If you want real performance, you have to go to some other model of computation at this point, so... yeah.
What claim do the advertisers have? Easy, when you buy an ad in Times Square, you pay a lot. More than my life is worth, to be sure. When you do that, though, you become part of Times Square. This isn't some podunk town being made up to look like some other podunk town in Nowheresville having its billboard changed, this is a situation where the advertisers had a reasonable belief that they would be featured in media. Spiderman obviously isn't trying to use Times Square as a stereotypical city backdrop, they're using it for the cultural significance. Part of that is the ads. After spending just a couple days in the area, the ads have an effect on me. The screens, the Nasdaq and so on. To portray one aspect and not another is changing the reality. Now, there are, of course, free speech arguments to be made and all things considered, I side with the first amendment. Think about it this way: What if you were using an image of me, but changing my eye color because you thought it looked better, ot it matched your production company's logo colors better, would that be fair? Probably not, if I had entered with the idea that you would accurately represent me. I'm sure that the City of New York and all entities involved in it give out filming permits with the idea that they will be portrayed more or less accurately, if not positively. I'm not saying they're right, but I am saying that they're not so obviously wrong, and that we should consider and discuss. -Dan
Wow. I wish I could highlight a section of your post to point out as being wrong as you did the the grandparent. Unforutnately, I can't. You're wrong all throughout.
First, how do you show something is proven? Well, you give a proof. How do I know the proof is correct? I work through all the steps... But what if I mess up and sneeze and my thinking gets confused and I accept something that isn't true? It could happen. Well, I'll just push it through a formal logic computer program that checks it. But what if the computer has a glitch and a 0 or a 1 gets accepted. Or worse, I made the error while programming the formal logic system. Or more subtly, the compiler or hardware.
Basically, it's like this, proofs are as much a social event as a mathematical cedrtainty. Proofs are presented, and believed, and then refuted. Mathematical proof is a social process carried on by mathamaticians, and you can't forget that. I'm sure that I've proved things incorrectly before, and believed them. Just because nobody's found an error in a published and accepted proof doesn't mean one doesn't exist. If you think that humans can do ANYTHING with probability 1, you're sorely mistaken and are seeing the world in too convenient terms.
Sorry to burst your bubble, but there's a lot of thinking in this. Peer review does not imply flawlessness.
Just so we're clear... recursive acronyms can be cool, as long as they aren't of the form F--B [is or isn't] Bar. Try this recursive acronym on for size (courtesy of Guy Steele): Recursive Acronyms Such As RASARAW Are Wonderful.
While y'all are fooling around with java... I went the original root. I've been playing with self. J/K. We al know that functional language users are so well hung that sometimes they have to use a lisp.
Slashdot Mirror
Just a couple set-uid bits here and there made the Internet Worm possible.
Sussman was a co-author on several papers, the titles of which approximated: "Lambda: The ultimate goto instruction." I think Sussman and Abelson know a lot more about cs than you give them credit for.
Here, the 256-bits refers to the instruction word, not the data-word size. These are completely different things. If you're going by this, then your x86 could be considered up to a 48-bit machine or so. The TMTA chips are still 32 or 64 or 48 or something like x86 is. this is just going to mean that because it's VLIW, it can do 8 ops per cycle per pipeline stage instead of 4. Cool, but not any more revolutionary than anything else TMTA has done.
Umm, actually, Pentiums and their later brethren ahve 36-bit physical addressing off-chip. Logical addressing-wise, I'm not sure. I never understood x86.
B) The translation doesn't have to be that great. They're still performing fairly competitively with Intel chips.
C) Pentiums don't play well enough. Transmeta can simulate fairly well a several hundred megahertz (probably about 4-500) Pentium III. Also, Intel is notoriously bad at doing such things. Their memory is not written down on how to make such chips, but only remembered in the minds of the workers. It would be VERY hard for them to do that, actually.
D) Transmeta based solutions have often employed other cool ideas in terms of power consumption: Better LCD's that don't need backlights, e.g. Not perfect, but getting there.
E) Transmeta's solution is so amazing that, even if it hasn't revolutionized the world, it has changed the course of Intel's strategy non-trivially. Plus, it's awesomely cool.
Wow, I haven't been flamed for a while. Thanks for the opportunity. AWK was designed by people at Bell Labs. That counts. As was UNIX. That counts. That is two, in and of itself. These people didn't just happen to be working by themselves in the same building. They were bouncing the ideas off of everyone in their department, no doubt. That lunch table must have been exciting.
I will admit that I had not remembered qed, and I gracefully cede that point.
In reference to your point that "there's not much difference ... between three and one." I obviously disagree. There is a difference between one student working on his own to make a kernel that he wants to use and three people working in the context of a department where they are creating a whole new system as a group, even if each individual piece was made separately. That's not a lone inventor, that's modularization.
These three inventions were all made by Bell Labs. Bell Labs was supported only by the telephone monopoly, aka the biggest corporation in the world. I'd say that that is a far cry from a "lone inventor." What it once took a genius years to do, it eventually takes anyone no time at all. You understand the laws of motion (probably) and gravity, which is more than can be said of anyone living in the 12th Century. You can create new applications of those problems, but that doesn't make you the inventor of them. Even if you recast them and re-write them.
I think we'll only learn it once. The question is when that one time is finally going to happen.
Yeah. It's not foo(1). That's not going to be an application. It's just a function call.
i++; //increments the variable i
I think that they are unclear and do not properly explain the situation. Remember, you're writing so people can UNDERSTAND the code, not so that you can impress them with how smart you are. Instead, strive for a comment like this:
i++; /*changes the value stored in the space referred to by i to be the sum of the old value stored in the space referred to by i and the constant 1. Note: In C, this may cause what is known as a "silent overflow" if the value is too large, and go so far as to make a large positive value into a larger negative one. Oh my!
This way, people who read your code not only understand your program, but all programs. I really think that each function you write should repeat a semester's worth of computer science theory and programming practice, so that anyone who reads your code will learn from it. Remember, not everyone knows idioms, and why should they? And since we all write open source on slashdot, many novices are going to have their introduction to any computing environment by looking at the code you write at any point.
Your most humble and obedient servant,
Dan
Actually, Stanford does have a java class. CS193J. Being part of the 193 series, which exists to teach tools, it cannot count towards a degree in computer science. Also, the third quarter of programming (object-oriented and large software projects) is taught in java, and the optimizing compilers class was this year, too.
-Dan
Do you care if you have a Transmeta or Intel chip to run x86 ops, aside from sheer performance?
Or put this way, so what if it's dynamically translated?
Secondly, picojava (?) chips do this. You can buy the core from Sun, and put them on your own chips. So, they actually do exist, but because they're all stack-based and in other ways fairly odd, you could probably do better with a dynamic translator than a silicon implementation, especially once you factor in volume.
-Dan
Hmm...
Maybe you were kidding, but...
emacs existed before GNU. GNU emacs is just one implementation.
-Dan
Umm, adders are actually linear in size of transistors (at least without special logic). I think that a 16 bit adder would take on the order of 500 transistors, not 4 billion. No chip, yet, has 1 billion transistors (that I know of).
B) That's why people have bool's already. Also, if you only assign 1's or 0's to the ints, then it can drop them down. This is how auto-vectorization works.
E) This isn't a matter of upping the word, it's a matter of virtualization, which is a useful abstraction.
8 bits?! Why 8 bits? You make it sounds like this is atomic, when it's not. At all. If you're going to go for the theoretical minimum, go for 1 bit. The CM-1 used 1 bit processors, and could do everything. But why 8 bit?! That's sort of whack.
A) consolidate in c-structs? Programmer laziness?
Don't bash the programmer, at all. That's just cruel. The programmer shouldn't have to. That's the compiler's job. However, that can often slow down the code, when it has to mask all the bits, op, then mask all the bits again. So, just using one word for a boolean makes sense. Surely, though, a compiler could do what it wans.
B) Constants get loaded into a different segment than the code, so they won't be in the code, most likely. Unless they're ints or somesuch, in which case you can just use an add-immediate to move them in, and in almost all cases (as you YOURSELF very specifically state) they won't take up more than one immediate.
C) "a++ looks scary"? Umm, a++ will still take one operation (add $rx, $rx, 1). What are you even talking about? Not to mention that compilers optimize.
D) You can still have 32 bit data values in a 64 bit computer by loading the words from memory differently, so don't think that suddenly EVERYTHING has to be in memory as a 64 bit value just because your architecture is that.
E) On a 32 bit architecture (at least, real ones), the 4 gig memory limit (2 on certain ones, e.g. MIPS) is per process, not per system. Thus, you can have many processors, each of which have 4 gigs of memory allocated and using running on a computer with 512K of memory. It would be slow, but that's the beauty of software.
The cost, in fact, will be in the middle. The cost will be on the order of n^8 or so, I think. Where n is the number of bits.
-Dan
PS: That is, in fact, huge.
Those 16 Billion GB of data fill up 64-bit. Say you had a 256-bit processor? You could count to a LARGE number. Whoop-de-frickin'-doo. When was the last time you needed to count to that large a number? Or one of your programs did? Probably very rarely.
SIMD uses aside (which have been mentioned elsewhere in responses to this), you don't need that much. In fact, 256 bits would decrease performance. Why? Because when you tried to pull that information in out of memory to the cache, or from disk to the memory, you'd have more time spent waiting for these bits to be transferred around. In fact, this sucks the most because almost all of those bits will be 0 (unless you're dealing with small negative numbers, in which case they'll all mostly be 1).
Numbers that are this big are used so infrequently that you can use bignums (used in lisp, for example) to represent them without taking much of a performance hit at all in the common case, and the exceptional case (VERY rare) will only be maybe twice as slow, which makes the average case faster.
Thus, if you want a slower computer, go design a 256-bit processor, by all means.
-Dan
Equivalently, you could have, for the same price, a 64 bit processor or a 32 bit processor which has more functional units, more cache, a faster clock, etc. What this means is that if you need 64 bit, it's better. If you don't, it probably isn't. Why do we need 64 bits? That, my dear friends, is the 64-thousand dollar question.
To deal with (precise) numbers larger than 4 billion. Do we need to? Well, sort of. It can be useful for polygons and stuff, but the "32-bit" architectures, largely, already have the SIMD instructions (MMX, Altivec, etc.) which will do this.
Basically, I think that the reason that many people are moving to 64 bit is that it doesn't cost much, and you could conceivably use it. Also, it makes compiling easier if everybody has the same processor. But by and large, I don't really think most people should care.
BTW, if anybody gets on my ass for this, 64 bits can't be for that much performance. If you want real performance, you have to go to some other model of computation at this point, so... yeah.
Hello, my name is Dan BentlEy.
My father is Jon BentlEy.
We spEll our namE with an E.
To Taco:
"My name is Dan Bentley. You kill my father ('s name). Prepare to die.
What claim do the advertisers have?
Easy, when you buy an ad in Times Square, you pay a lot. More than my life is worth, to be sure. When you do that, though, you become part of Times Square. This isn't some podunk town being made up to look like some other podunk town in Nowheresville having its billboard changed, this is a situation where the advertisers had a reasonable belief that they would be featured in media. Spiderman obviously isn't trying to use Times Square as a stereotypical city backdrop, they're using it for the cultural significance. Part of that is the ads.
After spending just a couple days in the area, the ads have an effect on me. The screens, the Nasdaq and so on. To portray one aspect and not another is changing the reality. Now, there are, of course, free speech arguments to be made and all things considered, I side with the first amendment.
Think about it this way: What if you were using an image of me, but changing my eye color because you thought it looked better, ot it matched your production company's logo colors better, would that be fair? Probably not, if I had entered with the idea that you would accurately represent me. I'm sure that the City of New York and all entities involved in it give out filming permits with the idea that they will be portrayed more or less accurately, if not positively.
I'm not saying they're right, but I am saying that they're not so obviously wrong, and that we should consider and discuss.
-Dan
Wow. I wish I could highlight a section of your post to point out as being wrong as you did the the grandparent. Unforutnately, I can't. You're wrong all throughout.
First, how do you show something is proven? Well, you give a proof. How do I know the proof is correct? I work through all the steps... But what if I mess up and sneeze and my thinking gets confused and I accept something that isn't true? It could happen. Well, I'll just push it through a formal logic computer program that checks it.
But what if the computer has a glitch and a 0 or a 1 gets accepted. Or worse, I made the error while programming the formal logic system. Or more subtly, the compiler or hardware.
Basically, it's like this, proofs are as much a social event as a mathematical cedrtainty. Proofs are presented, and believed, and then refuted. Mathematical proof is a social process carried on by mathamaticians, and you can't forget that. I'm sure that I've proved things incorrectly before, and believed them. Just because nobody's found an error in a published and accepted proof doesn't mean one doesn't exist. If you think that humans can do ANYTHING with probability 1, you're sorely mistaken and are seeing the world in too convenient terms.
Sorry to burst your bubble, but there's a lot of thinking in this. Peer review does not imply flawlessness.
Ronald Rivest.
The algorithm wasn't invented (even in part) by a Myst sequel.
Just so we're clear... recursive acronyms can be cool, as long as they aren't of the form F--B [is or isn't] Bar. Try this recursive acronym on for size (courtesy of Guy Steele):
Recursive Acronyms Such As RASARAW Are Wonderful.
This would be so much truer if Alfred Nobel had had a wife, huh?
While y'all are fooling around with java...
I went the original root. I've been playing with self.
J/K. We al know that functional language users are so well hung that sometimes they have to use a lisp.