You seem to be confusing the instruction set with the underlying implementation.
I'm not confusing anything.
So much so that it must be translated into a decent set of instructions by microcode before the processor can pass it through the decoder and ALU.
I don't know why you consider this a downside any longer; we've been able to do efficiently and fast for 20 years. And many times it can be an upside, by eliminating the need for long instruction sequences that x86 can accomplish in a single instruction. Want to add 5 to a memory location in x86? Add [mem], immediate. The same thing in RISC is: Load reg, [mem]; add reg, imm, store [mem], reg.
Oh, I don't know. Instructions for 64-bit programming piled upon instructions for 32-bit programming piled upon instructions for 16-bit programming piled upon instructions for 8-bit programming,
All the instructions are the same. There are some mode bits which take you to and from the different modes, which changes the default opsize/address size. That's about it. Stick with one mode as I'm sure 99% of people do, and you never have to worry about it.
all with a half-dozen memory modes to choose from
This allows expressiveness in your program without lots of address-computation instructions. Want to access a struct member in an array of structs? rbx is your array base pointer, rcx is your counter, and disp is your struct member offset. mov rax, [rbx + rcx + disp]. Saves instructions!
four different register access methods,
Yes, this allows you to use partial registers without lots of masking.
special use of particular registers in certain modes,
That is a problem in 16-bit mode *only*, and I'll agree wholeheartedly with you, it sucks. However, those register restrictions were removed in 32-bit mode when the 80386 came out in the late 80s. 20 years ago.
complex instructions added willy-nilly only to be deprecated into slow microcode later on
Microcode is at least as fast as executing a longer sequence of native instructions. But the upside of having complex instructions in microcode is, again, that it lets you express a complex operation using a single ISA instruction. That means it takes up less space in your instruction cache. More instructions fit in your instruction cache. Programs are smaller.
Just off the top of my head, I'm already thinking of carefully crafting instructions so that they seem correct when the verifier passes over them in sequence, but actually execute as different instructions when the jump is executed into what appears to be the middle of an instruction.
If you would RTFP, you'd see that they enforce branch targets in such a way so that you explicitly *cannot* jump into the middle of an instruction and make it do something else.
The x86 instruction set is far too large, overly complex, redundant, antiquated, and poorly suited as a replacement for VM-targeted instruction sets like Java bytecode.
Large, yes. Complex, yes. Redundant, don't know what you're talking about. Antiquated, no way. It certainly is poorly suited as a replacement for Java bytecode, which is poorly suited for just about any performance-critical task known to man.
"Speed" is a terrible excuse for attempting a platform like this.
Speed is just about the *only* reason to do this! So you disagree with their entire premise of their paper, fine. Don't bash native x86 in general because it's not suited for web applications.
Because all that we need is to further promote an archaic instruction set that won't die because of all the pre-existing code compiled for it.
I'm sick of people spouting off this FUD. What is "archaic" about modern x86? Have you ever looked at it? Have you looked at a modern x86 microprocessor's implementation of the x86 ISA?
I would argue that we use x86 not just because of legacy code, but also because everyone on Earth already has an x86 processor somewhere which performs quite well on a wide range of code. Specifically:
Variable-length instructions make more efficient use of the instruction cache because they can be, on average, smaller than fixed-length instructions for the same code sequence. And we've known how to efficiently decode variable-length instructions in hardware for about 20 years.
CISC processors look like RISC processors internally. You spend a little extra chip area on a microcode ROM to implement the nastier, longer CISC instructions.
SSE gives you vector processing.
The 64 bit support cleaned up some of the cruft and added other missing things (RIP-relative addressing, more GPRs).
Virtualization is supported by ISA extensions from both Intel and AMD.
Development tools for x86 are very mature, probably the most mature of any instruction set.
If researchers wanted to invent a more efficient or usable browser language other than JS, I'd be all for it. But I don't run a browser to become a part of a compute farm. I run a browser to access web information and applications. Very little of which is compute-intensive enough to require a new execution engine over a more advanced set of APIs.
The only reason to do any of this is speed. You're right, JS is fine for lots of things, but even the best JavaScript JIT won't be as fast as native x86.
I'm sure I'll figure it out eventually, but WHY oh why do we want to promote such a complicated method of compiling code?
Once again, speed. The only reason they are doing any of this is speed.
I don't know how to say this differently. You're arguing for a circuit-switched 10Mbps network. (Your telco/analog phone argument uses...what do you know...circuit switched links). The Internet gives you a statistically-multiplexed 10Mbps network, which works great most of the time. The only reason you ever get anywhere near 10Mbps is because all the subscribers' traffic can be statistically multiplexed over backbone links which can't handle anywhere near the maximum bandwidth of all the pipes they feed. But you still get 10Mbps most of the time, which is why they can sell it to you at 10Mbps and charge you for it.
Every subscriber using 10Mbps all the time (not 56k all the time as in your dial-up example) would break the network, and bumping up capacity to handle full 10Mbps at this point is too expensive. As for your triple play argument:
1) VOIP is low bandwidth. 2) Television is, multicast, mostly unidirectional, they're already moving to switched digital video because they're running out of bandwidth and can't compete with satellite for HD services.
From what I can tell, you're arguing against "statistical multiplexing", which unfortunately for you is how the entire Internet is built. Obviously ISPs and backbones have to constantly improve capacity, but that doesn't mean they need to provide every end user with their maximum last-mile bandwidth *all the time*. That's called a circuit-switched network, and we got away from it in the late 80s for efficiency reasons.
Besides, 10Mbps is the maximum bandwidth that your link can deliver, but it says nothing about other traffic on your ISP's network let alone the rest of the Internet. If your ISP doesn't throttle you somewhere, but the route to and from your data is congested, you're effectively going to get throttled elsewhere. Who are you going to bitch at then? The content provider? The backbone providers?
You were sold a 10Mbps link which is statistically multiplexed *many* places upstream with other links, not a 10Mbps dedicated circuit to every server on the Internet.
No. Freedom of speech/opinion (your example) is different than hypocrisy (OP's example).
An equivalent analogy of hypocrisy using your flat-Earthers would be if the flat Earth people think that they should be allowed to voice their opinion, but that Creationists should be silenced for being stupid.
Stated without an example, OP believes it's hypocritical that "American culture" is constantly bashed and various hypocrites say it shouldn't be celebrated - in the US, no less - yet other ethnic groups' cultures are widely celebrated in the US without such scorn.
Train travel isn't currently popular in the U.S. for passenger transport, for a variety of reasons, so a terrorist attack on one wouldn't make much sense. Most people would just say "Okay, I was going to fly anyway." But if these things catch on and do become as popular as air travel for common routes, I'm sure someone will start targeting them. All I was saying was that security implications of protecting a rail line are much bigger than protecting the endpoints of air travel.
I fully agree with your point about track maintenance.
Not only of the passengers, train, and endpoints/stations, but now you have to protect the entire track too. All it takes is some terrorist group with RPGs going around blowing up sections of track, causing train derailments.
Your tree, in a roundabout way, does exactly what this company says its going to do. Namely, it uses free energy (sunlight) to convert CO2+H2O into hydrocarbons which become part of the tree - things like cellulose. Why can't we try to find a way to do the same thing?
you're actually going to get fuel out that's good for *less* energy than you put in.
Yes, we all know that. But what are other "free" energy conversion efficiencies? Solar->electric (photovoltaics) is like 10%. Who knows what the efficiency of this might be. And I don't even know any other ones. Digging up and burning hydrocarbons doesn't count - the plants and animals + earth's pressure/temperature did all the energy conversion for us over millions of years. According to lots of people, we're eventually going to start running out of that sort of pre-converted energy, so then where will we be?
Like I said, the point is that in addition to some fuel, you're also removing CO2 from the atmosphere. Is the cost of doing this combination of fuel+CO2 removal cheaper than doing both of them separately?
Great post, and I'm skeptical too, but two points:
The point isn't about energy, it's about carbon. I know that CO2 is a terribly low-energy byproduct of hydrocarbon combustion, but that's the point - we want to get rid of the byproduct. We're going to continue to use hydrocarbon fuels because they're relatively cheap, so we're going to continue to put huge amounts of CO2 into the atmosphere which used to be tied up in heavy hydrocarbons deep in the earth. I'd want to see some hard efficiency numbers of this system, which might make it not worth it...but the extra benefit (in addition to making fuel from "free" energy sources like the sun/waste heat) is that the energy they are putting in is *also* removing carbon from the atmosphere. I don't know how much energy it would take to just plain remove an equivalent amount of CO2 from the atmosphere, but both things are happening here so you have to analyze it from both views.
They mentioned biocatalysts, which could be a buzzword, but also could be real. I remember from basic chemistry that catalysts lowered the activation point of a reaction. Maybe whatever biocatalysts they're using can accumulate enough energy from a low-exergy, ambient source like exhaust heat from, say, a coal-fired power plant, and slowly stitch up carbons and hydrogens together to form a hydrocarbon. It probably depends on the chemical mechanism of the hydrocarbon formation. Speaking of that, do we understand the mechanism by which hydrocarbons in the earth were formed (beyond "lots of heat and pressure"...I mean chemically how the bonds form, in what order, were there catalyst/activation sites on other materials, etc.). Maybe such a slow catalyzed process isn't possible...but maybe it is?
Like I said, I'm skeptical too...but I want to hope that such a thing is possible...
Wow. So you're saying union teachers trying to perpetuate a union system are looking to another union system to guide them?
No. He's saying teachers in the US trying to gain higher student achievement are looking to another teaching system which has high student achievement across the board to guide them.
Yes, they released a patch so that the NVM can't be overwritten after the e1000e driver is loaded. But from what I can tell, they still don't know what is/was responsible for the overwriting.
FWIW, I'm almost positive that modern CPUs have debug traps for this exact sort of thing...you can trap arbitrary I/O writes via SMM or something...obviously I'm not in the debug loop, but I don't see why this has been so hard to figure out...
No one is suggesting that heat, humidity, water can't kill servers. The point is overall uptime vs. overall cost.
If you build your SAN or whatever with enough redundancy or capacity that it can handle one or a handful of servers going down in that 115F July heat with little to no impact on uptime or productivity...and, you also save a boatload of money in AC installation, cooling, and maintenance costs because the cost of replacing/rebuilding those servers is less than the cost of cooling the server room, you have a net win. It's purely a numbers game.
No offense to you in particular, but the fact that you got modded +5 Insightful shows the lack of understanding of copyright in general by the Slashdot community. TheVelvetFlamebait's post above nails the real issue.
laws designed to protect book publishers in the 18th century may not quite be appropriate now.
Like TheVelvetFlamebait alludes to, the law was not designed to protect book publishers. It was designed to protect book writers. The fact that the RIAA is using the law to protect itself is an abuse of that law, but copyright was designed to protect creators of artistic works that could easily be reproduced.
You've been downmodded over 10 times because of your N posts, N of them are trolls and/or flamebait.
Your first post is clearly a troll by stating that/.'s mod system is broken, as a reply to a comment which is unrelated to/.'s mod system. That's the precise definition of troll; furthermore, it is not a fact (no matter how much anecdotal evidence you offer), but rather, your opinion. Your other N-1 posts (all but the first) are meta-troll and/or meta-flamebait posts; in each post, you argue that the first post shouldn't have been downmodded for being troll/flamebait, thus sparking a useless discussion about trolls and flamebaits and/.'s mod system.
The person who submitted this story to Slashdot left out an important link on that text from the original Inquirer article (linked again here for your convenience). In the original story, that sentence reads:
Then again, since doing the right thing would likely bankrupt them, we wouldn't hold your breath for it to happen.
At that link, you'll find The Inquirer's (however flimsy and speculative) financial analysis of a full-scale Nvidia recall of the bad parts.
The Inquirer doesn't and has never claimed to be a fair and balanced news source, so they are free to put these sorts of quips on their stories. People there are pretty knowledgeable, and appear to have connections and sources in the industry, which is why people keep reading The Inquirer and don't really complain about stuff like that.
I sort of agree, but even as-is I believe you can make the other conclusion as well (that US broadband speeds are severely lagging other countries' speeds).
If the median speed in Japan is 100Mbps, that means that the average person in Japan can afford 100Mbps broadband access. That either means that the average person in Japan is wealthier than the average person in the US to be able to afford such speeds (possible or even likely), but I can't imagine they are *that* much wealthier. The other thing it could tell us is that the average person in Japan can afford to pay for such speeds because they are cheap enough for the average person. I think this is just as likely as the first conclusion, maybe even moreso.
Artificial value? The design for that Pentium or Core 2 or Athlon running your computer is just data. Literally, it's a set of Verilog files, and some pictures of the layout. I bet AMD or Intel thinks that data is pretty valuable.
The problem is not finding good music, the problem is filtering out the crap.
And once I filter out the crap, I want to compensate the creators of the good stuff.
We live in a very information rich and music rich world where the marginal cost of music is close to zero.
I couldn't agree more. The marginal cost of music is not the issue. It's the talent and creativity required to create it that is what's worth something.
Like you just did?
So you got the irony, then. Give yourself a pat on the back.
It was a direct reply to your so-called reason as to why you "pay for music". If you can't see that you've completely missed the point.
I can repeat myself all day and I still don't think you would get it. Massive amounts of music, or economies of scale, or mass-produced corporate noise, I'm not interested. I'm paying for creativity and talent. I'm paying for creativity and talent. I'm paying for creativity and talent.
I'm not sure what you mean by geometries. SRAM arrays, flops, random logic, carry-lookahead adders, Wallace-tree multipliers (building blocks of processors) generally look similar across all high-performance ASICs over the past 15 years. Circuit geometries themselves have almost certainly changed completely since P6 days - 45nm is a hell of a lot smaller than 350nm, and the rules governing how close things can be have almost certainly changed.
I think what the article really means is that Nehalem shares a lot of the architectural concepts and style of the P6: similar number of pipe stages, similar number of execution units, similar decode/dispatch/execute/retire width (I think Core 2/Penryn/Nehalem are 4 and P6 was 3), similar microcode, etc. Of course enhancements and improvements have been made in things like the branch predictor, load-store unit, and obviously the interconnect/bus...but if you look at Nehalem closely enough, and indeed if you look at Pentium M, Core 2, Penryn too, you can see the architecture of the P6 as an ancestor.
I couldn't disagree more. The thing in limited supply, and in high demand, is the musician's creativity - writing melodies that people like, expressive lyrics, cool guitar solos, interesting arangements, new instruments used in a different genre, etc. That's what I'm paying for when I buy music. The fact that copies of this creativity cost $0 to duplicate and distribute does not mean that the creativity itself is worthless. *That* is what copyright law was establish to protect. Everyone here on Slashdot justifies illegal copying by making quips about the poor quality of music, lack of creativity, etc., but that does not give anyone the right to take it for $0. The course of action in those cases is to not buy it.
The thing is, the x86 CPUID instruction gives you many different things in EAX/EBX/ECX/EDX depending on what you put into EAX before you execute it. The "GenuineIntel"/"AuthenticAMD" strings are what you get when you put 0 in EAX. When you put 1 in EAX, you get various feature bits in ECX and EDX, such as support for SSE/SSE2/SSE3. Any code worth its salt will base any decisions on those feature bits from CPUID function 1, not on the string you get from CPUID function 0.
Slashdot Mirror
You seem to be confusing the instruction set with the underlying implementation.
I'm not confusing anything.
So much so that it must be translated into a decent set of instructions by microcode before the processor can pass it through the decoder and ALU.
I don't know why you consider this a downside any longer; we've been able to do efficiently and fast for 20 years. And many times it can be an upside, by eliminating the need for long instruction sequences that x86 can accomplish in a single instruction. Want to add 5 to a memory location in x86? Add [mem], immediate. The same thing in RISC is: Load reg, [mem]; add reg, imm, store [mem], reg.
Oh, I don't know. Instructions for 64-bit programming piled upon instructions for 32-bit programming piled upon instructions for 16-bit programming piled upon instructions for 8-bit programming,
All the instructions are the same. There are some mode bits which take you to and from the different modes, which changes the default opsize/address size. That's about it. Stick with one mode as I'm sure 99% of people do, and you never have to worry about it.
all with a half-dozen memory modes to choose from
This allows expressiveness in your program without lots of address-computation instructions. Want to access a struct member in an array of structs? rbx is your array base pointer, rcx is your counter, and disp is your struct member offset. mov rax, [rbx + rcx + disp]. Saves instructions!
four different register access methods,
Yes, this allows you to use partial registers without lots of masking.
special use of particular registers in certain modes,
That is a problem in 16-bit mode *only*, and I'll agree wholeheartedly with you, it sucks. However, those register restrictions were removed in 32-bit mode when the 80386 came out in the late 80s. 20 years ago.
complex instructions added willy-nilly only to be deprecated into slow microcode later on
Microcode is at least as fast as executing a longer sequence of native instructions. But the upside of having complex instructions in microcode is, again, that it lets you express a complex operation using a single ISA instruction. That means it takes up less space in your instruction cache. More instructions fit in your instruction cache. Programs are smaller.
Just off the top of my head, I'm already thinking of carefully crafting instructions so that they seem correct when the verifier passes over them in sequence, but actually execute as different instructions when the jump is executed into what appears to be the middle of an instruction.
If you would RTFP, you'd see that they enforce branch targets in such a way so that you explicitly *cannot* jump into the middle of an instruction and make it do something else.
The x86 instruction set is far too large, overly complex, redundant, antiquated, and poorly suited as a replacement for VM-targeted instruction sets like Java bytecode.
Large, yes. Complex, yes. Redundant, don't know what you're talking about. Antiquated, no way. It certainly is poorly suited as a replacement for Java bytecode, which is poorly suited for just about any performance-critical task known to man.
"Speed" is a terrible excuse for attempting a platform like this.
Speed is just about the *only* reason to do this! So you disagree with their entire premise of their paper, fine. Don't bash native x86 in general because it's not suited for web applications.
Because all that we need is to further promote an archaic instruction set that won't die because of all the pre-existing code compiled for it.
I'm sick of people spouting off this FUD. What is "archaic" about modern x86? Have you ever looked at it? Have you looked at a modern x86 microprocessor's implementation of the x86 ISA?
I would argue that we use x86 not just because of legacy code, but also because everyone on Earth already has an x86 processor somewhere which performs quite well on a wide range of code. Specifically:
If researchers wanted to invent a more efficient or usable browser language other than JS, I'd be all for it. But I don't run a browser to become a part of a compute farm. I run a browser to access web information and applications. Very little of which is compute-intensive enough to require a new execution engine over a more advanced set of APIs.
The only reason to do any of this is speed. You're right, JS is fine for lots of things, but even the best JavaScript JIT won't be as fast as native x86.
I'm sure I'll figure it out eventually, but WHY oh why do we want to promote such a complicated method of compiling code?
Once again, speed. The only reason they are doing any of this is speed.
I don't know how to say this differently. You're arguing for a circuit-switched 10Mbps network. (Your telco/analog phone argument uses...what do you know...circuit switched links). The Internet gives you a statistically-multiplexed 10Mbps network, which works great most of the time. The only reason you ever get anywhere near 10Mbps is because all the subscribers' traffic can be statistically multiplexed over backbone links which can't handle anywhere near the maximum bandwidth of all the pipes they feed. But you still get 10Mbps most of the time, which is why they can sell it to you at 10Mbps and charge you for it.
Every subscriber using 10Mbps all the time (not 56k all the time as in your dial-up example) would break the network, and bumping up capacity to handle full 10Mbps at this point is too expensive. As for your triple play argument: 1) VOIP is low bandwidth. 2) Television is, multicast, mostly unidirectional, they're already moving to switched digital video because they're running out of bandwidth and can't compete with satellite for HD services.
From what I can tell, you're arguing against "statistical multiplexing", which unfortunately for you is how the entire Internet is built. Obviously ISPs and backbones have to constantly improve capacity, but that doesn't mean they need to provide every end user with their maximum last-mile bandwidth *all the time*. That's called a circuit-switched network, and we got away from it in the late 80s for efficiency reasons.
Besides, 10Mbps is the maximum bandwidth that your link can deliver, but it says nothing about other traffic on your ISP's network let alone the rest of the Internet. If your ISP doesn't throttle you somewhere, but the route to and from your data is congested, you're effectively going to get throttled elsewhere. Who are you going to bitch at then? The content provider? The backbone providers?
You were sold a 10Mbps link which is statistically multiplexed *many* places upstream with other links, not a 10Mbps dedicated circuit to every server on the Internet.
No. Freedom of speech/opinion (your example) is different than hypocrisy (OP's example).
An equivalent analogy of hypocrisy using your flat-Earthers would be if the flat Earth people think that they should be allowed to voice their opinion, but that Creationists should be silenced for being stupid.
Stated without an example, OP believes it's hypocritical that "American culture" is constantly bashed and various hypocrites say it shouldn't be celebrated - in the US, no less - yet other ethnic groups' cultures are widely celebrated in the US without such scorn.
http://bash.org/?24262
Train travel isn't currently popular in the U.S. for passenger transport, for a variety of reasons, so a terrorist attack on one wouldn't make much sense. Most people would just say "Okay, I was going to fly anyway." But if these things catch on and do become as popular as air travel for common routes, I'm sure someone will start targeting them. All I was saying was that security implications of protecting a rail line are much bigger than protecting the endpoints of air travel.
I fully agree with your point about track maintenance.
Okay okay...build the track underground?
Not only of the passengers, train, and endpoints/stations, but now you have to protect the entire track too. All it takes is some terrorist group with RPGs going around blowing up sections of track, causing train derailments.
So plant a tree.
Your tree, in a roundabout way, does exactly what this company says its going to do. Namely, it uses free energy (sunlight) to convert CO2+H2O into hydrocarbons which become part of the tree - things like cellulose. Why can't we try to find a way to do the same thing?
you're actually going to get fuel out that's good for *less* energy than you put in.
Yes, we all know that. But what are other "free" energy conversion efficiencies? Solar->electric (photovoltaics) is like 10%. Who knows what the efficiency of this might be. And I don't even know any other ones. Digging up and burning hydrocarbons doesn't count - the plants and animals + earth's pressure/temperature did all the energy conversion for us over millions of years. According to lots of people, we're eventually going to start running out of that sort of pre-converted energy, so then where will we be?
Like I said, the point is that in addition to some fuel, you're also removing CO2 from the atmosphere. Is the cost of doing this combination of fuel+CO2 removal cheaper than doing both of them separately?
Great post, and I'm skeptical too, but two points:
Like I said, I'm skeptical too...but I want to hope that such a thing is possible...
Wow. So you're saying union teachers trying to perpetuate a union system are looking to another union system to guide them?
No. He's saying teachers in the US trying to gain higher student achievement are looking to another teaching system which has high student achievement across the board to guide them.
Yes, they released a patch so that the NVM can't be overwritten after the e1000e driver is loaded. But from what I can tell, they still don't know what is/was responsible for the overwriting.
FWIW, I'm almost positive that modern CPUs have debug traps for this exact sort of thing...you can trap arbitrary I/O writes via SMM or something...obviously I'm not in the debug loop, but I don't see why this has been so hard to figure out...
No one is suggesting that heat, humidity, water can't kill servers. The point is overall uptime vs. overall cost.
If you build your SAN or whatever with enough redundancy or capacity that it can handle one or a handful of servers going down in that 115F July heat with little to no impact on uptime or productivity...and, you also save a boatload of money in AC installation, cooling, and maintenance costs because the cost of replacing/rebuilding those servers is less than the cost of cooling the server room, you have a net win. It's purely a numbers game.
No way, betterer is not a word. Your way dumberer than him.
No offense to you in particular, but the fact that you got modded +5 Insightful shows the lack of understanding of copyright in general by the Slashdot community. TheVelvetFlamebait's post above nails the real issue.
laws designed to protect book publishers in the 18th century may not quite be appropriate now.
Like TheVelvetFlamebait alludes to, the law was not designed to protect book publishers. It was designed to protect book writers. The fact that the RIAA is using the law to protect itself is an abuse of that law, but copyright was designed to protect creators of artistic works that could easily be reproduced.
You've been downmodded over 10 times because of your N posts, N of them are trolls and/or flamebait.
Your first post is clearly a troll by stating that /.'s mod system is broken, as a reply to a comment which is unrelated to /.'s mod system. That's the precise definition of troll; furthermore, it is not a fact (no matter how much anecdotal evidence you offer), but rather, your opinion. Your other N-1 posts (all but the first) are meta-troll and/or meta-flamebait posts; in each post, you argue that the first post shouldn't have been downmodded for being troll/flamebait, thus sparking a useless discussion about trolls and flamebaits and /.'s mod system.
PLONK
Then again, since doing the right thing would likely bankrupt them, we wouldn't hold your breath for it to happen.
At that link, you'll find The Inquirer's (however flimsy and speculative) financial analysis of a full-scale Nvidia recall of the bad parts.
The Inquirer doesn't and has never claimed to be a fair and balanced news source, so they are free to put these sorts of quips on their stories. People there are pretty knowledgeable, and appear to have connections and sources in the industry, which is why people keep reading The Inquirer and don't really complain about stuff like that.
I sort of agree, but even as-is I believe you can make the other conclusion as well (that US broadband speeds are severely lagging other countries' speeds).
If the median speed in Japan is 100Mbps, that means that the average person in Japan can afford 100Mbps broadband access. That either means that the average person in Japan is wealthier than the average person in the US to be able to afford such speeds (possible or even likely), but I can't imagine they are *that* much wealthier. The other thing it could tell us is that the average person in Japan can afford to pay for such speeds because they are cheap enough for the average person. I think this is just as likely as the first conclusion, maybe even moreso.
Artificial value? The design for that Pentium or Core 2 or Athlon running your computer is just data. Literally, it's a set of Verilog files, and some pictures of the layout. I bet AMD or Intel thinks that data is pretty valuable.
The problem is not finding good music, the problem is filtering out the crap.
And once I filter out the crap, I want to compensate the creators of the good stuff.
We live in a very information rich and music rich world where the marginal cost of music is close to zero.
I couldn't agree more. The marginal cost of music is not the issue. It's the talent and creativity required to create it that is what's worth something.
Like you just did?
So you got the irony, then. Give yourself a pat on the back.
It was a direct reply to your so-called reason as to why you "pay for music". If you can't see that you've completely missed the point.
I can repeat myself all day and I still don't think you would get it. Massive amounts of music, or economies of scale, or mass-produced corporate noise, I'm not interested. I'm paying for creativity and talent. I'm paying for creativity and talent. I'm paying for creativity and talent.
I'm not sure what you mean by geometries. SRAM arrays, flops, random logic, carry-lookahead adders, Wallace-tree multipliers (building blocks of processors) generally look similar across all high-performance ASICs over the past 15 years. Circuit geometries themselves have almost certainly changed completely since P6 days - 45nm is a hell of a lot smaller than 350nm, and the rules governing how close things can be have almost certainly changed.
I think what the article really means is that Nehalem shares a lot of the architectural concepts and style of the P6: similar number of pipe stages, similar number of execution units, similar decode/dispatch/execute/retire width (I think Core 2/Penryn/Nehalem are 4 and P6 was 3), similar microcode, etc. Of course enhancements and improvements have been made in things like the branch predictor, load-store unit, and obviously the interconnect/bus...but if you look at Nehalem closely enough, and indeed if you look at Pentium M, Core 2, Penryn too, you can see the architecture of the P6 as an ancestor.
In a world of 6,718,000,000+ [census.gov] people that is not in short supply, not even a little bit, whatever the marketing parasites might tell you.
You seem to have missed the point entirely. The world could have 600 trillion people, and good music would still be in limited supply and high demand.
You need to become more numerically literate.
I don't understand why people feel the need to add one-liner crap like this to their posts.
I couldn't disagree more. The thing in limited supply, and in high demand, is the musician's creativity - writing melodies that people like, expressive lyrics, cool guitar solos, interesting arangements, new instruments used in a different genre, etc. That's what I'm paying for when I buy music. The fact that copies of this creativity cost $0 to duplicate and distribute does not mean that the creativity itself is worthless. *That* is what copyright law was establish to protect. Everyone here on Slashdot justifies illegal copying by making quips about the poor quality of music, lack of creativity, etc., but that does not give anyone the right to take it for $0. The course of action in those cases is to not buy it.
The thing is, the x86 CPUID instruction gives you many different things in EAX/EBX/ECX/EDX depending on what you put into EAX before you execute it. The "GenuineIntel"/"AuthenticAMD" strings are what you get when you put 0 in EAX. When you put 1 in EAX, you get various feature bits in ECX and EDX, such as support for SSE/SSE2/SSE3. Any code worth its salt will base any decisions on those feature bits from CPUID function 1, not on the string you get from CPUID function 0.