I read the pdf linked in the article and was excited, because this proposal seems like it might actually work. I checked out the responses and was very irritated to find that the vast majority of the posters were objecting to things that weren't even in the proposal. I haven't read slashdot much recently, and I can really see what people mean when they say it's going to hell in a handbasket.
(And hopefully someone responded to your previous post in exactly this way, creating an ultra-tiple-decker dup.)
You're right that computer architecture is in for some big changes in the coming decades, but probably not in the ways that you expect. As some other posters pointed out, the RISC/CISC debate is over. The big problem is that all popular architectures are still structured around the idea of a single sequential instruction stream.
Computer architects have more transistors than they can shake a stick at now, but at some point it becomes impossible to accelerate a single RISC/CISC instruction stream by throwing more transistors at it. What we need are new architectures that are designed from the ground up for serious parallelism. I'm not talking about 4 or 8 parallel execution units, I'm talking about tens, hundreds, even thousands of instructions executing independently.
If you're interested in this sort of thing, I recommend checking out the ADAM architecture from MIT or the PipeRench architecture from CMU. Obviously, these ideas are not yet commercially available, but I expect that within 10 years we are going to see a major leap in the mainstream processor world to more highly parallel architectures.
I've written a compiler in Java and a compiler in SML (a language in the same family as Ocaml) and I promise you that it was MUCH easier in SML. And I didn't even have to use the imperative features in the main body of the compiler code.
If you are curious, I highly recommend Bob Harper's introduction to SML. If you read it with an open mind, it will open you up to a whole new world of programming. http://www-2.cs.cmu.edu/~rwh/smlbook/
Very simple example of proving that a program meets a high level spec, using SML:
{* pre-condition: n >= 0 *}
fun factorial 0 = 1
| factorial n = n * factorial(n - 1)
Proof that factorial correctly implements the factorial function, by mathematical induction on n:
base case (n = 0):
1) factorial 0 =? 0!
2) 1 =? 1 (good)
It might seem that you can do this sort of thing in any programming language. However, there are some important features of SML that make this a nearly complete proof, as opposed to just a good argument. To get from step 1 to step 2 we had to replace factorial(n) with n * factorial(n - 1). We can do this, because every call to a function with a given argument in purely functional code will return the same result. To get from step 3 to step 4, we should invoke the multiplication semantics from the Definition of Standard ML (I'm just too lazy to look up the page number). Most languages do not have such a formal definition.
I am currently working on a new circuit description language (in the same vein as Verilog and VHDL) for which I am implementing a compiler/simulator in SML. I plan on proving certain nice features -- like the simulation can never spin off into infinity -- that would be impossible to prove in most programming languages.
There are many functional-style languages that are not statically type safe. LISP is the most popular one. Java is a nearly type-safe language. There are some flaws in the Java type system that require runtime checks to ensure that the program doesn't go wrong. There is no such thing as a null pointer in any statically type safe language.
Some examples of what many "type-safe" language compilers can prove:
-A variable will always contain a value of the correct type. This contrasts with any language that allows casting from one type to another.
-Unallocated memory will never be accessed. This contrasts with any language that requires manual memory allocation.
-Given a particular input, a function will always return the same value. This contrasts with any language that allows memory store effects.
In addition to low level things that a compiler can prove about your program, formal languages also permit higher level proofs about the functionality of your program. A programmer can prove correct functionality for her program, as opposed to just testing it with lots of data and hoping that it will work in the future. If you are interested I highly recommend reading Bob Harper's Introduction to SML. His web page is http://www.cs.cmu.edu/~rwh. Scroll down to the bottom to his books section.
I was blending the architectural and linguistic domains, the way John Backus did in his seminal paper "Can programming be liberated from the von Neumann style?:a functional style and its algebra of programs". A small excerpt from that paper's abstract:
Conventional programming languages are growing ever more enormous, but not stronger. Inherent defects at the most basic level cause them to be both fat and weak: their primitive word-at-a-time style of programming inherited from their common ancestor--the von Neumann computer, their close coupling of semantics to state transitions, their division of programming into a world of expressions and a world of statements, their inability to effectively use powerful combining forms for building new programs from existing ones, and their lack of useful mathematical properties for reasoning about programs.
So you are correct; I was primarily talking about programming languages, not architectures. However, the two domains are closely related and most programmers use programming languages that are still primarily based on the semantics of the architecture on which they run.
There is a whole host of languages more "modern" than C, Java, C++, C#, Pascal, Ada, Perl, or any other of the essentially von Neumann-style languages out there. I highly recommend that anyone out there who is interested in advanced type-safe languages take a look at SML, O'Caml, Haskell or Clean. Most of these languages have more or less formalized language semantics (as in mathematically precise). Formal descriptions and strong type systems allow the compiler to *prove* (again, in a mathematically precise sense) that a program can not go wrong at run time.
If the literary range of slashdot readers is accurately represented by the postings to this story so far, most of you really need to break out of the SF rut once in a while. I'm not suggesting that SF books are inferior; just that there is a whole lot of great writing out there that is not in that category.
My nominations:
-Joseph Heller. After Catch 22 he didn't have much inspiration left, but Catch 22 is clearly one of the best American novels ever.
-Michael Chabon. I'm not nearly as confident about Chabon as I am about Heller, but some of his books are great reads and he's still in his 20's (I think).
> We need to fix the current problem, not dwell on how it came about.
I hope you are not responisble for making any important decisions. I am feeling very ambivalent about attacks on the Talbian. However, I am quite certain that fixing problems without understanding what caused them is no fix at all.
> Rote memorization isn't a sign of intellectual ability.
I disagree. I think most of us would agree that memorization and intelligance are not one in the same, but being able to remember individual bits of information is clearly one part of a well-functioning brain. I happen to be quite bad at remembering pieces of data, so it's unsurprising that I chose a field of study in which it is more important to be able solve problems than remember things. However, I would say there are professions in which it is incredibly important to be able to remember and recall lots of information quickly. For example, when a good lawyer looks at a case, he or she should be able to immediately recall some other related cases that set precedence that might be relevant.
First, I think beauty is the wrong word to use. A bridge (or any other engineering project) can be beautiful without being terribly useful or reliable. I think we should be striving for high quality software. What is a simple way of writing more high quality software you ask? Stop using C, C++, or Java. Start using ML, Haskell, or Clean. Modern functional programming languages offer:
1. Immutable objects
2. Higher order functions
3. Strong static type systems
4. No pointers
5. Garbage collected memory allocation system
All of these add up to shorter, much more reliable code. I know there are some people out there who will protest that any garbage collected language will be slow. This is simply false. Thanks to strong static typing and a formal semantic that permits easy reasoning about optimizations, ML family language compilers produce code that is almost always faster than Java code and quite possibly faster than C code that has not been hand optimized. For those who are interested take a look at "Haskell vs. Ada Vs. C++ vs. Awk vs.... An Experiment in Software Prototyping Productivity" and "Four-fold Increase in Productivity and Quality" for respectively an academic and industrial look at the productivity increase offered by functional languages.
The one area of computing that most functional languages are not particularly well suited for is low level system programming. However, there are researchers working on that, and how many of us do low level system programming?
> Every human activity obeys the rules of economics
This really depends on what you mean by the rules of economics. I agree that there are some fundamental principles about economic activity that can not be avoided. However, I don't believe that any human has a good quantitative understanding of exactly what these "laws of economics" are. In every economics text I have seen these principles are either ridiculously non-quantitative or unproven. When I say non-quantitative I am refering to things like supply-demand curves or the Laffer curve. Of course these models describe some reasonable economic activity, but no one knows exactly what their shape is and therefore can't use them to predict the outcome of individual events. I mean proven more in the mathematical and logical sense than the sociological sense.
When some people say the rules of economics they mean something far more mundane about how the Fed should control interest rates or how Wall St will react to this or that. To suggest that the people making these sorts of decisions are using fundamental laws the way a scientist at NASA would use gravity to figure out how to get a space craft to Mars is ridiculous.
To get back to the article, clearly nothing (Linux included) can break the first sort of economic law that I dicsussed. However, I think what Scot Hacker was refering to was more the second sort of economic law; the collected conventional wisdom about the way a software company (and specifically an operating system company) must operate to survive. This sort of law Linux most definitely does break by not being tied to any large established economic body.
> One advantage of C++, in my experience, is its
> support for multiple paradigms. C++ isn't an
> object-oriented programming language, or a
> functional programming language, or a procedural
> language -- but it allows me to use all of those
> paradigms as needed to accomplish a task.
There is a big problem with this attitude towards programming languages. One of the big advantages that many functional languages (and other carefully designed languages for that matter) have is that they have certain nice provable -- and in many cases proved -- properties that are a result of a tractable language definition. C++ is probably the best example of a totally intractable language and it is therefore impossible to say with mathematical certainty what a C++ program means. It is also a bit of a stretch to say that one can program functionally in C++. I understand that there are various contortions you can go through to get some of the features of functional languages, but it's still pretty far from ML or Haskell in my opinion.
I agree that object oriented programming is overrated by its adherants. However, I have seen a few programs that drew quite a bit of expressiveness from being written in an object oriented language. I don't think functional programming is as overrated as you appear to. I think it is quite remarkable what has been accomplished in functional languages (i.e. the Fox project at CMU (SML) or wireless switching software at Ericsson (Erlang)) with a fraction of the effort as has been expended on similar projects written in more traditional languages. An Ericsson employee recently wrote a paper about their experience with Erlang, with respect to productivity:http://www.erlang.se/publications/Ulf _Wiger.pdf. Clearly there is a significant limit to the good and happiness that language choice can bring on any particular software project. However, I think a large portion of the application code running today would have been better off written in a functional language.
> Why do people get so worked up about one specific tool?
Coming from the functional programming camp I can tell you that SML, O'Caml, Haskell, Clean, etc. people tend to get so worked up because so much energy and time is put in to arguing about whether C, C++, Java or Perl is better. I believe that for a significant chunk of general application developement (i.e. not writing OSes, device drivers or shell scripts) good functional languages are years ahead of most popular languages in language design. One important advantage that many languages (especially Java) have over functional languages is that huge libraries of freely available code exist already. At my job I am forced to use Java for compilers and circuit simulators and synthsizers. I could write the same applications in SML (the functional language that I am most familiar with) in half the code with one quarter of the bugs and mathematically prove that important parts of my algorithms were correct.
For what it's worth, I have had only good experiences with group programming. However, I am still in school and all of my group programming experience has come from classes, not from work. I think one of the biggest potential gains from group programming is that it is much easier for a small group of people to think around a problem than a single person. If a single programmer runs into a problem for which he/she can't think of an elegant solution, he/she might decide to just give up or hack around it. However, with more than one person, ideas can be bounced around and it seems more likely that a reasonable solution will appear in less time. Given the extent to which programming is a process of solving lots of small problems, group programming seems like a big advantage to me.
Does anyone know if there are any companies planning on offering Linux (or any other free UNIX) pre-installed on laptops? I realize it is quite possible to install Linux on most laptops myself, but I am just curious.
The concept of a storage hierarchy for computers goes well beyond just main memory and hard drives. For example, on the smaller/faster end of things there are SRAM caches on chips and motherboard; on the bigger/slower end of things there are tape and CD backups. I think that though it is tempting for a programmer to throw out the storage hierarchy ("Everything is fast and big! Yay!"), they are with us to stay and serve a verry useful purpose.
The current head of x86 developement at Intel, John Shen (I think that's his title, anyway) is a former professor here at CMU. Another professor of mine was talking with John some time ago, and John mentioned that several of the advanced features in IA64 -- such as the rotating register file mentioned elsewhere in the comments and predicated execution -- have made the Itanium a bear of a chip to implement. I for one am a little skeptical that Intel will be able to make a really fast processor out of this architecture any time soon.
I've been trying to find out if I am the fastest Minesweeper player in the world (a dubious honor at best). My best time on Expert level is 84 seconds. Obviously I can't prove that since no one was there, but can anyone report a lower time?
I posted this in the last story about this chip, but I think I was too late for anyone to notice, so I'll post it again.
This is an interesting architecture, but I don't think you'll see it in a personal computer any time soon. You have to program in one of two funky dataflow oriented languages to use this beast. The company says they will have a C compiler out by next year, but the job of mapping a C program onto an architecture like this efficiently is incredibly compilcated. I would be surprised if they managed to get 1/4 of the efficiency out of a complex algorithm written in C, vs. the same algorithm written in their own programming language.
I am currently involved in some research in which we are trying to solve the same problem, roughly. However, we are trying to make the change as transparent to users (i.e. compiler writers & assembly code writers) as possible by making small tweaks to the standard RISC concept that will allow our chip to extract large amounts of parallelism. It is clear that with these reconfiguration based architectures it is possible to have huge performance gains at the expense of programming complexity. Hopefully our architecture will be to these reconfigurable systems what superscalar was to VLIW. VLIW has been around for a long time, but it wasn't popularized until architects came up with ways of making a VLIW core look like a scalar processor to the outside world.
The probable reason why this chip and most massively reconfigurable chips have low clock rates is that they have huge tangles of internal routing to allow signals to flow from any internal point to any other point. Delay in modern processors is much more dependant on interconnect (wires) than devices (transistors), so all of this interconnect they need to achieve full reconfigurability causes long critical paths and low clock rates. The trick, as pointed out by the designers of the Remove and PipeRench architectures (both purely academic research efforts so far) is to provide enough local interconnect to allow a wide array of applications to run while limitting the interconnect to a allow the clock to run more quickly.
What I think it means is that the company does not plan to release an details about the architecture of the small internal processors. It's similar to Transmeta's chip: On the outside it looks like an x86 chip, but on the inside it's some funky VLIW architecture. They don't want people programming directly to the internal archtecture (i.e. it's proprietary), because it may/will change with each new chip.
Slashdot Mirror
Damn! I thought my 83 was pretty good.
I read the pdf linked in the article and was excited, because this proposal seems like it might actually work. I checked out the responses and was very irritated to find that the vast majority of the posters were objecting to things that weren't even in the proposal. I haven't read slashdot much recently, and I can really see what people mean when they say it's going to hell in a handbasket.
(And hopefully someone responded to your previous post in exactly this way, creating an ultra-tiple-decker dup.)
Benjamin
Hey Nick.
And maybe if I get off my ass, we'll have a nice language with which to program the things, too.
Benjamin
You're right that computer architecture is in for some big changes in the coming decades, but probably not in the ways that you expect. As some other posters pointed out, the RISC/CISC debate is over. The big problem is that all popular architectures are still structured around the idea of a single sequential instruction stream.
Computer architects have more transistors than they can shake a stick at now, but at some point it becomes impossible to accelerate a single RISC/CISC instruction stream by throwing more transistors at it. What we need are new architectures that are designed from the ground up for serious parallelism. I'm not talking about 4 or 8 parallel execution units, I'm talking about tens, hundreds, even thousands of instructions executing independently.
If you're interested in this sort of thing, I recommend checking out the ADAM architecture from MIT or the PipeRench architecture from CMU. Obviously, these ideas are not yet commercially available, but I expect that within 10 years we are going to see a major leap in the mainstream processor world to more highly parallel architectures.
Cheers,
Benjamin
The Cheat is to the Limit
I've written a compiler in Java and a compiler in SML (a language in the same family as Ocaml) and I promise you that it was MUCH easier in SML. And I didn't even have to use the imperative features in the main body of the compiler code.
If you are curious, I highly recommend Bob Harper's introduction to SML. If you read it with an open mind, it will open you up to a whole new world of programming. http://www-2.cs.cmu.edu/~rwh/smlbook/
Benjamin
Very simple example of proving that a program meets a high level spec, using SML:
{* pre-condition: n >= 0 *}
fun factorial 0 = 1
| factorial n = n * factorial(n - 1)
Proof that factorial correctly implements the factorial function, by mathematical induction on n:
base case (n = 0):
1) factorial 0 =? 0!
2) 1 =? 1 (good)
Inductive hypothesis: factorial (n - 1) correctly computes (n - 1)!.
Inductive step: prove that factorial(n) correctly computes n!.
1) factorial(n) =? n!
2) n * factorial(n - 1) =? n!
3) n * (n - 1)! =? n!
4) n! =? n! (good)
It might seem that you can do this sort of thing in any programming language. However, there are some important features of SML that make this a nearly complete proof, as opposed to just a good argument. To get from step 1 to step 2 we had to replace factorial(n) with n * factorial(n - 1). We can do this, because every call to a function with a given argument in purely functional code will return the same result. To get from step 3 to step 4, we should invoke the multiplication semantics from the Definition of Standard ML (I'm just too lazy to look up the page number). Most languages do not have such a formal definition.
I am currently working on a new circuit description language (in the same vein as Verilog and VHDL) for which I am implementing a compiler/simulator in SML. I plan on proving certain nice features -- like the simulation can never spin off into infinity -- that would be impossible to prove in most programming languages.
There are many functional-style languages that are not statically type safe. LISP is the most popular one. Java is a nearly type-safe language. There are some flaws in the Java type system that require runtime checks to ensure that the program doesn't go wrong. There is no such thing as a null pointer in any statically type safe language.
Benjamin
Some examples of what many "type-safe" language compilers can prove:
-A variable will always contain a value of the correct type. This contrasts with any language that allows casting from one type to another.
-Unallocated memory will never be accessed. This contrasts with any language that requires manual memory allocation.
-Given a particular input, a function will always return the same value. This contrasts with any language that allows memory store effects.
In addition to low level things that a compiler can prove about your program, formal languages also permit higher level proofs about the functionality of your program. A programmer can prove correct functionality for her program, as opposed to just testing it with lots of data and hoping that it will work in the future. If you are interested I highly recommend reading Bob Harper's Introduction to SML. His web page is http://www.cs.cmu.edu/~rwh. Scroll down to the bottom to his books section.
Benjamin
I was blending the architectural and linguistic domains, the way John Backus did in his seminal paper "Can programming be liberated from the von Neumann style?:a functional style and its algebra of programs". A small excerpt from that paper's abstract:
Conventional programming languages are growing ever more enormous, but not stronger. Inherent defects at the most basic level cause them to be both fat and weak: their primitive word-at-a-time style of programming inherited from their common ancestor--the von Neumann computer, their close coupling of semantics to state transitions, their division of programming into a world of expressions and a world of statements, their inability to effectively use powerful combining forms for building new programs from existing ones, and their lack of useful mathematical properties for reasoning about programs.
So you are correct; I was primarily talking about programming languages, not architectures. However, the two domains are closely related and most programmers use programming languages that are still primarily based on the semantics of the architecture on which they run.
Benjamin
There is a whole host of languages more "modern" than C, Java, C++, C#, Pascal, Ada, Perl, or any other of the essentially von Neumann-style languages out there. I highly recommend that anyone out there who is interested in advanced type-safe languages take a look at SML, O'Caml, Haskell or Clean. Most of these languages have more or less formalized language semantics (as in mathematically precise). Formal descriptions and strong type systems allow the compiler to *prove* (again, in a mathematically precise sense) that a program can not go wrong at run time.
Benjamin
If the literary range of slashdot readers is accurately represented by the postings to this story so far, most of you really need to break out of the SF rut once in a while. I'm not suggesting that SF books are inferior; just that there is a whole lot of great writing out there that is not in that category.
My nominations:
-Joseph Heller. After Catch 22 he didn't have much inspiration left, but Catch 22 is clearly one of the best American novels ever.
-Michael Chabon. I'm not nearly as confident about Chabon as I am about Heller, but some of his books are great reads and he's still in his 20's (I think).
Benjamin
> We need to fix the current problem, not dwell on how it came about.
I hope you are not responisble for making any important decisions. I am feeling very ambivalent about attacks on the Talbian. However, I am quite certain that fixing problems without understanding what caused them is no fix at all.
Benjamin
> Rote memorization isn't a sign of intellectual ability.
I disagree. I think most of us would agree that memorization and intelligance are not one in the same, but being able to remember individual bits of information is clearly one part of a well-functioning brain. I happen to be quite bad at remembering pieces of data, so it's unsurprising that I chose a field of study in which it is more important to be able solve problems than remember things. However, I would say there are professions in which it is incredibly important to be able to remember and recall lots of information quickly. For example, when a good lawyer looks at a case, he or she should be able to immediately recall some other related cases that set precedence that might be relevant.
Don't underestimate the importance of memory.
Cheers,
Benjamin
First, I think beauty is the wrong word to use. A bridge (or any other engineering project) can be beautiful without being terribly useful or reliable. I think we should be striving for high quality software. What is a simple way of writing more high quality software you ask? Stop using C, C++, or Java. Start using ML, Haskell, or Clean. Modern functional programming languages offer:
... An Experiment in Software Prototyping Productivity" and "Four-fold Increase in Productivity and Quality" for respectively an academic and industrial look at the productivity increase offered by functional languages.
1. Immutable objects
2. Higher order functions
3. Strong static type systems
4. No pointers
5. Garbage collected memory allocation system
All of these add up to shorter, much more reliable code. I know there are some people out there who will protest that any garbage collected language will be slow. This is simply false. Thanks to strong static typing and a formal semantic that permits easy reasoning about optimizations, ML family language compilers produce code that is almost always faster than Java code and quite possibly faster than C code that has not been hand optimized. For those who are interested take a look at "Haskell vs. Ada Vs. C++ vs. Awk vs.
The one area of computing that most functional languages are not particularly well suited for is low level system programming. However, there are researchers working on that, and how many of us do low level system programming?
Cheers,
Benjamin
> Every human activity obeys the rules of economics
This really depends on what you mean by the rules of economics. I agree that there are some fundamental principles about economic activity that can not be avoided. However, I don't believe that any human has a good quantitative understanding of exactly what these "laws of economics" are. In every economics text I have seen these principles are either ridiculously non-quantitative or unproven. When I say non-quantitative I am refering to things like supply-demand curves or the Laffer curve. Of course these models describe some reasonable economic activity, but no one knows exactly what their shape is and therefore can't use them to predict the outcome of individual events. I mean proven more in the mathematical and logical sense than the sociological sense.
When some people say the rules of economics they mean something far more mundane about how the Fed should control interest rates or how Wall St will react to this or that. To suggest that the people making these sorts of decisions are using fundamental laws the way a scientist at NASA would use gravity to figure out how to get a space craft to Mars is ridiculous.
To get back to the article, clearly nothing (Linux included) can break the first sort of economic law that I dicsussed. However, I think what Scot Hacker was refering to was more the second sort of economic law; the collected conventional wisdom about the way a software company (and specifically an operating system company) must operate to survive. This sort of law Linux most definitely does break by not being tied to any large established economic body.
Cheers,
Benjamin
> One advantage of C++, in my experience, is its
f _Wiger.pdf. Clearly there is a significant limit to the good and happiness that language choice can bring on any particular software project. However, I think a large portion of the application code running today would have been better off written in a functional language.
> support for multiple paradigms. C++ isn't an
> object-oriented programming language, or a
> functional programming language, or a procedural
> language -- but it allows me to use all of those
> paradigms as needed to accomplish a task.
There is a big problem with this attitude towards programming languages. One of the big advantages that many functional languages (and other carefully designed languages for that matter) have is that they have certain nice provable -- and in many cases proved -- properties that are a result of a tractable language definition. C++ is probably the best example of a totally intractable language and it is therefore impossible to say with mathematical certainty what a C++ program means. It is also a bit of a stretch to say that one can program functionally in C++. I understand that there are various contortions you can go through to get some of the features of functional languages, but it's still pretty far from ML or Haskell in my opinion.
I agree that object oriented programming is overrated by its adherants. However, I have seen a few programs that drew quite a bit of expressiveness from being written in an object oriented language. I don't think functional programming is as overrated as you appear to. I think it is quite remarkable what has been accomplished in functional languages (i.e. the Fox project at CMU (SML) or wireless switching software at Ericsson (Erlang)) with a fraction of the effort as has been expended on similar projects written in more traditional languages. An Ericsson employee recently wrote a paper about their experience with Erlang, with respect to productivity:http://www.erlang.se/publications/Ul
Benjamin
> Why do people get so worked up about one specific tool?
Coming from the functional programming camp I can tell you that SML, O'Caml, Haskell, Clean, etc. people tend to get so worked up because so much energy and time is put in to arguing about whether C, C++, Java or Perl is better. I believe that for a significant chunk of general application developement (i.e. not writing OSes, device drivers or shell scripts) good functional languages are years ahead of most popular languages in language design. One important advantage that many languages (especially Java) have over functional languages is that huge libraries of freely available code exist already. At my job I am forced to use Java for compilers and circuit simulators and synthsizers. I could write the same applications in SML (the functional language that I am most familiar with) in half the code with one quarter of the bugs and mathematically prove that important parts of my algorithms were correct.
Benjamin
For what it's worth, I have had only good experiences with group programming. However, I am still in school and all of my group programming experience has come from classes, not from work. I think one of the biggest potential gains from group programming is that it is much easier for a small group of people to think around a problem than a single person. If a single programmer runs into a problem for which he/she can't think of an elegant solution, he/she might decide to just give up or hack around it. However, with more than one person, ideas can be bounced around and it seems more likely that a reasonable solution will appear in less time. Given the extent to which programming is a process of solving lots of small problems, group programming seems like a big advantage to me.
Ben
Does anyone know if there are any companies planning on offering Linux (or any other free UNIX) pre-installed on laptops? I realize it is quite possible to install Linux on most laptops myself, but I am just curious.
Thanks,
Ben
The concept of a storage hierarchy for computers goes well beyond just main memory and hard drives. For example, on the smaller/faster end of things there are SRAM caches on chips and motherboard; on the bigger/slower end of things there are tape and CD backups. I think that though it is tempting for a programmer to throw out the storage hierarchy ("Everything is fast and big! Yay!"), they are with us to stay and serve a verry useful purpose.
Ben
The current head of x86 developement at Intel, John Shen (I think that's his title, anyway) is a former professor here at CMU. Another professor of mine was talking with John some time ago, and John mentioned that several of the advanced features in IA64 -- such as the rotating register file mentioned elsewhere in the comments and predicated execution -- have made the Itanium a bear of a chip to implement. I for one am a little skeptical that Intel will be able to make a really fast processor out of this architecture any time soon.
Ben
I've been trying to find out if I am the fastest Minesweeper player in the world (a dubious honor at best). My best time on Expert level is 84 seconds. Obviously I can't prove that since no one was there, but can anyone report a lower time?
Ben
I posted this in the last story about this chip, but I think I was too late for anyone to notice, so I'll post it again.
This is an interesting architecture, but I don't think you'll see it in a personal computer any time soon. You have to program in one of two funky dataflow oriented languages to use this beast. The company says they will have a C compiler out by next year, but the job of mapping a C program onto an architecture like this efficiently is incredibly compilcated. I would be surprised if they managed to get 1/4 of the efficiency out of a complex algorithm written in C, vs. the same algorithm written in their own programming language.
I am currently involved in some research in which we are trying to solve the same problem, roughly. However, we are trying to make the change as transparent to users (i.e. compiler writers & assembly code writers) as possible by making small tweaks to the standard RISC concept that will allow our chip to extract large amounts of parallelism. It is clear that with these reconfiguration based architectures it is possible to have huge performance gains at the expense of programming complexity. Hopefully our architecture will be to these reconfigurable systems what superscalar was to VLIW. VLIW has been around for a long time, but it wasn't popularized until architects came up with ways of making a VLIW core look like a scalar processor to the outside world.
We'll see.
Ben
The probable reason why this chip and most massively reconfigurable chips have low clock rates is that they have huge tangles of internal routing to allow signals to flow from any internal point to any other point. Delay in modern processors is much more dependant on interconnect (wires) than devices (transistors), so all of this interconnect they need to achieve full reconfigurability causes long critical paths and low clock rates. The trick, as pointed out by the designers of the Remove and PipeRench architectures (both purely academic research efforts so far) is to provide enough local interconnect to allow a wide array of applications to run while limitting the interconnect to a allow the clock to run more quickly.
Ben
What I think it means is that the company does not plan to release an details about the architecture of the small internal processors. It's similar to Transmeta's chip: On the outside it looks like an x86 chip, but on the inside it's some funky VLIW architecture. They don't want people programming directly to the internal archtecture (i.e. it's proprietary), because it may/will change with each new chip.
Ben