I know that the University of Manchester was designing an asynchronous Arm-binary compatable processor (here). Now that is has been shown to be feasable to do RISC in asynch, maybe big vendors will start to take notice.
A bit of (greatly simplified) background for those who havn't looked into this. The huge decrease in asych power consumption (at least using CMOS) is becasue the MOSFETs discipate (sp?) power during voltage level changes. Many transisters in sychronous chips change state every clock pulse, but changes are much more isolated in asynchrouns chips. I predict (in my infinite wisdom, and using my crystal-ball-of-infinite-wisdom) that RISC based asynch will get much more powerful and fast as companies like Intel, Motorola, etc put more money into reasearching this previously forgotten/niche field.
Probably they'll only be used in portable systems at first to conserve power, but maybe if design techniques progress, we'll see them in desktop PCs or even some heavy metal systems within 10 years or so as other benifits becom apparent... But even my crystal-ball can't say for sure.
-- below is opinion, don't read it if you're an easilly offended Republican or supporter thereof as you may be unintentionally offended - damn -1 flaimbait modders... --
I wouldn't count on much (US) government research money or grants going into it while Bush is president though... I don't exactly think he's interrested in energy conservation...
One of the suptleties (spelling?) of customer support is rarely, if ever, taught in training. Try to avoid saying "sorry" to the customer. Even if they "are always right" the instant you say "sorry" it is a psycological jump in the customer's mind, that you admitted that you (either personally, or as a representative of the company) are wrong.
I know tonnes of people in support/service who only figured this out after 6 months or more on the job, and it makes the tech-support job a lot less stressful (which in turn makes finding solutions quicker, and happier customers). Customers are not your enemy, but a customer who has spent the last 10 hours trying to fix something will be stressed-out at least, and may be looking for an excuse to take it out on you. This is especially true when dealing with end-users or individual software licencees. Sysadmins, or those dealing with software on a network are usually a) more computer literate and b) know that there are things that go wrong, that one cannot plan for. These people are likely to be a lot more patient with you, and therefore you should extend them the same courtousy.
I don't have any links or data to back this up, but I was under the impression that several years ago AMD designed around the x86 architecture to avoid paying Intel royaltees.
I mean they used the same instruction set to input instructions and data, but by converting the x86 machine code into an internal machine code, they avoided directly implementing a x86 processor (although they did implement a translator) and thus (as a judge ruled, I recall) avoided patent infringment. Like I said, I wish I had an article to back this up.
In another matter how is it that the PIC is patentable? The article is plenty scant on technical details, but I got the impression that it was just a fancy term for pipelining, which has been around in supercomputers for 25-30 years. Does anyone out there know if PIC is some sort of new, exceptionally novell way of pipelining, or is it just another example of the patant office issuing a "you are the only one allowed to use this incredibly simple, obvious technique, that half the industry uses already."
Don't get me wrong, I'm not a big Intel fan, but still...
Personally I'm a big fan of separating the UI and the rendering engine into two separate programs. *nix has been doing this forever, but I'm starting to see it more and more on Windows/Mac as well.
The great advantage specifically for a 3D modeler/renderer is that you can do up the UI (and yeah, you get to have fun writing 3D routines for displaying the wireframe or solid modeled for display to the user) but you can then program to output in a known format (and take care of one of your "export" filters at the same time), and have a 3rd party renderer take care of the messiness for you. Once you're happy with how the UI works, you can write your own renderer if you still feel up to it.
The disadvantage with writing it either all-at-once (or writing only the renderer first) is that you can't test things nearly as quickly. Let's say you hammer out 3M lines of code, open the UI window, model a sphere, assign a texture, click the "render" button, and you end up with a black window. Did the sphere not get modeled? Was there an issue passing it to the renderer? Did the renderer mess up with the texture? Does the UI for some reason pass all objects as coloured perfectly flat black?
As for all those who say "why are you doing this, there are all ready free renderers", screw 'em. Sometimes it's fun to play areound and design/code a massive app just for the hell of it, right. Although, these massive apps rarely get completed...
isn't the force two objects excert on eachother called gravity?
seriously though, I wonder how these forces are effected by non-vacumes - i.e. a virtual vacume with one lonely hydrogen moluecule. Is the H2 excerting forces on the two mirrors? are these forces the same magnitude as that the mirrors excert on eachother in pure vacume? more? less? 1/distance squared?
Mostly for speed. Let's review our 1st year digital electronics course. Since computer operations (at least in modern-day chips) are done on the binary level, storing in 32/64/whatever bits levels would require whatever portion of the system is reading the memory block to convert this one psudo-bit (for lack of a better term) to digital before processing. This is equavilent to (for example) sampleing audio data (taking the voltage produced by a microphone or similar device, and converting it to 8/16/24 bits).
In addition to requireing extra circuitry for decoding, this would require extra time. If you're wondering why CPUs don't just use various (16/32/64/whatever) voltage levels internally, then you really need a refresher course.
Transistor -> voltage controlled current source. i.e. a transister (in most cpus, these are nmos/pmos pairs) will either be "conducting" or "not conducting" a current depending on voltage level at the gate. Although technically these conducting/non-conducting will have slightly different currents flowing though them, we cannot use these as various voltage levels for the next transister because we get into all sorts of matching problems, fan-in/out problems, and basically (for example) the number "26" would be represented by one voltage level here, a different one there, and another one based on what transisters or conducting, and how much. If you're wondering why we don't use resisters to solve some of these problems, you REALLY need to review - power dicipated = current * current * resistance = heat. 20B currents squared * 20B resistances = instant chip incineration.
As a side note (actually two side notes) I beleive in the 40s they were experimenting with computers which used 10 voltage levels because that was the natuaral thing to do, until someone suggested using binary/boolean value which until that time were just a mathmatical curiosity than a dicipline taken seriously. I don't have references on hand ot back this up, but I think i remember reading something to that effect. The other side note is that many modems (even today) use variable-level voltages ot communicate. This is because the speed limiting factor effecting modems is line quality and length. It takes a relativly long time to force the line to any particular voltage, and so the modem makes these voltages count by encoding multiple levels. Ex. 9600bps modem uses 12 phase angles, four of which have two voltage levels, alowing to transmit 16 bits in one cycle (Stallings, Data & Computer Communications, 6th, p145). This is also why some modems (ex 56k) will only connect at (ex) 24k if excessive line noise prevents reliable encoding on many voltage levels.
The second reason we don't use variable levels in memory storage is error control. 1/0 values are screwed up enough by line noise, magnetic fields, and what have you. Imageine how difficult a time a machine would have dtermining "is that atom 23456 picometers about the base or 23457?"
As photonics emerges as a network technology though, I'm wondering if there is something like a "photo-transister" that will block or allow passthrough of light if light is present at a gate of a certain wavelegth. I know extreamly little about photonics, but if this possible then maybe multiple bits can be transmitted via multiple wavelengths inside a light-based (as opposed to electricity based) processor. Anyonw working on something like this?
After reading that last comment, one thing that I realize I was a bit ambiguous on (should've used the Preview button...) was that although the heating is done almost instantanously with a laser, my real concern is the maximum temperature that the disk reaches, and the heat diccipation over time. As the old electical/comp engineering saying goes (and it is rarely wrong) "heat sucks".
An ideal form of government is democracy tempered with assasination -- Voltair
Whaile it's fun for marketers to create ackronyms that sound cool (although I don't know how AMD lawyers will feel) I have one wuestion about this HAMR technology.
When they say "heat assisted" do they mean they must acutally heat the metal on the disc to allow recording onto the surface?
It has been known for a long time that heat can destroy magnets (you melt the magnetic metal, get all the particals moving and oriented randomly, let's hear it for entropy...) so it makes sense that heating portions of the platter can make magnetism or demagnetism quite a bit easier. But how hot do you have to heat the surface? Does this head dicipate around the portion trying to be written, and affect portions near it? How fast can this drive be (will we have to wait for cool-down)? If speed is an issue will this be a solely archival device, and is it actually usable for contant operation? How does heating affect lifetime of the unit?
Just food for thought.
An ideal form of government is democracy tempered with assasination -- Voltair
How many posts can be made about "conversion from lossy format x to lossy formay y means you get the worst aspects of both"?
Yes, conversion from an mp3 to ogg will reduce quality, but chances are you won't notice it. I don't have numbers to back this up, but I would be extreamly surprised if 2% of people could tell the difference between a cd->mp3->ogg file vs a cd->ogg file. Remember those calculus classes all you engineers had to take? Remeber the Fornier transform? Mp3 saves space by removing data that humans can't hear anyway.
Sorry if this sounds like flame-bait but it's already been pointed out that a 3db increase in sound level more than compensates for huge technical quality losses.
Take for example the HP Photoret III printers (930, 960, Photosmart 1200 and many, many more) verses the Kodak (Lexmark) photo printers. When I was selling these, the same digital printer was printed on the same paper, using brand new ink cartridges to compare the printers to clients. The HP quality was great, while the Kodak looked pixilated. None the less, the colors from the Kodak were more intense, and clients almost always bought the Kodak. (good for me - I made slightly more profit on those:)
Anyway, same with music. Even if you can tell the difference in two samples which theoretically sound different only to dogs, a slight increase in volume makes more of a difference to the human ear, and percieved sound quality.
And in the end arn't you really looking for what sounds the best to you?
In conclusion stop gabbing back and forth with "do I lose quality in conversion", "yes, don't do it", "why", "because", "oh", "yeah" and so on. If you're reading this last line, you know the facts, now make up your friccin mind and quit cluttering the message board.
p.s. I am aware that by posting I am just re-hashing infromation and cluttering up the message board, so don't bother pointing it out. You'll just add more clutter... jk
I hate to be a "me-too", but this is the first opinion piece I've seen on/. for a while that I agree with.
Having said that, I would like to comment that SGI has not only been good by not suing people (GNU/Linux/OSC notably, but others as well) but if I'm not mistaken they actually invest in patents and standards like GL with the before-hand knowledge that their IP is going to be used by others.
To me, this makes them one of the best corporate citizens in this industry where many areas are only seen as "grey" by the law because there is no precendent to see them as "black".
Although a number of posts about this topic (and other similar topics, especially involving Microsoft and the seeming un-willingness of most the major governments in the world) about how unfair current practices are, I think that most people agree that the situation is not going to change signifigantly in the next few years at least.
Having said that, I started thinking about a book I reak a couple of months ago (Birds of Prey by Wilbur Smith, great book) which took place in the 17th century and which cited certain practices of "law" by governing bodies at that time period. And you know what? Comparativly we're not that bad off. At least now (in most parts of the world) people are actually allowed to do stuff like present a defence at trial rather than the judge having you flogged for opening your mouth while the trial is proceeding.
Maybe in another couple hundred years everyone will enjoy equal treatment under the law, but right now money talks, and there's nothing to be done about. I'm not saying stop trying and fighting for fairness, but don't expect too much.
Just a disclaimer -- I'm not usually this cynical. I need beer.
Despite the marketing problems associated with clockless machines (as a one-time computer retail sales guy, it was easy to talk a 1st-time-buyer into upgrading from the 800MHz system for the identical 900MHz for $50 difference) there are some other asynchronis aspects which may throw a wrench into design.
First, if the chip is asynchronous, there must be a way to signal that the chip is ready for the next instruction - i.e. a "ready" line. Similarly since everyonw is pumped about the chips coming out in the last few years which execute multiple instructions simutaneously in different parts of the chip (think pipelines) there would have to be several of these signal lines. This will require additional logic circuits simply to decode these lines and figure out what instuctions can be executed, where they can, when they can, and so on. A related problem occurs with large, time consuming instructions which require the majority of the chip to execute. It would be difficult to implement a system which is by its nature asynchronous with a system of semaphores and time-estimating logic.
And how much faster would this type of design actually be than a RISC based chip with a fast floating point unit. Since flops are typically the operation bottleneck in a new breed of processor, are we really saving time?
I realize that the whole presumption of an asynchronous chip is that in traditional clocked chips we have to wait a finite amount of time (usually determined by the most complex operation) for every cycle, even if the op can be completed in less time. But personally I don't think that we'll see these on the market for at least ten years (well... maybe in a few microcontrollers, but only for really, really specialised tasks). Still it's good to see a few novel ideas (or in this case applying an old idea on a completely different scale) in this industry of re-packaging buzzwords.
Slashdot Mirror
A bit of (greatly simplified) background for those who havn't looked into this. The huge decrease in asych power consumption (at least using CMOS) is becasue the MOSFETs discipate (sp?) power during voltage level changes. Many transisters in sychronous chips change state every clock pulse, but changes are much more isolated in asynchrouns chips. I predict (in my infinite wisdom, and using my crystal-ball-of-infinite-wisdom) that RISC based asynch will get much more powerful and fast as companies like Intel, Motorola, etc put more money into reasearching this previously forgotten/niche field.
Probably they'll only be used in portable systems at first to conserve power, but maybe if design techniques progress, we'll see them in desktop PCs or even some heavy metal systems within 10 years or so as other benifits becom apparent... But even my crystal-ball can't say for sure.
-- below is opinion, don't read it if you're an easilly offended Republican or supporter thereof as you may be unintentionally offended - damn -1 flaimbait modders... --
I wouldn't count on much (US) government research money or grants going into it while Bush is president though... I don't exactly think he's interrested in energy conservation...
I know tonnes of people in support/service who only figured this out after 6 months or more on the job, and it makes the tech-support job a lot less stressful (which in turn makes finding solutions quicker, and happier customers). Customers are not your enemy, but a customer who has spent the last 10 hours trying to fix something will be stressed-out at least, and may be looking for an excuse to take it out on you. This is especially true when dealing with end-users or individual software licencees. Sysadmins, or those dealing with software on a network are usually a) more computer literate and b) know that there are things that go wrong, that one cannot plan for. These people are likely to be a lot more patient with you, and therefore you should extend them the same courtousy.
I mean they used the same instruction set to input instructions and data, but by converting the x86 machine code into an internal machine code, they avoided directly implementing a x86 processor (although they did implement a translator) and thus (as a judge ruled, I recall) avoided patent infringment. Like I said, I wish I had an article to back this up.
In another matter how is it that the PIC is patentable? The article is plenty scant on technical details, but I got the impression that it was just a fancy term for pipelining, which has been around in supercomputers for 25-30 years. Does anyone out there know if PIC is some sort of new, exceptionally novell way of pipelining, or is it just another example of the patant office issuing a "you are the only one allowed to use this incredibly simple, obvious technique, that half the industry uses already."
Don't get me wrong, I'm not a big Intel fan, but still...
The great advantage specifically for a 3D modeler/renderer is that you can do up the UI (and yeah, you get to have fun writing 3D routines for displaying the wireframe or solid modeled for display to the user) but you can then program to output in a known format (and take care of one of your "export" filters at the same time), and have a 3rd party renderer take care of the messiness for you. Once you're happy with how the UI works, you can write your own renderer if you still feel up to it.
The disadvantage with writing it either all-at-once (or writing only the renderer first) is that you can't test things nearly as quickly. Let's say you hammer out 3M lines of code, open the UI window, model a sphere, assign a texture, click the "render" button, and you end up with a black window. Did the sphere not get modeled? Was there an issue passing it to the renderer? Did the renderer mess up with the texture? Does the UI for some reason pass all objects as coloured perfectly flat black?
As for all those who say "why are you doing this, there are all ready free renderers", screw 'em. Sometimes it's fun to play areound and design/code a massive app just for the hell of it, right. Although, these massive apps rarely get completed...
isn't the force two objects excert on eachother called gravity? seriously though, I wonder how these forces are effected by non-vacumes - i.e. a virtual vacume with one lonely hydrogen moluecule. Is the H2 excerting forces on the two mirrors? are these forces the same magnitude as that the mirrors excert on eachother in pure vacume? more? less? 1/distance squared?
9600bps:
12 phase angles, 4 of which have two voltage levels -
8log2 = 3
4log2 * 2 = 4
meaning 9600 sending 7 bits at a time, not 16...
In addition to requireing extra circuitry for decoding, this would require extra time. If you're wondering why CPUs don't just use various (16/32/64/whatever) voltage levels internally, then you really need a refresher course.
Transistor -> voltage controlled current source. i.e. a transister (in most cpus, these are nmos/pmos pairs) will either be "conducting" or "not conducting" a current depending on voltage level at the gate. Although technically these conducting/non-conducting will have slightly different currents flowing though them, we cannot use these as various voltage levels for the next transister because we get into all sorts of matching problems, fan-in/out problems, and basically (for example) the number "26" would be represented by one voltage level here, a different one there, and another one based on what transisters or conducting, and how much. If you're wondering why we don't use resisters to solve some of these problems, you REALLY need to review - power dicipated = current * current * resistance = heat. 20B currents squared * 20B resistances = instant chip incineration.
As a side note (actually two side notes) I beleive in the 40s they were experimenting with computers which used 10 voltage levels because that was the natuaral thing to do, until someone suggested using binary/boolean value which until that time were just a mathmatical curiosity than a dicipline taken seriously. I don't have references on hand ot back this up, but I think i remember reading something to that effect. The other side note is that many modems (even today) use variable-level voltages ot communicate. This is because the speed limiting factor effecting modems is line quality and length. It takes a relativly long time to force the line to any particular voltage, and so the modem makes these voltages count by encoding multiple levels. Ex. 9600bps modem uses 12 phase angles, four of which have two voltage levels, alowing to transmit 16 bits in one cycle (Stallings, Data & Computer Communications, 6th, p145). This is also why some modems (ex 56k) will only connect at (ex) 24k if excessive line noise prevents reliable encoding on many voltage levels.
The second reason we don't use variable levels in memory storage is error control. 1/0 values are screwed up enough by line noise, magnetic fields, and what have you. Imageine how difficult a time a machine would have dtermining "is that atom 23456 picometers about the base or 23457?"
As photonics emerges as a network technology though, I'm wondering if there is something like a "photo-transister" that will block or allow passthrough of light if light is present at a gate of a certain wavelegth. I know extreamly little about photonics, but if this possible then maybe multiple bits can be transmitted via multiple wavelengths inside a light-based (as opposed to electricity based) processor. Anyonw working on something like this?
Anyway, I hope this helps!
KeggInKenny
An ideal form of government is democracy tempered with assasination -- Voltair
When they say "heat assisted" do they mean they must acutally heat the metal on the disc to allow recording onto the surface?
It has been known for a long time that heat can destroy magnets (you melt the magnetic metal, get all the particals moving and oriented randomly, let's hear it for entropy...) so it makes sense that heating portions of the platter can make magnetism or demagnetism quite a bit easier. But how hot do you have to heat the surface? Does this head dicipate around the portion trying to be written, and affect portions near it? How fast can this drive be (will we have to wait for cool-down)? If speed is an issue will this be a solely archival device, and is it actually usable for contant operation? How does heating affect lifetime of the unit?
Just food for thought.
An ideal form of government is democracy tempered with assasination -- Voltair
How many posts can be made about "conversion from lossy format x to lossy formay y means you get the worst aspects of both"?
Yes, conversion from an mp3 to ogg will reduce quality, but chances are you won't notice it. I don't have numbers to back this up, but I would be extreamly surprised if 2% of people could tell the difference between a cd->mp3->ogg file vs a cd->ogg file. Remember those calculus classes all you engineers had to take? Remeber the Fornier transform? Mp3 saves space by removing data that humans can't hear anyway.
Sorry if this sounds like flame-bait but it's already been pointed out that a 3db increase in sound level more than compensates for huge technical quality losses.
Take for example the HP Photoret III printers (930, 960, Photosmart 1200 and many, many more) verses the Kodak (Lexmark) photo printers. When I was selling these, the same digital printer was printed on the same paper, using brand new ink cartridges to compare the printers to clients. The HP quality was great, while the Kodak looked pixilated. None the less, the colors from the Kodak were more intense, and clients almost always bought the Kodak. (good for me - I made slightly more profit on those :)
Anyway, same with music. Even if you can tell the difference in two samples which theoretically sound different only to dogs, a slight increase in volume makes more of a difference to the human ear, and percieved sound quality.
And in the end arn't you really looking for what sounds the best to you?
In conclusion stop gabbing back and forth with "do I lose quality in conversion", "yes, don't do it", "why", "because", "oh", "yeah" and so on. If you're reading this last line, you know the facts, now make up your friccin mind and quit cluttering the message board.
p.s. I am aware that by posting I am just re-hashing infromation and cluttering up the message board, so don't bother pointing it out. You'll just add more clutter... jk
Having said that, I would like to comment that SGI has not only been good by not suing people (GNU/Linux/OSC notably, but others as well) but if I'm not mistaken they actually invest in patents and standards like GL with the before-hand knowledge that their IP is going to be used by others.
To me, this makes them one of the best corporate citizens in this industry where many areas are only seen as "grey" by the law because there is no precendent to see them as "black".
Although a number of posts about this topic (and other similar topics, especially involving Microsoft and the seeming un-willingness of most the major governments in the world) about how unfair current practices are, I think that most people agree that the situation is not going to change signifigantly in the next few years at least.
Having said that, I started thinking about a book I reak a couple of months ago (Birds of Prey by Wilbur Smith, great book) which took place in the 17th century and which cited certain practices of "law" by governing bodies at that time period. And you know what? Comparativly we're not that bad off. At least now (in most parts of the world) people are actually allowed to do stuff like present a defence at trial rather than the judge having you flogged for opening your mouth while the trial is proceeding.
Maybe in another couple hundred years everyone will enjoy equal treatment under the law, but right now money talks, and there's nothing to be done about. I'm not saying stop trying and fighting for fairness, but don't expect too much.
Just a disclaimer -- I'm not usually this cynical. I need beer.
Despite the marketing problems associated with clockless machines (as a one-time computer retail sales guy, it was easy to talk a 1st-time-buyer into upgrading from the 800MHz system for the identical 900MHz for $50 difference) there are some other asynchronis aspects which may throw a wrench into design. First, if the chip is asynchronous, there must be a way to signal that the chip is ready for the next instruction - i.e. a "ready" line. Similarly since everyonw is pumped about the chips coming out in the last few years which execute multiple instructions simutaneously in different parts of the chip (think pipelines) there would have to be several of these signal lines. This will require additional logic circuits simply to decode these lines and figure out what instuctions can be executed, where they can, when they can, and so on. A related problem occurs with large, time consuming instructions which require the majority of the chip to execute. It would be difficult to implement a system which is by its nature asynchronous with a system of semaphores and time-estimating logic. And how much faster would this type of design actually be than a RISC based chip with a fast floating point unit. Since flops are typically the operation bottleneck in a new breed of processor, are we really saving time? I realize that the whole presumption of an asynchronous chip is that in traditional clocked chips we have to wait a finite amount of time (usually determined by the most complex operation) for every cycle, even if the op can be completed in less time. But personally I don't think that we'll see these on the market for at least ten years (well... maybe in a few microcontrollers, but only for really, really specialised tasks). Still it's good to see a few novel ideas (or in this case applying an old idea on a completely different scale) in this industry of re-packaging buzzwords.