Register renaming doesn't always mean there are multiple registers.
In the case of AMD K8 only the FPU has redundant registers the ALU maintains strict serial order.
So
ADD EAX,EBX ADD ECX,EAX
Takes two cycles on the K8 according to public documentation and patent filings.
What essentially happens is EAX in the second case is tagged as "coming from the previous cycle" and the schedule will dispatch it to the ALU after the first cycle.
Just a quick breakdown... x86 => macro_ops which are fed into one of three pipes. The ICU [or Reorder buffer] then lines them up 3 per line and throws them into the 8-way schedulers for each ALU pipe. The ALU schedulers actually split the macro_op into ALU and AGU micro_ops and can run any of them in any order [well so long as program order is followed].
The registers are renamed as they enter the scheduler from their original names like eax, ebx or esp to future file names. Where a conflict exists they are marked with a pipe and distance. This tells the scheduler in which cycle and pipe the current register value is ready. In this way one ALU or AGU can feed another ALU or AGU [or even itself] as quickly as possible [e.g. 0-cycle].
The schedulers for each pipe simply look at when and where the register will be available and delay the insertion into the ALU itself until ready.
The FPU on the otherhand has free/retire/rename files can and can schedule two independent paths but still only one pipe for add and one for mul. Result forwarding is less important in the FPU as it has a higher latency and fewer resources to start with.
Eitherway.
To get the highest IPC on K8 processors you need to use different registers alltogether. Register renaming only helps the scheduler minimize bubbles.
Intel may be different but I suspect their ALU is the same. This is the quickest way to feed results around while sacrificing some parallelizability.
Most benchmarks are not only artificial in nature but flawed in delivery.
Some 32-bit optimized test running on a 64-bit box does not a 64-bit benchmark make.
Games are notoriously useless as they depend more on the entire system than just the processor.
The synthetic benchmarks are just that, etc...
Why not do real tests like "time to zip 1GB file of text, bmp and exes" or "time to compile 1M lines of C++" or... Things where you can actually extract useful information out of.
Seeing that F.E.A.R. gets 1fps higher on a Core than a Turion does not tell me x86_64 is a waste. It tells me that for that game it doesn't matter.
Believe it or not, many people buy computers for more than gaming.
Hello. Go hunt down my CV and look where I work. I know about the insides of the processor.
And as I said unless you remove the dependency alltogether register renaming only helps serialize the pipeline. The idea is you can feed the result off the ALU bus directly into the execution engine again.
That helps keep a low level of bubbles but doesn't help with IPC beyond 1.0
A register-register feed is a zero cycle access. e.g.
MOV EAX,EBX ADD ECX,EAX ADD EDX,ECX
The result each operation will forward to the other and on the K8 core this takes 3 cycles. Without this you'd need a cycle to store back to the register file and a fetch.
This takes at a minimum 4+3*3=13 cycles provided the stack is in the L1 and is DWORD aligned. So the simple step of 3 adds can take either 3 cycles or >10 cycles if you spill. Recall every access to the L1 takes 3 cycles. That is if the DTLB has the mapping, the data is present and there are no pending writes.
That's where having more registers helps. There are a lot of hotspots with pointers or other complicated access where having registers to cache data helps. Crypto and DSP work are two examples, there are many others.
So where ever a statement [or group of statements] have blocks that are independent of each other you can compute them in parallel. Consider something complicated like
p[t[3*x + y*z] + 1] = s[blah blah...]
Whatever, point is the address for p[] and s[] can be computed "serially" in program order but in parallel on the processor if they're not reusing the same registers.
If they have to spill or re-use registers than the cpu can't have two copies of a given register at once.
The x86_64 additions *DO* help performance in many real-world examples from MPEG encoders to cryptographic algorithms to various other register intense algorithms.
As for your last sentence that's so wrong I don't know where to begin.
Look into how much a stack spill costs compared to just using a register to hold a value. Then tell me x86_64 doesn't help.
Also keep in mind not all registers are 64-bit. You can access the *EXTRA* registers as 64-bits, 32-bits, 16-bits and 8-bits if you want.... seriously, actually benchmark code instead of spreading retarded fud.
I hate people like you. There are more benefits to x86_64 than just the friggin extra address lines.
Consider how you write software now. At best you have a few GPRs to work with. Even with register renaming [which all modern x86 processors have] you get at best, let me repeat, at *BEST* serialized performance.
Extra registers means you can do various things at once. Consider a simple loop like
for (x = 0; x 1000; x++) {
t[x].p[2*x] += s[x].q[3*x];
s[x].q[3*x+1] += r[x].q[4*x]; }
Or some complicated pointer/array looking BS like that. in x86_32 world you may fight for registers to figure out the address of those objects, etc. In x86_64 world you would have enough registers. So both statements are executing at the same time.
If you have to use the same registers, even through register renaming you can only run one at a time.
The extra XMM registers give you the same benefit in the FPU world.
So for the love of god and all that is holy, would you actually read the specs for a change?
The problem that the people who understand the scene have is that what's to stop nvidia from deviating from the standards for OpenGL?
Fact is they *already* do that [from what I've read].
So the more and more people use these closed source drivers the more likely they are to get into vendor lockin.
Imagine you're a game developer and you're working on boxes that use nvidia hardware. Then you realize that a particular "feature" of the driver [e.g. misinterpretation of the GL spec] is used in your game and not reproduced in other drivers.
Do you re-write the game to support all other GL vendors or suck it up or ???
Now ATI and nvidia are pretty neck and neck so they stick close to the GL spec. But that in a nutshell is the fear of using closed source drivers.
I dunno, that sounds bogus to me. if the kernel is truly under GPLv2 there is no reason why end users cannot load binary modules.
What the GPLv2 actually says is that if you distribute derivatives of the GPL'ed product you have to make your modifications open source. In no way shape or form is a GPU driver a "derivative" of the Linux kernel. That's like saying Slashdot is a derivative of the glibc project because the Apache server it runs on uses it.
Now if Nvidia started distributing Linux kernels with the drivers integrated into it, that'd be another story. But as I read the GPLv2 end users are allowed making *ANY* modification they want (including adding closed source additions) provided they do not redistribute it publicly.
So legally I don't see the issue. They're not violating the GPLv2 by having them.
While I hate the old folks too, don't discount the younger population.
There are plenty of people in all age groups that suck plenty at driving.
The real problem is people just take it for granted. They assume driving is a right [it isn't] and that they can do whatever they want on the road as a result.
If you made re-testing mandatory for all ages you'd probably see quite a few failures.
And it isn't like the re-test has to be long. just get in the car with the driver, go for 7 minutes doing turns, passing, change lanes, then turn around and come back.
In a city of 700,000 where there are probably around 350,000 drivers [at most] it would take one person about 12 years to test everyone. Hire a staff of 100 and boom you have practical testing schedules. Those 100 people can very likely save millions on the road as they force people to think while they drive.
Nvidias and ATIs "value proposition" is the hardware. The driver is just a required evil.
Opening up the driver projects would mean they could get OSS loving hippies to do all the grunt MTRR/PAT/Register/MMIO/OpenGL hackery for them and they could concentrate on the actual hardware.
It's like AMD or Intel selling an OS. And saying "you must use this OS with this processor". That trick didn't fan out to well for IBM (System/360 anyone?) and wouldn't work for x86 processors either.
Frankly I'm for mandatory re-testing every 5-10 years. You get one chance to pass and if you fail you have to take a weekend or two of drivers ed and retest. Fail again and you go back in the learner permit category.
That would sufficiently piss off and scare people into... KNOWING WHAT THE FUCK THEY ARE DOING.
I swear half of the errors I see drivers make is simply because they forgot the lessons taught in drivers ed. Like checking before switching lanes, turning into the proper lane from a turning lane, not speeding, not tailgating, etc...
Driving isn't hard once you get the feel for the wheel. It just takes vigilence to actually keep up on "10 and 2", checking the blind spots, etc, etc.
and I'll say it again, there is nothing and I repeat nothing worth paying money to see the first time around let alone record and watch later.
Basically this is how TV works. They hype some stupid episode for a week, make it the "must see event of your lifetime" then 3 seconds after the episode airs the next episode is the "must see event of your lifetime.
The way I go about things if I miss an episode it's no biggie. It'll be on again in my lifetime through re-runs syndication.
TiVo is just yet another leach in the pocketbook [financially and socially] that frankly people can just as easily do without.
Yeah, unfortunately it doesn't work that way. Companies like IBM and Microsoft [for instance] are proud of their patent portfolios and even have hall of fames for people with the most patents. They patent every incremental improvement to any process they perform just as a means to screw over any possible competitor.
But that's exactly my point. A lot of the hype for MacOSX is how spiffy cool the desktop is.
I don't care about that.
Granted I've never used Xcode I just don't see the appeal of Macs. Specially now with the Intel move. I'll just end up using GNU tools anyways so I could save a pocket of money and still have a machine.
Well maybe you want to, and I know this may come as a shock,..., have a friggin choice in the matter.
I know if I bought a 2500$ laptop I'd want to be able to run whatever software I want on it. While their hardware looks spiffy (though to be honest no more special than Dell) as a developer I'd have to gouge out my eyes after looking at finder for more than 10 minutes.
Slashdot Mirror
Register renaming doesn't always mean there are multiple registers.
In the case of AMD K8 only the FPU has redundant registers the ALU maintains strict serial order.
So
ADD EAX,EBX
ADD ECX,EAX
Takes two cycles on the K8 according to public documentation and patent filings.
What essentially happens is EAX in the second case is tagged as "coming from the previous cycle" and the schedule will dispatch it to the ALU after the first cycle.
Just a quick breakdown... x86 => macro_ops which are fed into one of three pipes. The ICU [or Reorder buffer] then lines them up 3 per line and throws them into the 8-way schedulers for each ALU pipe. The ALU schedulers actually split the macro_op into ALU and AGU micro_ops and can run any of them in any order [well so long as program order is followed].
The registers are renamed as they enter the scheduler from their original names like eax, ebx or esp to future file names. Where a conflict exists they are marked with a pipe and distance. This tells the scheduler in which cycle and pipe the current register value is ready. In this way one ALU or AGU can feed another ALU or AGU [or even itself] as quickly as possible [e.g. 0-cycle].
The schedulers for each pipe simply look at when and where the register will be available and delay the insertion into the ALU itself until ready.
The FPU on the otherhand has free/retire/rename files can and can schedule two independent paths but still only one pipe for add and one for mul. Result forwarding is less important in the FPU as it has a higher latency and fewer resources to start with.
Eitherway.
To get the highest IPC on K8 processors you need to use different registers alltogether. Register renaming only helps the scheduler minimize bubbles.
Intel may be different but I suspect their ALU is the same. This is the quickest way to feed results around while sacrificing some parallelizability.
Tom
Most benchmarks are not only artificial in nature but flawed in delivery.
... Things where you can actually extract useful information out of.
Some 32-bit optimized test running on a 64-bit box does not a 64-bit benchmark make.
Games are notoriously useless as they depend more on the entire system than just the processor.
The synthetic benchmarks are just that, etc...
Why not do real tests like "time to zip 1GB file of text, bmp and exes" or "time to compile 1M lines of C++" or
Seeing that F.E.A.R. gets 1fps higher on a Core than a Turion does not tell me x86_64 is a waste. It tells me that for that game it doesn't matter.
Believe it or not, many people buy computers for more than gaming.
Tom
I didn't know they were all selling mainframes or clusters as recent as the 90s...
IBMs shift to Linux Happy Happy Land is fairly recent.
If IBM came out today with their own processor running their own OS they would be laughed at.
Tom
Hello. Go hunt down my CV and look where I work. I know about the insides of the processor.
...]
And as I said unless you remove the dependency alltogether register renaming only helps serialize the pipeline. The idea is you can feed the result off the ALU bus directly into the execution engine again.
That helps keep a low level of bubbles but doesn't help with IPC beyond 1.0
A register-register feed is a zero cycle access. e.g.
MOV EAX,EBX
ADD ECX,EAX
ADD EDX,ECX
The result each operation will forward to the other and on the K8 core this takes 3 cycles. Without this you'd need a cycle to store back to the register file and a fetch.
Now consider a spill
MOV EAX,EBX
ADD [ESP+4],EAX
MOV EAX,[ESP+4]
ADD [ESP+8],EAX
This takes at a minimum 4+3*3=13 cycles provided the stack is in the L1 and is DWORD aligned. So the simple step of 3 adds can take either 3 cycles or >10 cycles if you spill. Recall every access to the L1 takes 3 cycles. That is if the DTLB has the mapping, the data is present and there are no pending writes.
That's where having more registers helps. There are a lot of hotspots with pointers or other complicated access where having registers to cache data helps. Crypto and DSP work are two examples, there are many others.
So where ever a statement [or group of statements] have blocks that are independent of each other you can compute them in parallel. Consider something complicated like
p[t[3*x + y*z] + 1] = s[blah blah
Whatever, point is the address for p[] and s[] can be computed "serially" in program order but in parallel on the processor if they're not reusing the same registers.
If they have to spill or re-use registers than the cpu can't have two copies of a given register at once.
Tom
I know there were other vendors. But IBM essentially had a good size market share.
If AIX was such the best route then why do the have the LTC now? Why do they do so much work with Windows? Why do they support both Intel and AMD?
Tom
Mod parent down -1, ignorant.
... seriously, actually benchmark code instead of spreading retarded fud.
The x86_64 additions *DO* help performance in many real-world examples from MPEG encoders to cryptographic algorithms to various other register intense algorithms.
As for your last sentence that's so wrong I don't know where to begin.
Look into how much a stack spill costs compared to just using a register to hold a value. Then tell me x86_64 doesn't help.
Also keep in mind not all registers are 64-bit. You can access the *EXTRA* registers as 64-bits, 32-bits, 16-bits and 8-bits if you want.
Tom
I hate people like you. There are more benefits to x86_64 than just the friggin extra address lines.
Consider how you write software now. At best you have a few GPRs to work with. Even with register renaming [which all modern x86 processors have] you get at best, let me repeat, at *BEST* serialized performance.
Extra registers means you can do various things at once. Consider a simple loop like
for (x = 0; x 1000; x++) {
t[x].p[2*x] += s[x].q[3*x];
s[x].q[3*x+1] += r[x].q[4*x];
}
Or some complicated pointer/array looking BS like that. in x86_32 world you may fight for registers to figure out the address of those objects, etc. In x86_64 world you would have enough registers. So both statements are executing at the same time.
If you have to use the same registers, even through register renaming you can only run one at a time.
The extra XMM registers give you the same benefit in the FPU world.
So for the love of god and all that is holy, would you actually read the specs for a change?
Tom
Solution:
.... *BEFORE* release date.
Give boards to developers
Tom
IBM only dominated because they were essentially the only commercial large scale computer vendor at the time.
Look where they are at now though. Supporting Linux, Windows, AIX, HPUX, etc, etc.
Customers are big fans of choice in some circles.
tom
Oh, then the answer is no. Closed source binaries should NEVER be part of ANY GPL project.
Tom
The problem that the people who understand the scene have is that what's to stop nvidia from deviating from the standards for OpenGL?
Fact is they *already* do that [from what I've read].
So the more and more people use these closed source drivers the more likely they are to get into vendor lockin.
Imagine you're a game developer and you're working on boxes that use nvidia hardware. Then you realize that a particular "feature" of the driver [e.g. misinterpretation of the GL spec] is used in your game and not reproduced in other drivers.
Do you re-write the game to support all other GL vendors or suck it up or ???
Now ATI and nvidia are pretty neck and neck so they stick close to the GL spec. But that in a nutshell is the fear of using closed source drivers.
Tom
I dunno, that sounds bogus to me. if the kernel is truly under GPLv2 there is no reason why end users cannot load binary modules.
What the GPLv2 actually says is that if you distribute derivatives of the GPL'ed product you have to make your modifications open source. In no way shape or form is a GPU driver a "derivative" of the Linux kernel. That's like saying Slashdot is a derivative of the glibc project because the Apache server it runs on uses it.
Now if Nvidia started distributing Linux kernels with the drivers integrated into it, that'd be another story. But as I read the GPLv2 end users are allowed making *ANY* modification they want (including adding closed source additions) provided they do not redistribute it publicly.
So legally I don't see the issue. They're not violating the GPLv2 by having them.
Tom
While I hate the old folks too, don't discount the younger population.
There are plenty of people in all age groups that suck plenty at driving.
The real problem is people just take it for granted. They assume driving is a right [it isn't] and that they can do whatever they want on the road as a result.
If you made re-testing mandatory for all ages you'd probably see quite a few failures.
And it isn't like the re-test has to be long. just get in the car with the driver, go for 7 minutes doing turns, passing, change lanes, then turn around and come back.
In a city of 700,000 where there are probably around 350,000 drivers [at most] it would take one person about 12 years to test everyone. Hire a staff of 100 and boom you have practical testing schedules. Those 100 people can very likely save millions on the road as they force people to think while they drive.
Tom
You're missing the capitalistic incentive.
Nvidias and ATIs "value proposition" is the hardware. The driver is just a required evil.
Opening up the driver projects would mean they could get OSS loving hippies to do all the grunt MTRR/PAT/Register/MMIO/OpenGL hackery for them and they could concentrate on the actual hardware.
It's like AMD or Intel selling an OS. And saying "you must use this OS with this processor". That trick didn't fan out to well for IBM (System/360 anyone?) and wouldn't work for x86 processors either.
Why are GPUs any different?
Tom
Linux should be *open* to using either. If not than it's not really a "open" tool.
The real question is: Should we buy hardware with closed source drivers.
Tom
Their technology is moot and I hope they get bought out by Walmart or something.
Layoff the entire staff, move the BUs to india and be done with.
I swear to god if I hear "I tivo'ed that episode" one more time I'm gonna be linked to some fairly hefty crimes against humanity.
Tom
Frankly I'm for mandatory re-testing every 5-10 years. You get one chance to pass and if you fail you have to take a weekend or two of drivers ed and retest. Fail again and you go back in the learner permit category.
... KNOWING WHAT THE FUCK THEY ARE DOING.
That would sufficiently piss off and scare people into
I swear half of the errors I see drivers make is simply because they forgot the lessons taught in drivers ed. Like checking before switching lanes, turning into the proper lane from a turning lane, not speeding, not tailgating, etc...
Driving isn't hard once you get the feel for the wheel. It just takes vigilence to actually keep up on "10 and 2", checking the blind spots, etc, etc.
Tom
and I'll say it again, there is nothing and I repeat nothing worth paying money to see the first time around let alone record and watch later.
Basically this is how TV works. They hype some stupid episode for a week, make it the "must see event of your lifetime" then 3 seconds after the episode airs the next episode is the "must see event of your lifetime.
The way I go about things if I miss an episode it's no biggie. It'll be on again in my lifetime through re-runs syndication.
TiVo is just yet another leach in the pocketbook [financially and socially] that frankly people can just as easily do without.
Tom
Yeah, unfortunately it doesn't work that way. Companies like IBM and Microsoft [for instance] are proud of their patent portfolios and even have hall of fames for people with the most patents. They patent every incremental improvement to any process they perform just as a means to screw over any possible competitor.
Tom
Yes, but the motivation to ignore the hosts file is because of viruses that could overwrite it.
... if a user level virus couldn't write to the host file ...
So
Think about it.
Tom
tom@localhost ~ $ ls -l /etc/hosts /etc/hosts
-rw-r--r-- 1 root root 519 Oct 19 12:13
....
Why can't windows just make the host files read only.
Click the parent link you fucking slashdot newbie.
Tom
Correction, they're based on GNU tools but aren't standard.
In particular they broke libtool from the way it works on pretty much any BSD or Linux OS to some craptastic inhouse flavour.
Viva gentoo, viva la choice!
Tom
But that's exactly my point. A lot of the hype for MacOSX is how spiffy cool the desktop is.
I don't care about that.
Granted I've never used Xcode I just don't see the appeal of Macs. Specially now with the Intel move. I'll just end up using GNU tools anyways so I could save a pocket of money and still have a machine.
Viva gentoo!
Tom
Well maybe you want to, and I know this may come as a shock, ..., have a friggin choice in the matter.
I know if I bought a 2500$ laptop I'd want to be able to run whatever software I want on it. While their hardware looks spiffy (though to be honest no more special than Dell) as a developer I'd have to gouge out my eyes after looking at finder for more than 10 minutes.
Tom