Basically, intel's merced (or whatever they've renamed it to) has two operating modes: a "native" or VLIW-style mode that takes raw EPIC instructions, and an x86 "emulation" mode that translates x86 style instructions on the fly. Merced actually has a special opcode just for switching between these modes. When merced starts up, so to speak, it starts in x86 emulation mode, so if your binaries are old, they'll work ok. Native code can be intermingled with x86 code simply by bracketing it with these opcodes telling it to switch to the proper mode.
Naturally, if you are just trying to use x86 binaries, this processor won't do much for you as far as horsepower, because it has to translate all those instructions, schedule them, etc.
However, by recompiling your code to run using "native" IA-64 instructions, you can get tremendous performance advantages. Native code basically goes straight into the pipeline. Due to the many advantages inherent in VLIW architectures, like (supposedly better) software scheduling, more functional units, etc., I think any native code should run quite well.
1. Yes, I have read Patterson, and yes, he is clear about the goal of reducing execution time for instructions.
2. I am not arguing CISC vs. RISC. I am saying many of the "design leaps" you refer to are infeasible using traditional CISC methods. It was the push towards reducing execution time per instruction in the 80's that made modern processor designs possible.
His main evidence is a quote wherein Ditzel is quoted as saying, "Superscalar and out-of-order execution are the biggest problem areas that have impeded performance [leaps]." Obviously the author has absolutely no knowledge of how processors work internally, or he wouldn't say that this is due to the complexity of the ISA (Instruction Set Architecture).
The complexity with superscalars is not in the ISA, but in the scheduling. At the most basic level, though, RISC instructions are used because it is (effectively) impossible to schedule CISC instructions for out-of-order execution.
The whole idea with RISC is to make instructions so basic that they can (almost) all be completed in a single processor cycle. In the article, he tries to refute this with a quote from Patterson, but the quote actually refutes the author's point, and the author is too blind to realize it. Twice in the quote Patterson refers to reducing the cycle time for each instruction, but the author says that's not Patterson's point.
Today's processors take the idea a step further, by trying to execute MORE than one instruction per cycle by providing multiple processing units (the thing that does the actual addidtion, subtraction, or whatever) which can execute instructions in parallel. However, instructions still need to be scheduled so that they can execute in parallel while preserving dependencies. The hardware that accomplishes this scheduling is complex.
IMHO VLIW is the way to go. With VLIW, you do the scheduling at compile time, and remove a lot of the complexity involved with hardware scheduling. Not only do you gain the possiblity of higher parallelism through an increased number of processing units (you can use the silicon previously reserved for the scheduling hardware), but you also can gain a little more since theoretically a complier can spend more time looking for dependencies between instructions, and come up with a more optimal schedule.
anyway, that's just my 2 cents.
other books by stephenson
on
Snow Crash
·
· Score: 1
FYI, Stephenson has also written several books with his uncle (I believe) under the pseudonym Stephen Bury. Of these, a book of particular interest to/. readers is Interface, which is kind of a sci-fi version of The Manchurian Candidate.
A book which I don't think many people other than myself have read, but which is extremely geeky, is called The Planiverse, by A.K. Dewdney.
Dewdney, being a CS professor himself, does a good job of writing an entertaining story ala Flatland, interspersed with little tidbits on 2D physics, physiology, architecture, and the like.
Also, I'm a fan of the early Hunter S. Thompson stuff, Shakespeare (talk about wit), and man pages.
Before we all go off M$ bashing, have any of you ever seen MainSoft's product? It's been around for a while, you know.
What MainWin does is make windows-developed applications work under UNIX OSes. They are not just runnable, they run exactly like they do under windows. This is a good thing for linux, because it means that companies (like mine, for instance) which must spend serious amounts of money to develop applications under WinNT or Win95/98 don't have to spend equal amounts of money to port those applications (along with all the specialized GUI features, like drag-n-drop, scripting host, etc.) to the various UNIX flavors. This means more applications that would normally never see the light of day on UNIX have the opportunity to grow into a real market there.
For my company in particular, this is a life-saving product. We simply do not have the extra resources to develop all that stuff on another OS.
However, that being said, I do feel that in some ways microsoft is trying to preserve its market by getting developers to choose M$ as a "common" platform. IMHO this won't work. We only use mainwin because we want to port a product previously targeted for the winnt market to the UNIX market. If we knew there would be this kind of demand on UNIX 3 years ago, we would have developed the product differently.
To begin with, I'd like to state that I disagree with the whole game rating system. However, given that it exists, and that there are whiny parents and activists out there, I do feel it is much better than not even selling these games in your walmart or whatever.
The problem is, in order for these people to feel secure, that have to feel that the system is working properly most of the time, and I have to say flat out, that I have never seen a kid getting carded when they bought one of the games marked "mature". Naturally, this will cause people who believe in the system to lose their faith, and they will make an outcry that we should just ban these games outright.
When carrying out an invocation, a SOAP client must first try the invocation using the M-POST invocation style.
...snip...
a) If using the M-POST verb, a mandatory extension declaration must be present that refers to the namespace "http://www.microsoft.com/protocols/ext/SOAP". For the purposes of this section, suppose that said declaration chooses to map the namespace to the header-prefix "01". If the POST verb is used, the namespace header-prefix is not used. For example, a MethodName header would have an M-POST value of "01-MethodName" and a POST value of "MethodName".
I guess this is microsoft's way of making sure they stay in the distributed object game for a while.
I know these might seem like flamebait, butI have 2 things to say about this:
In the "real" world, I have every right to buy some piece of crap plot of land on the chance that it will be worth some money some day. I don't have to develop on it, I just have to own it. Just because some company comes along later, and decides that plot would be the perfect place to build their new headquarters, doesn't make a difference. I should be able to sell that plot for as much as I can get, and not what I originally paid.
This seems to go back to the discussion of virtual property I recall that stemmed from the sale of castles, characters and such on eBay. What happens when a company decides it wants ownership of its trademarks in RPGs? Does Ford get the rights to my character because his name happens to be Taurus?
I wish I could have attended, if only to see the Japanese teams break down in tears when they lost. With AI being as pervasive as it is in Japan (the "focus where you look" cameras, rice cookers with fuzzy logic), one would think they would have had a better showing.
FPGAs with high gate counts (e.g. Flex 10kXXX series) are expensive, and physically quite large. The other problem involved with this is the compilers for FPGAs pretty much suck at laying out the wiring between gates. You end up with layouts that not only waste most of the space available on the FPGA, but are also an order of magnitude slower than you want. Don't get me wrong. FPGAs are great for prototyping, but for real speed, ASICs will always be the best.
Re:No need for watermarking people
on
DNA Encryption
·
· Score: 1
No, you're missing the point of watermarking. It's not just reading a person's unique ID and matching them, it's the ability to brand people/animals/whatever into categrories.
Everybody considered a "hacker", "gay", "lesbian", "christian", or whatever could be marked with the appropriate permanent brand.
What if a variant of herpes (or similar genetic disease) was created which would alter the recipient's DNA to carry this watermark?
Re:Nothing earth-shattering here
on
DNA Encryption
·
· Score: 1
I was thinking the same thing. In fact, I was wondering just how big the key space actually is. Since all one really has to do is figure out which markers are being used, the key space isn't the 30 billion they were talking about, but probably a more reasonable number which it might even be possible to break with distributed processing ala www.distributed.net
As far as the watermarking goes, that is not new technology at all. I remember reading the same stuff many years ago when researchers first started cloning mice. The scary question to me is: how do we know people, plants, animals, etc., aren't already being watermarked?
Slashdot Mirror
Basically, intel's merced (or whatever they've renamed it to) has two operating modes: a "native" or VLIW-style mode that takes raw EPIC instructions, and an x86 "emulation" mode that translates x86 style instructions on the fly. Merced actually has a special opcode just for switching between these modes. When merced starts up, so to speak, it starts in x86 emulation mode, so if your binaries are old, they'll work ok. Native code can be intermingled with x86 code simply by bracketing it with these opcodes telling it to switch to the proper mode.
Naturally, if you are just trying to use x86 binaries, this processor won't do much for you as far as horsepower, because it has to translate all those instructions, schedule them, etc.
However, by recompiling your code to run using "native" IA-64 instructions, you can get tremendous performance advantages. Native code basically goes straight into the pipeline. Due to the many advantages inherent in VLIW architectures, like (supposedly better) software scheduling, more functional units, etc., I think any native code should run quite well.
1. Yes, I have read Patterson, and yes, he is clear about the goal of reducing execution time for instructions.
2. I am not arguing CISC vs. RISC. I am saying many of the "design leaps" you refer to are infeasible using traditional CISC methods. It was the push towards reducing execution time per instruction in the 80's that made modern processor designs possible.
His main evidence is a quote wherein Ditzel is quoted as saying, "Superscalar and out-of-order execution are the biggest problem areas that have impeded performance [leaps]." Obviously the author has absolutely no knowledge of how processors work internally, or he wouldn't say that this is due to the complexity of the ISA (Instruction Set Architecture).
The complexity with superscalars is not in the ISA, but in the scheduling. At the most basic level, though, RISC instructions are used because it is (effectively) impossible to schedule CISC instructions for out-of-order execution.
The whole idea with RISC is to make instructions so basic that they can (almost) all be completed in a single processor cycle. In the article, he tries to refute this with a quote from Patterson, but the quote actually refutes the author's point, and the author is too blind to realize it. Twice in the quote Patterson refers to reducing the cycle time for each instruction, but the author says that's not Patterson's point.
Today's processors take the idea a step further, by trying to execute MORE than one instruction per cycle by providing multiple processing units (the thing that does the actual addidtion, subtraction, or whatever) which can execute instructions in parallel. However, instructions still need to be scheduled so that they can execute in parallel while preserving dependencies.
The hardware that accomplishes this scheduling is complex.
IMHO VLIW is the way to go. With VLIW, you do the scheduling at compile time, and remove a lot of the complexity involved with hardware scheduling. Not only do you gain the possiblity of higher parallelism through an increased number of processing units (you can use the silicon previously reserved for the scheduling hardware), but you also can gain a little more since theoretically a complier can spend more time looking for dependencies between instructions, and come up with a more optimal schedule.
anyway, that's just my 2 cents.
FYI, Stephenson has also written several books with his uncle (I believe) under the pseudonym Stephen Bury. Of these, a book of particular interest to /. readers is Interface, which is kind of a sci-fi version of The Manchurian Candidate.
A book which I don't think many people other than myself have read, but which is extremely geeky, is called The Planiverse, by A.K. Dewdney.
Dewdney, being a CS professor himself, does a good job of writing an entertaining story ala Flatland, interspersed with little tidbits on 2D physics, physiology, architecture, and the like.
Also, I'm a fan of the early Hunter S. Thompson stuff, Shakespeare (talk about wit), and man pages.
Before we all go off M$ bashing, have any of you ever seen MainSoft's product? It's been around for a while, you know.
What MainWin does is make windows-developed applications work under UNIX OSes. They are not just runnable, they run exactly like they do under windows. This is a good thing for linux, because it means that companies (like mine, for instance) which must spend serious amounts of money to develop applications under WinNT or Win95/98 don't have to spend equal amounts of money to port those applications (along with all the specialized GUI features, like drag-n-drop, scripting host, etc.) to the various UNIX flavors. This means more applications that would normally never see the light of day on UNIX have the opportunity to grow into a real market there.
For my company in particular, this is a life-saving product. We simply do not have the extra resources to develop all that stuff on another OS.
However, that being said, I do feel that in some ways microsoft is trying to preserve its market by getting developers to choose M$ as a "common" platform. IMHO this won't work. We only use mainwin because we want to port a product previously targeted for the winnt market to the UNIX market. If we knew there would be this kind of demand on UNIX 3 years ago, we would have developed the product differently.
To begin with, I'd like to state that I disagree with the whole game rating system. However, given that it exists, and that there are whiny parents and activists out there, I do feel it is much better than not even selling these games in your walmart or whatever.
The problem is, in order for these people to feel secure, that have to feel that the system is working properly most of the time, and I have to say flat out, that I have never seen a kid getting carded when they bought one of the games marked "mature". Naturally, this will cause people who believe in the system to lose their faith, and they will make an outcry that we should just ban these games outright.
From the SOAP specification:
When carrying out an invocation, a SOAP client must first try the invocation using the M-POST invocation style.
...snip...
a) If using the M-POST verb, a mandatory extension declaration must be present that refers to the namespace "http://www.microsoft.com/protocols/ext/SOAP". For the purposes of this section, suppose that said declaration chooses to map the namespace to the header-prefix "01". If the POST verb is used, the namespace header-prefix is not used. For example, a MethodName header would have an M-POST value of "01-MethodName" and a POST value of "MethodName".
I guess this is microsoft's way of making sure they stay in the distributed object game for a while.
Hemos, did you lose any computer equipment or gadgets? If so, my condolences.
If not, look on the bright side: it could have been your COMPUTER man!
I wish I could have attended, if only to see the Japanese teams break down in tears when they lost. With AI being as pervasive as it is in Japan (the "focus where you look" cameras, rice cookers with fuzzy logic), one would think they would have had a better showing.
FPGAs with high gate counts (e.g. Flex 10kXXX series) are expensive, and physically quite large. The other problem involved with this is the compilers for FPGAs pretty much suck at laying out the wiring between gates. You end up with layouts that not only waste most of the space available on the FPGA, but are also an order of magnitude slower than you want.
Don't get me wrong. FPGAs are great for prototyping, but for real speed, ASICs will always be the best.
No, you're missing the point of watermarking. It's not just reading a person's unique ID and matching them, it's the ability to brand people/animals/whatever into categrories.
Everybody considered a "hacker", "gay", "lesbian", "christian", or whatever could be marked with the appropriate permanent brand.
What if a variant of herpes (or similar genetic disease) was created which would alter the recipient's DNA to carry this watermark?
I was thinking the same thing. In fact, I was wondering just how big the key space actually is. Since all one really has to do is figure out which markers are being used, the key space isn't the 30 billion they were talking about, but probably a more reasonable number which it might even be possible to break with distributed processing ala www.distributed.net
As far as the watermarking goes, that is not new technology at all. I remember reading the same stuff many years ago when researchers first started cloning mice. The scary question to me is: how do we know people, plants, animals, etc., aren't already being watermarked?