Summary claims 350C for traditional silicon, but most silicon based transistor manufacturers list only 125C as the maximum junction temperature. (Which makes the package temp max out at 70-85C.) Makes me question how fast and loose the author was playing with the numbers. Article starts with 600C for SiC, but in the same paragraph they are down to 500C for only < 2000hrs of operation? Hype?
Also, do SiC transitors switch as fast as doped silicon? Otherwise the "make a pentium with it!" ideas might fall flat.
Fertilizer is more about giving the plants nitrogen, potasium, and phosphorous than energy from chemical bonds. They get their energy from fusion 8 minutes away. We're after the chemical bond energy in the form of C-H bonds. The plants can have the rest back.
The Econ 101 word you are looking for here is "elasticity." Gas is an extremely inelastic good. Demand does not fluctuate (much) with price compared to other goods. Of course if you get to Econ 202 there may be a time domain component. I still have to get to work tomorrow and so will pay the price, but next year when I buy a new car, I may look more favorably on that Mini where I'll be buying less every tank from then on.
Except that storage is one of the major hurdles that needs to be over come to use hydrogen.
With this, the car's power source has been decoupled from our choice of power supply. We can use what ever source for energy to turn the 2Al2O3 back into 4Al + 3O2. Today we can use coal burning plants for the electricity, tomorrow nuclear, the next day solar and wind, the next fusion. You don't need to upgrade your car every time we invent (and/or make economical) a cleaner power source.
Dude, way to completely misrepresent their arguments. The lag you refer to is due to CO2 indeed being a feedback on the order of 1000s of years to other (unspecified) sources of temperature rise. (And being a + feedback, it amplifies the primary factor.) But what we are dealing with today is a rapid rise in CO2 on the order of 100s to 10s of years demonstrably caused by man, not temperature rise. On this timescale, CO2 is indeed a forcing. All else equal (and on this timescale it is) CO2 effecting temp (at least for first-order effects) comes straight out of basic physics and has been known since late 1800s.
Also, the BIG point left out by the original poster: it doesn't matter to the current debate if cosmic rays can alter the Earth's climate since the level of cosmic rays has been measured as constant over the period in dispute.
No scientist was predicting "freezing to death", nor were any peer-reviewed journals publishing articles to this effect. The "1970's prediction of an iceage" myth is based on two media articles by National Geographic and Newsweek where the journalists got their science wrong (more so in Newsweek.)
This is myth is keept alive by the likes of George Will (a fairly respectable conservative on most other topics) and that "expert" Michael Crichton.
The only thing close was the discovery in the 1970's of teperature variations with a periodicity of 20000 years. Well below the time scale of anthropogenic warming (on order of decades to 100s of years.)
Well technicaly this video is a form of propeganda. Then again, so is the original Oxfam video. Propeganda is an extremely broad category and doesn't always have to mean dissembling or promoting falsehoods. Unfortunately the word 'propeganda' has lost it's neutrality in the modern lexicon and often has negative conotations for people.
Propeganda is merely an attempt to sway a group's opinion through communication. "Getting your message out." That message can be truthful or lies, honest or deceptive, present all facts or cherry pick; it just needs to be pursuasive. I think sometims the negative connotation actualy discourages non-deceptive propeganda from more honest parties because they feer being accused of engaging in 'propeganda'.
TCP only matters at the endpoints, which presumably they control. If TCP is causing problems, use something else or invent something better to shove in the IP payload. Now if there is a problem at the IP layer of the protocol stack then, yes, your're SOL if you want to use the internets.
D.C. is on a silly zone system rather than any rational a*time+b*distance formula. Trips accross town depend on how many zones you drive through. And guess who gets to pick the route? Yep, the cabbie. So he's bassicaly doing a min-max of the most zones he can drive through that isn't obviously going backwards while keeping the time down so he gets more fares. The end result is that trips between the same point can cost different customers WILDLY different ammounts.
And grid cities can still be confusing when you throw in one way streets, diagonal streets (all the state named avenues in DC), streets that don't exist for one or more blocks then start up again, traffic circles, traffic sqares, etc. But don't blame us, DC was laid out by a Frenchman.
Except that other consumers' buying habbits (inattention to quality for small ++ in price) place me in the "long tail", where it's no longer worth ANY manufacurers time/effort to meet my demand. So I end up with 'crap' or 'nothing' because the manufactures who would have sold me a higher quality item for slightly more money went under last Tuesday.
Markets aren't 100% efficient and only support a finite # of suppliers. They often can support fewer suppliers than there are permutations of consumer demand. The lament isn't that there are no suppliers willing to take an unprofitable stance on a small market segement. The lament is that other conusmers have made the "quality" demographic too small to support through shortsightedness that actualy costs them more in the long run to boot.
Soon the number of cores in my desktop machine will surpass the number of blades in my shaving razor.
But seriously, as it gets harder and harder to make larger CPUs run faster the trend is going to be more, smaller processors per die. Each core is by itself slower than a huge monolithic one, but the sum is greater thanks to non-linear scaling. The trick is getting software to efficiently utilize them all.
This king of write-once memory model is called I-Structures. In the full implementation on some dataflow processors, you can actualy create the reference to an empty I-structure and pass it before you write to it. The reader will block until the write takes place. By the way you can't do this if each process has its own virtual memory space. The cost, as another poster mentioned is that modifying (even sligtly) large data structures is expensive. You're basicaly doing the memory copy before the pass. Imagine a process that adds +1 to a few elemetnts of an array, it has to copy the hole damn thing.
As for ease of programing another poster mentioned. I think viewing a parallel application as data passed/flowing from node to node in a graph is easy to conceptualize, especialy for multimedia or server applications. However most programers are taught C first and then taugh some bastardization that lets them explicitly spawn threads in the same memory space, with things like semaphores, etc. for safety and synchonization. It is extremely difficult to rationalize about correctness when programing that way since you have to either conservatively synch every step (not verry parallel) or convince yourself the app is safe under every possible read/write ordering of ALL the threads. They need to be taught languages that are safe from the get-go.
The problem with the asynch message passing method is that you have to explicitly send/copy your data to the next process, which causes the bandwidth to skyrocket. (Better to pass by reference, with some mechanism to ensure the producer can't make more modifications after the consumer process gets the pointer.)
Actualy what you described is a very specific instance of dataflow programs, where the flow can best be described by a directed "dataflow" graph. Technicaly macrodataflow since you pass data between processes; true dataflow reduces the granularity all the way down to individual instructions passing each other operands.
The reason "applications naturally parallelize" is because the language is forcing the programer to be explicit about the parallelism, something that doesn't come naturaly to your Freshman CS101 coder. Imperative languages like C, Fortran, Java, etc. that students are taught first are geared towards von Neumann machines and are incredebly hard for the compiler to parallelize.
Interestingly, functional languages like you mentioned (also try 'Id') map quite well to dataflow. This is directly due to their lack of side effects (i.e. manipulating structures in memory, which must be inherently sequential in order for the programer to reason well about program correctness.)
Dataflow had a lot more following in the 80s and early 90s. One problem was actualy an explosion of too much parallelism exposed in the application, more than the functional units could handle. The overflow then had to be shuttled back and forth to memory, making the aps bandwidth limited. Look at the MIT TTDA, Monsoon, *T, TERA, TAM, WaveScalar, and other projects. The ability to put many functional units (cores) and sufficient memory to keep them fed on a single die recently (last 5 years) reduces this limit and may allow the field to have a bit of resurgance.
Turns out that you can make an asynch circuit 'safe' to almost all race conditions if you design it properly. In our undergrad class, we made almost no assumptions about propegation time or which gate was 'first', yet still had to be provably correct (via 2^n brute force simulation, which only works for smallish blocks.)
The only timing assumption that had to be made was "isochronous forks" i.e. that if two gates saw the same input (i.e. were tied with the same wire from a common output) then they both 'see' the input before their outputs can have any effect on the other gate with the same input. So for example if a transition to a '1' at an OR gate input simultaneously causes some other gate to set the OR's second input from '1' to '0', there would be no glitches. The prof proved that this assumption is needed to do any usefull calculations. Wire speed.lt. gate speed is an easy condition to meet for most technologies.
So then as long as the design is segmented into lots of small, verifiable components, you can define a safe, 4-phase handshake that has no race conditions between blocks so the whole design is safe. You still have to check for deadlock conditions. The drawback is that to do the handshaking you have to use two wires per bit, which essentialy doubles your transistor count. "00" = no data, "01" = 0, "10" = 1, "11" can't happen. This gets arround the problem of a fast "valid" flag arriving before slow data is metastable.
I took an undergrad class on asynchronous chip design back in 2000. The class project was to implement the ARM7 instruction set (well, most of it) in about 5 weeks. We split it up into teams doing the Fetch, Decode, Reg file, ALU, etc. The nice thing about asynch is that as long as you have well defined, four phase handshaking between blocks you don't have to wory about global timing (there is no global "time" reference!). We were able to get it mostly done in those 5 weeks. Nothing manufacturable, and not tuned for performance, but we could simulate execution.
One of the neatest things about asynch processors is their ability to run in a large range of voltages. You don't have to worry that lowering the voltage will make you miss gate setup timing since the thing just slows down. Increasing voltage increases rise time/propegation and speeds the thing up. The grad students had a great demo where they powered one of their CPUs using a potato with some nails in it (like from elementary school science class.) They called it the 'potato chip'.
Processors like this do not have a clock. Each piece of the processor is self-timing, with handshaking done between components to pass the data (compare this with clocked processors, where you can assume the data is at your input and valid just by counting cycles.) Asynchronous processors don't have global 'cycles' when all components must pass data.
But your assertion about critical path is slightly off. Asynch processors still have a critical path. If you immagine the components as a bucket-bregade and the data the buckets, then they may not all be heaving the buckets at exactly the same time anymore, but they will still be slowed down by the slowest man in the line. The difference is that critical path is now dynamic. You don't have to time everything to the static, worst-case component on your chip. If you consistenly don't use the slowest components (say, the multiply unit), then you will get a faster IPT (instruction per time) on average.
And yes, you don't have clock skew any more which is nice, but you now have to handshake data back-and-forth across the chip. Of course putting decoupling circuitry in can help.
Yeah, I like that idea too. Let people post the first one free, which lets the casual user avoid fees. The realestate agents / brokers who post day in and day out (and are the one's abusing the system with same-day repeats to keep on top of the stack) will have a market force applied to curb the posting.
For things like home, or rent listings you could even limit it to once per week. I mean how often do you need to update those? And for that category, you could also require a (not publicaly disclosed) address to prevent someone from signing up as a 'new' user over and over.
Except that you can't get very far without coming to a freeway or highway that you are legaly bared from walking or biking on. We're essentialy hemmed in by the interstates. So unless you have earned the 'privalage' to drive on the highways from your friendly govornment, you've essentialy been confined to a (sometimes large) box. There may be the occasional underpass, but good luck finding one that doesn't double your route.
Slashdot Mirror
Also, do SiC transitors switch as fast as doped silicon? Otherwise the "make a pentium with it!" ideas might fall flat.
Fertilizer is more about giving the plants nitrogen, potasium, and phosphorous than energy from chemical bonds. They get their energy from fusion 8 minutes away. We're after the chemical bond energy in the form of C-H bonds. The plants can have the rest back.
The Econ 101 word you are looking for here is "elasticity." Gas is an extremely inelastic good. Demand does not fluctuate (much) with price compared to other goods. Of course if you get to Econ 202 there may be a time domain component. I still have to get to work tomorrow and so will pay the price, but next year when I buy a new car, I may look more favorably on that Mini where I'll be buying less every tank from then on.
Because Fark was work appropriate before that?
Except that storage is one of the major hurdles that needs to be over come to use hydrogen.
With this, the car's power source has been decoupled from our choice of power supply. We can use what ever source for energy to turn the 2Al2O3 back into 4Al + 3O2. Today we can use coal burning plants for the electricity, tomorrow nuclear, the next day solar and wind, the next fusion. You don't need to upgrade your car every time we invent (and/or make economical) a cleaner power source.
All you'd need is a big spinning mirror and you could vaporize a human target from space.
Also, the BIG point left out by the original poster: it doesn't matter to the current debate if cosmic rays can alter the Earth's climate since the level of cosmic rays has been measured as constant over the period in dispute.
No scientist was predicting "freezing to death", nor were any peer-reviewed journals publishing articles to this effect. The "1970's prediction of an iceage" myth is based on two media articles by National Geographic and Newsweek where the journalists got their science wrong (more so in Newsweek.)
a better explination is here
This is myth is keept alive by the likes of George Will (a fairly respectable conservative on most other topics) and that "expert" Michael Crichton. The only thing close was the discovery in the 1970's of teperature variations with a periodicity of 20000 years. Well below the time scale of anthropogenic warming (on order of decades to 100s of years.)
Um, isn't the IP version field only 4 bits?
Propeganda is merely an attempt to sway a group's opinion through communication. "Getting your message out." That message can be truthful or lies, honest or deceptive, present all facts or cherry pick; it just needs to be pursuasive. I think sometims the negative connotation actualy discourages non-deceptive propeganda from more honest parties because they feer being accused of engaging in 'propeganda'.
TCP only matters at the endpoints, which presumably they control. If TCP is causing problems, use something else or invent something better to shove in the IP payload. Now if there is a problem at the IP layer of the protocol stack then, yes, your're SOL if you want to use the internets.
Ah, a Yankees fan I see.
And grid cities can still be confusing when you throw in one way streets, diagonal streets (all the state named avenues in DC), streets that don't exist for one or more blocks then start up again, traffic circles, traffic sqares, etc. But don't blame us, DC was laid out by a Frenchman.
Markets aren't 100% efficient and only support a finite # of suppliers. They often can support fewer suppliers than there are permutations of consumer demand. The lament isn't that there are no suppliers willing to take an unprofitable stance on a small market segement. The lament is that other conusmers have made the "quality" demographic too small to support through shortsightedness that actualy costs them more in the long run to boot.
Yes, but a useful one.
= copyright lawsuit. But don't worry, all they've got to do is reprogram it to shoot the horde of oncoming MPAA/RIAA lawyers.
But seriously, as it gets harder and harder to make larger CPUs run faster the trend is going to be more, smaller processors per die. Each core is by itself slower than a huge monolithic one, but the sum is greater thanks to non-linear scaling. The trick is getting software to efficiently utilize them all.
I blame the twos.
As for ease of programing another poster mentioned. I think viewing a parallel application as data passed/flowing from node to node in a graph is easy to conceptualize, especialy for multimedia or server applications. However most programers are taught C first and then taugh some bastardization that lets them explicitly spawn threads in the same memory space, with things like semaphores, etc. for safety and synchonization. It is extremely difficult to rationalize about correctness when programing that way since you have to either conservatively synch every step (not verry parallel) or convince yourself the app is safe under every possible read/write ordering of ALL the threads. They need to be taught languages that are safe from the get-go.
Actualy what you described is a very specific instance of dataflow programs, where the flow can best be described by a directed "dataflow" graph. Technicaly macrodataflow since you pass data between processes; true dataflow reduces the granularity all the way down to individual instructions passing each other operands.
The reason "applications naturally parallelize" is because the language is forcing the programer to be explicit about the parallelism, something that doesn't come naturaly to your Freshman CS101 coder. Imperative languages like C, Fortran, Java, etc. that students are taught first are geared towards von Neumann machines and are incredebly hard for the compiler to parallelize.
Interestingly, functional languages like you mentioned (also try 'Id') map quite well to dataflow. This is directly due to their lack of side effects (i.e. manipulating structures in memory, which must be inherently sequential in order for the programer to reason well about program correctness.)
Dataflow had a lot more following in the 80s and early 90s. One problem was actualy an explosion of too much parallelism exposed in the application, more than the functional units could handle. The overflow then had to be shuttled back and forth to memory, making the aps bandwidth limited. Look at the MIT TTDA, Monsoon, *T, TERA, TAM, WaveScalar, and other projects. The ability to put many functional units (cores) and sufficient memory to keep them fed on a single die recently (last 5 years) reduces this limit and may allow the field to have a bit of resurgance.
The only timing assumption that had to be made was "isochronous forks" i.e. that if two gates saw the same input (i.e. were tied with the same wire from a common output) then they both 'see' the input before their outputs can have any effect on the other gate with the same input. So for example if a transition to a '1' at an OR gate input simultaneously causes some other gate to set the OR's second input from '1' to '0', there would be no glitches. The prof proved that this assumption is needed to do any usefull calculations. Wire speed .lt. gate speed is an easy condition to meet for most technologies.
So then as long as the design is segmented into lots of small, verifiable components, you can define a safe, 4-phase handshake that has no race conditions between blocks so the whole design is safe. You still have to check for deadlock conditions. The drawback is that to do the handshaking you have to use two wires per bit, which essentialy doubles your transistor count. "00" = no data, "01" = 0, "10" = 1, "11" can't happen. This gets arround the problem of a fast "valid" flag arriving before slow data is metastable.
One of the neatest things about asynch processors is their ability to run in a large range of voltages. You don't have to worry that lowering the voltage will make you miss gate setup timing since the thing just slows down. Increasing voltage increases rise time/propegation and speeds the thing up. The grad students had a great demo where they powered one of their CPUs using a potato with some nails in it (like from elementary school science class.) They called it the 'potato chip'.
But your assertion about critical path is slightly off. Asynch processors still have a critical path. If you immagine the components as a bucket-bregade and the data the buckets, then they may not all be heaving the buckets at exactly the same time anymore, but they will still be slowed down by the slowest man in the line. The difference is that critical path is now dynamic. You don't have to time everything to the static, worst-case component on your chip. If you consistenly don't use the slowest components (say, the multiply unit), then you will get a faster IPT (instruction per time) on average.
And yes, you don't have clock skew any more which is nice, but you now have to handshake data back-and-forth across the chip. Of course putting decoupling circuitry in can help.
For things like home, or rent listings you could even limit it to once per week. I mean how often do you need to update those? And for that category, you could also require a (not publicaly disclosed) address to prevent someone from signing up as a 'new' user over and over.
"Sorry, but you can't get there from here."