Well, given the assumption that intelligence is somehow genetically determined and an inherited trait, if being less intelligent allowed one to propagate the species more easily, then let them. Really, what has intelligence gotten us? Ever consider *why* people drink themselves to oblivion? Here's a snippet of pseudo-code (well, ok, Java):
I believe that is a much larger social issue than equality of the sexes. In fact, it sounds a whole lot like communism. Computer programmers are paid more than prostitutes because the market values computer programmers more. Although with the saturation of programmers the way it is, it could very well be that prostitutes make more than programmers nowadays (hell, I think they do on a per-hour basis). That has absolutely nothing to do with male/female equality and suggesting that there be equalization in pay simply because one has a higher male-female ratio is absurd.
I think the point of the argument you missed is not her boss's attitude but rather her boss's sex. It is perfectly natural that men may find more in common with other men and consequently (and even inadvertently) favor them. The argument (as I can infer in my drunken state) is that if women were more prevalent in the upper-level management positions (e.g. bosses) then this kind of preference would not be blatantly in favor of males than females. Female managers would connect more with female employees (overall) and male managers would connect more with males. It would be a zero-sum game in the end.
The argument can go the same way about role models and heroes. If most well-known scientists/engineers are male and if most women you see growing up are nurses/receptionists/models, there is a *very* strong social inclination to follow suit. The problem with diversity programs, I think, is that they treat the symptoms and not the cause.
Since we can't change the statistics of women in the workplace overnight, at the very least, education, particularly in the early years, should be taught to put these roles and statistics into context. Instead of trying to coerce girls into computers for the sake of a magical 50/50 split when signing up for college, provide more education for parents (gasp! you mean parents don't always know what they're doing?!) to try to lessen the early gender education (i.e. dishes - girls, sparkplugs - guys).
There are all aspects of society, not in the least of which is the media, which need to adjust beyond the gender roles (ever see a boy playing with a Barbie in those commercials?) if we are truly to have people grow based as purely as possible based on their natural inclinations (not saying that there isn't any).
Hell, in the end, it could very well turn out to be that more men prefer computer/science/technical related work than women. But until we eliminate all of the unnecessary social factors that interfere with natural inclinations, we'll never know.
Calling PPC RISC is like calling a Scion TC a "racing car". Asside from the fixed instruction size of its base instruction set, PPC is just about as complex as any "CISC" instruction set out there.
More memory controllers does not mean less latency. In fact, it can mean more if one processor needs data that can only be accessed by another processor's memory controller. The on-die memory controller adds bandwidth, yes, but only if used effectively.
In the situation we're talking about, an on-board memory controller ala the Opteron would require *more* software intelligence, not less. In a shared bus architecture, the most that can happen is that data is in the wrong cache and an inter-cache transfer (I'm not sure how Intel does this but I would assume there's a bus between the two caches) is required. In the case of separate memory paths as in the Opteron multiprocessor system, information can be in the wrong *memory* bank. It would then have to be read out of memory, travel to one die, get transfered over the HT link (which isn't exactly low-latency) and used in the other die. Yes this can be avoided with smart software. But only smart *low-level* software. The OS will have to do this as applications do not even have access to physical memory address.
Show me any possible way to design a microprocessor that can do number crunching faster if the memory subsystem is hampered. Do you realize what would happen to that Athlon if we disabled the on-board memory controller and forced it to communicate with memory through an intermediate chipset?
All, I repeat *all* processors need fast memory accesses. It's simply how they chose to make memory accesses faster that differs. The Athlon went with an on-board memory controller and the Core uses a load of cache and more intelligent pre-fetch algorithms. They *all* need some form of "cheating" to overcome the fact that they have to go to memory.
The problem with that analogy is that one cannot avoid following a law without hard consequences if one remains to be a citizen of said country. Google is perfectly capable of not cooperating with China and not suffer punishment other than gaining less profit. There is also the fact that citizenship implies an agreement to follow all laws and that desires to change those laws will be made via a process (in the case of the US, a democratic policy). Google has no such responsibility for following Chinese law.
(a) Yes....we do. One could even argue that there is an entire profession, nay, multiple professions, positions, both government appointed and not, social and political organizations, and just generally bored individuals spreading ideas on some form of distributed electronic medium devoted to it. I suppose they're just wasting their time though... (b) A more accurate assessment would be, is it better to refuse to work with an oppressive organization, and refuse services which make life more convenient for the Chinese people, or aid an oppressive government economically (through taxes on profit, and a precedence I might add). Companies like MSN and Yahoo have done a greater deal of harm simply because they're willing to comply with the Chinese government. The choice, therefore, becomes much harder for other companies (Google, for instance) to refuse service to China. If Google goes in, it further adds to this precedence of cooperation with an oppressive regime, which is probably the most harmful aspect of this. (c) Just because one does not have influence does not make one's actions any more or less wrong. The man who stood in front of the tank in Tiananmen Square probably could not have made much of a difference, does not mean that his actions were less morally admirable. Practically speaking, I would argue that Google, being one of the most successful companies on the Internet, does indeed hold quite a bit of influence. The profits generated from business in China adds further to the government's income in taxes, as well as further adds to the precedence of cooperation with that oppressive regime.
One of the responsibilities of those with clout (not neccessarily just a company), particularly one who has elevated themselves to the "holier-than-thou" attitude that Google has, is to set examples for others.
The reason people care about this, is because Google, besides the company, represented an ideal that business and moral fortitude need not be separate. And considering the amount of power corporations have over policy, and various aspects of life in general, I do not think such an expectation of these companies is out of the question.
As for change in China, as I've said before, moral principles are not to be upheld or not based solely on whether they will affect change. They are upheld by fact that they are principles. If you could selectively choose when to follow them or not, they would not be principles.
The problem with this is that power requirements will impact performance when you've reached a certain envelope. You can only reliably deliver so much power across the pins to a CPU and it's even more difficult to filter that power so that transcients/ripples don't cause all the signals that it powers to become noisy. At that point, you've hit a wall and can't make that processor run faster. So yes, lower power is important, because it means you can add more to boost performance.
As I'm aware, most high-speed oscillators are LVDS or LVPECL. They don't oscillate between VDD and GND, they generate two 180-degree phase-shifted voltages relative to each other. The problem isn't generating the clock, it's distributing it across the chip. And unless this oscillator scheme has the ability to not be affected by fanout, line delays, etc. it will not overcome the clocking problem. There is still a need for that clock signal to reach different parts of the circuit and there will still be a wire delay, which will cause clock skew. That same clock will still need to drive many gates (or be buffered and then drive those gates). That introduces rise time delays. You'd have to change the gates themselves, not just the clock source, in order to avoid this.
Just based on speculation, that seems to provide many problems:
1. How are signals for the rest of the circuit interpreted? If they do not share a power and ground line then there must be some method of determining the switching voltage. If it's purely based on the difference of the positive and negative terminals then what he's proposing here is pretty much replacing all TTL and CMOS logic with differential logic. Kinda impractical.
2. How does this remove the problem of drive strength? I imagine that if you try to drive anything with this circuit, it will add to the capacitance of loop and therefore chance the oscillation period. If you use it simply as a control signal for an opamp or some other buffering device, you've effectively negated the whole point of having this clock generator as skew (although perhaps not as much jitter) would be just as big of a problem when distributing the clock through a large chip.
Perhaps I'm not fully grasping the significance of this but simply being able to generate a fast clock signal doesn't make it useful. Clocks need to be connected and drive the rest of the circuit.
Is there a technical paper on this? I know it's probably patented and they want to keep as much detail as possible but it seems like a somewhat abstract paper of how this works would convince the chip makers they want to sell this to to be interested. And satisfy curious people like me.
It'd be vastly more complex to layout transistors in 3D. You have to keep in mind that the network of interconnects connecting them would have to either be able to skip between layers, or you'd need a chip design in which equal, exact proportions of the transistors talk to each other and only to each other with very limited inter-layer communication.
And then there's the heat problem.
You want to make software design like designing hardware? Do you *realize* that event-based, serial iteration is what makes software *easier* to create and therefore one can make *more* complex functions with software than with hardware? Do you realize how ridiculously easy modeling a P4 would be using C++? Do you realize how insanely difficult Windows XP would be to describe in VHDL?
This would imply that there is a "proper" price. What you feel you want to pay for whatever they're selling is in no way a method of measuring what they *should* sell their chips at. Supply and demand, remember? They're not there to fullfill your needs and simply take compensation for what it cost them. They're there to make money and if they happen to get you what you want, so much the better.
You are not some form of market god to be appeased.
I'm no expert in ASIC design but that doesn't sound like the best thing to have in your extremely sensitive high-speed signals. I assume this field will remain constant and won't provide noise for the chip (or at least I hope) but it will introduce an electrical bias that needs to be planned and compensated for during the chip's layout.
I fail to see why it is not relevent to modern day problems of power consumption. One of the key ideas of IA-64 was to reduce transistor count (as transistors, like power now, were a premium back then). This is indeed true even today as the IA-64 core itself is tiny in comparison to a Netburst or K8 core. The vast majority of the Itanium chips (even moreso than the Netburst or K8 chips) is cache.
As for parallelism, it is very much the "new world". Multicore is the new trend, didn't you hear? With an ISA that has explicit parallelism built in, it would be much easier to do something like the proposed scheme that started this thread.
Of course, the strict design that Intel built into IA-64 does make it less flexible to things such as long memory latencies and such. I don't see it as what I would envision in an explicitly parallel ISA but that's just me.
I don't see why it does. In current ASIC and FPGA design, clock distribution is a huge problem. So much so that a lot of logic is dedicated (more than the simple branch and buffer) to building a clock distribution tree on the chip. Asynchronous logic has to be built to help synchronize and propogate the clock along with incomming signals because of clock skew.
In short, clocking has become a significant enough problem that the added overhead of asynchronous hand-shaking protocols is actually less burdensome in many cases.
Yes and no. Timing problems is really something that occurs in a synchronous design as you have a limited window of time (between clock edges) where your combinatorial circuit must stabilize. This is not the case in asynchronous design. You have all the time in the world to stabilize your stages of logic. When it is stabilized and only when it is stabilized, does it send a signal to the next stage that it is done and to latch the incomming data. So essentially, your design will time itself (as the method implies) and you won't have timing violations because a certain stage took too long to stabilize.
That being said. Asynchronous design does present problems in terms of performance evaluation and circuit design complexity. When you have any form of procssing pipeline where there are loop-backs (and almost any complex circuit does), you have to be able to evaluate how fast data will move through that pipeline since it will take a variable time for certain combinations of data input bits to produce results at the output lines. Optimizing then becomes much more difficult than to run a static timing analysis tool, find the critical path, and optimizing it.
Not really the same thing. VHDL and Verilog resemble a programming language insofar as there is a syntax and simple if-then statements. Other than that, it's a different beast. Hardware simply works differently. It's not a sequential iteration of instructions, it's the concurrent movement of signals.
FPGA's aren't the golden answer currently. Most if not all FPGA's have issues with being used this way. They are programmable, but they're not made or intended to be programmed in the field (despite their name). The majority have a programmable life of maybe 1000 flashes with flash-based FPGA's (ProASIC from Actel for instance) having a life of maybe 100 flashes. They're basically a poor-man's ASIC more than anything else. The technology would have to improve significantly in a much different direction than what the main FPGA market is targetted at before they can be used as adaptive circuit components while live.
Look on Xilinx's website. The Vertex4's (although currently having supply problems) go up to 500MHz (though you probably don't want to run anything at that speed considering that's probably the reg-to-reg limit).
These things are literally better system-on-a-chip solutions than any ASICs could be considering what it offers. Integrated micro-processor, bus architecture, peripheral interfaces and non-volatile and volatile memory, with enough pins (BGA package) to expand with off-chip components.
Actel even offers mixed-signal FPGA's where you can have your analog and digital circuitry all programmed onto one chip.
These things are the future.
Slashdot Mirror
Well, given the assumption that intelligence is somehow genetically determined and an inherited trait, if being less intelligent allowed one to propagate the species more easily, then let them. Really, what has intelligence gotten us? Ever consider *why* people drink themselves to oblivion? Here's a snippet of pseudo-code (well, ok, Java):
while(person.isAlive()) {
if(person.getIntelligence() > Universe.NebulousGoodIntelligenceLevel) {
person.realizeHowMuchLifeSucks(true);
}
if(person.isConsumingAlcohol()) {
person.setIntelligence(person.getIntelligence() - Universe.NebulousIntelligenceIncrement);
}
}
I believe that is a much larger social issue than equality of the sexes. In fact, it sounds a whole lot like communism. Computer programmers are paid more than prostitutes because the market values computer programmers more. Although with the saturation of programmers the way it is, it could very well be that prostitutes make more than programmers nowadays (hell, I think they do on a per-hour basis). That has absolutely nothing to do with male/female equality and suggesting that there be equalization in pay simply because one has a higher male-female ratio is absurd.
I think the point of the argument you missed is not her boss's attitude but rather her boss's sex. It is perfectly natural that men may find more in common with other men and consequently (and even inadvertently) favor them. The argument (as I can infer in my drunken state) is that if women were more prevalent in the upper-level management positions (e.g. bosses) then this kind of preference would not be blatantly in favor of males than females. Female managers would connect more with female employees (overall) and male managers would connect more with males. It would be a zero-sum game in the end.
The argument can go the same way about role models and heroes. If most well-known scientists/engineers are male and if most women you see growing up are nurses/receptionists/models, there is a *very* strong social inclination to follow suit. The problem with diversity programs, I think, is that they treat the symptoms and not the cause.
Since we can't change the statistics of women in the workplace overnight, at the very least, education, particularly in the early years, should be taught to put these roles and statistics into context. Instead of trying to coerce girls into computers for the sake of a magical 50/50 split when signing up for college, provide more education for parents (gasp! you mean parents don't always know what they're doing?!) to try to lessen the early gender education (i.e. dishes - girls, sparkplugs - guys).
There are all aspects of society, not in the least of which is the media, which need to adjust beyond the gender roles (ever see a boy playing with a Barbie in those commercials?) if we are truly to have people grow based as purely as possible based on their natural inclinations (not saying that there isn't any).
Hell, in the end, it could very well turn out to be that more men prefer computer/science/technical related work than women. But until we eliminate all of the unnecessary social factors that interfere with natural inclinations, we'll never know.
Calling PPC RISC is like calling a Scion TC a "racing car". Asside from the fixed instruction size of its base instruction set, PPC is just about as complex as any "CISC" instruction set out there.
More memory controllers does not mean less latency. In fact, it can mean more if one processor needs data that can only be accessed by another processor's memory controller. The on-die memory controller adds bandwidth, yes, but only if used effectively.
In the situation we're talking about, an on-board memory controller ala the Opteron would require *more* software intelligence, not less. In a shared bus architecture, the most that can happen is that data is in the wrong cache and an inter-cache transfer (I'm not sure how Intel does this but I would assume there's a bus between the two caches) is required. In the case of separate memory paths as in the Opteron multiprocessor system, information can be in the wrong *memory* bank. It would then have to be read out of memory, travel to one die, get transfered over the HT link (which isn't exactly low-latency) and used in the other die. Yes this can be avoided with smart software. But only smart *low-level* software. The OS will have to do this as applications do not even have access to physical memory address.
You can't be serious...
Show me any possible way to design a microprocessor that can do number crunching faster if the memory subsystem is hampered. Do you realize what would happen to that Athlon if we disabled the on-board memory controller and forced it to communicate with memory through an intermediate chipset?
All, I repeat *all* processors need fast memory accesses. It's simply how they chose to make memory accesses faster that differs. The Athlon went with an on-board memory controller and the Core uses a load of cache and more intelligent pre-fetch algorithms. They *all* need some form of "cheating" to overcome the fact that they have to go to memory.
*That* is asinine. It's not that they've done their best not to do evil, they've *stated* that they will *do no evil*. That *means* zero.
The problem with that analogy is that one cannot avoid following a law without hard consequences if one remains to be a citizen of said country. Google is perfectly capable of not cooperating with China and not suffer punishment other than gaining less profit. There is also the fact that citizenship implies an agreement to follow all laws and that desires to change those laws will be made via a process (in the case of the US, a democratic policy). Google has no such responsibility for following Chinese law.
(a) Yes....we do. One could even argue that there is an entire profession, nay, multiple professions, positions, both government appointed and not, social and political organizations, and just generally bored individuals spreading ideas on some form of distributed electronic medium devoted to it. I suppose they're just wasting their time though...
(b) A more accurate assessment would be, is it better to refuse to work with an oppressive organization, and refuse services which make life more convenient for the Chinese people, or aid an oppressive government economically (through taxes on profit, and a precedence I might add). Companies like MSN and Yahoo have done a greater deal of harm simply because they're willing to comply with the Chinese government. The choice, therefore, becomes much harder for other companies (Google, for instance) to refuse service to China. If Google goes in, it further adds to this precedence of cooperation with an oppressive regime, which is probably the most harmful aspect of this.
(c) Just because one does not have influence does not make one's actions any more or less wrong. The man who stood in front of the tank in Tiananmen Square probably could not have made much of a difference, does not mean that his actions were less morally admirable. Practically speaking, I would argue that Google, being one of the most successful companies on the Internet, does indeed hold quite a bit of influence. The profits generated from business in China adds further to the government's income in taxes, as well as further adds to the precedence of cooperation with that oppressive regime.
One of the responsibilities of those with clout (not neccessarily just a company), particularly one who has elevated themselves to the "holier-than-thou" attitude that Google has, is to set examples for others.
The reason people care about this, is because Google, besides the company, represented an ideal that business and moral fortitude need not be separate. And considering the amount of power corporations have over policy, and various aspects of life in general, I do not think such an expectation of these companies is out of the question.
As for change in China, as I've said before, moral principles are not to be upheld or not based solely on whether they will affect change. They are upheld by fact that they are principles. If you could selectively choose when to follow them or not, they would not be principles.
The problem with this is that power requirements will impact performance when you've reached a certain envelope. You can only reliably deliver so much power across the pins to a CPU and it's even more difficult to filter that power so that transcients/ripples don't cause all the signals that it powers to become noisy. At that point, you've hit a wall and can't make that processor run faster. So yes, lower power is important, because it means you can add more to boost performance.
No more than any other high-speed, spiking digital signals.
As I'm aware, most high-speed oscillators are LVDS or LVPECL. They don't oscillate between VDD and GND, they generate two 180-degree phase-shifted voltages relative to each other. The problem isn't generating the clock, it's distributing it across the chip. And unless this oscillator scheme has the ability to not be affected by fanout, line delays, etc. it will not overcome the clocking problem. There is still a need for that clock signal to reach different parts of the circuit and there will still be a wire delay, which will cause clock skew. That same clock will still need to drive many gates (or be buffered and then drive those gates). That introduces rise time delays. You'd have to change the gates themselves, not just the clock source, in order to avoid this.
Just based on speculation, that seems to provide many problems: 1. How are signals for the rest of the circuit interpreted? If they do not share a power and ground line then there must be some method of determining the switching voltage. If it's purely based on the difference of the positive and negative terminals then what he's proposing here is pretty much replacing all TTL and CMOS logic with differential logic. Kinda impractical. 2. How does this remove the problem of drive strength? I imagine that if you try to drive anything with this circuit, it will add to the capacitance of loop and therefore chance the oscillation period. If you use it simply as a control signal for an opamp or some other buffering device, you've effectively negated the whole point of having this clock generator as skew (although perhaps not as much jitter) would be just as big of a problem when distributing the clock through a large chip. Perhaps I'm not fully grasping the significance of this but simply being able to generate a fast clock signal doesn't make it useful. Clocks need to be connected and drive the rest of the circuit.
Is there a technical paper on this? I know it's probably patented and they want to keep as much detail as possible but it seems like a somewhat abstract paper of how this works would convince the chip makers they want to sell this to to be interested. And satisfy curious people like me.
It'd be vastly more complex to layout transistors in 3D. You have to keep in mind that the network of interconnects connecting them would have to either be able to skip between layers, or you'd need a chip design in which equal, exact proportions of the transistors talk to each other and only to each other with very limited inter-layer communication. And then there's the heat problem.
You want to make software design like designing hardware? Do you *realize* that event-based, serial iteration is what makes software *easier* to create and therefore one can make *more* complex functions with software than with hardware? Do you realize how ridiculously easy modeling a P4 would be using C++? Do you realize how insanely difficult Windows XP would be to describe in VHDL?
This would imply that there is a "proper" price. What you feel you want to pay for whatever they're selling is in no way a method of measuring what they *should* sell their chips at. Supply and demand, remember? They're not there to fullfill your needs and simply take compensation for what it cost them. They're there to make money and if they happen to get you what you want, so much the better. You are not some form of market god to be appeased.
I'm no expert in ASIC design but that doesn't sound like the best thing to have in your extremely sensitive high-speed signals. I assume this field will remain constant and won't provide noise for the chip (or at least I hope) but it will introduce an electrical bias that needs to be planned and compensated for during the chip's layout.
I fail to see why it is not relevent to modern day problems of power consumption. One of the key ideas of IA-64 was to reduce transistor count (as transistors, like power now, were a premium back then). This is indeed true even today as the IA-64 core itself is tiny in comparison to a Netburst or K8 core. The vast majority of the Itanium chips (even moreso than the Netburst or K8 chips) is cache.
As for parallelism, it is very much the "new world". Multicore is the new trend, didn't you hear? With an ISA that has explicit parallelism built in, it would be much easier to do something like the proposed scheme that started this thread.
Of course, the strict design that Intel built into IA-64 does make it less flexible to things such as long memory latencies and such. I don't see it as what I would envision in an explicitly parallel ISA but that's just me.
I don't see why it does. In current ASIC and FPGA design, clock distribution is a huge problem. So much so that a lot of logic is dedicated (more than the simple branch and buffer) to building a clock distribution tree on the chip. Asynchronous logic has to be built to help synchronize and propogate the clock along with incomming signals because of clock skew.
In short, clocking has become a significant enough problem that the added overhead of asynchronous hand-shaking protocols is actually less burdensome in many cases.
Yes and no. Timing problems is really something that occurs in a synchronous design as you have a limited window of time (between clock edges) where your combinatorial circuit must stabilize. This is not the case in asynchronous design. You have all the time in the world to stabilize your stages of logic. When it is stabilized and only when it is stabilized, does it send a signal to the next stage that it is done and to latch the incomming data. So essentially, your design will time itself (as the method implies) and you won't have timing violations because a certain stage took too long to stabilize.
That being said. Asynchronous design does present problems in terms of performance evaluation and circuit design complexity. When you have any form of procssing pipeline where there are loop-backs (and almost any complex circuit does), you have to be able to evaluate how fast data will move through that pipeline since it will take a variable time for certain combinations of data input bits to produce results at the output lines. Optimizing then becomes much more difficult than to run a static timing analysis tool, find the critical path, and optimizing it.
Not really the same thing. VHDL and Verilog resemble a programming language insofar as there is a syntax and simple if-then statements. Other than that, it's a different beast. Hardware simply works differently. It's not a sequential iteration of instructions, it's the concurrent movement of signals.
FPGA's aren't the golden answer currently. Most if not all FPGA's have issues with being used this way. They are programmable, but they're not made or intended to be programmed in the field (despite their name). The majority have a programmable life of maybe 1000 flashes with flash-based FPGA's (ProASIC from Actel for instance) having a life of maybe 100 flashes. They're basically a poor-man's ASIC more than anything else. The technology would have to improve significantly in a much different direction than what the main FPGA market is targetted at before they can be used as adaptive circuit components while live.
Look on Xilinx's website. The Vertex4's (although currently having supply problems) go up to 500MHz (though you probably don't want to run anything at that speed considering that's probably the reg-to-reg limit). These things are literally better system-on-a-chip solutions than any ASICs could be considering what it offers. Integrated micro-processor, bus architecture, peripheral interfaces and non-volatile and volatile memory, with enough pins (BGA package) to expand with off-chip components. Actel even offers mixed-signal FPGA's where you can have your analog and digital circuitry all programmed onto one chip. These things are the future.