Ah, its the old bullshit "completely free software stack for rendering the web" argument from a browser that already happily uses Flash, QuickTime, and WMP in order to render a lot of the multimedia content on the web.
Here is an idea.. stop using each and every external component installed on peoples computers that turns out to be required to render the existing web, or stop using this bullshit inconsistent argument when firefox is already more than happy to use other 3rd party stuff to render the existing web.
No, but you can do branching between each set of operations. If you're doing a matrix operation, then you can do a couple of SIMD operation on a row, then a branch based on the result. This is pretty fast on most CPUs, it's painfully slow on a GPU.
You are doing it wrong. The branching is only one of your issues. You are preventing coalesced reads, as well as causing bank conflicts in shared memory.
What you are describing is effectively "gimped" from the start. You have a single matrix but want to leverage instructions which operate on multiple data. Sure, the matrix is made up of multiple data.. but what you should be doing is operating on many matrices (hundreds.. thousands even) at the same time... Certainly you know the difference between AoS (Array of Structures), SoA (Structure of Arrays), and SoAoS (Structure of Arrays of Structures)
If you cannot do this, then performance isnt really the concern that you are making it out to be (I don't care how big the matrix is.)
And performance dies screaming at the first branch instruction.
You cant do separate branching *at all* between the multiple scalers within a SIMD vector. All the scalers have the same operations performed on them.
You seem to be confused about why the negative performance of branching matters on GPU's... its not because it impacts their SIMD capabilities.. because it doesnt.. its because it impacts their CPU-like "GPGPU" capabilities... which means... what I said is 100% correct:
If you are doing heavy SIMD work, get a pile of GPU's.
it also has two 256-bit vector pipelines that provide SIMD floating-point operations so powerful that a single 1ghz core can do 1080p at over 100 frames a second.
In these modern times, if you are going to be doing lots of SIMD on your HPC, you will replace the 10,000 CPU's with 500 GPU's + 500 CPU's to drive them.
In both the Senate and the House, only 1 republican voted for the healthcare bill. Thats it. 1 republican.
All that wheeling and dealing that destroyed any real semblance of a decent healthcare bill was done to get enough Democrats on board, not Republicans. Let me repeat.. only 1 republican voted for the healthcare bill.
It is no surprise why the Democrats want so desperately to blame the healthcare bill on the Republicans.. what is surprising is people like you, that believe them when they say it.
Only in compromising with the GOP did the plan get transmogrified into a tax money transfer to the healthcare industry. But somehow you're going to blame the Democrats for this?
The senate vote went 60 to 39: The yea votes were 58 democrats, 2 independents, 0 republicans.
The house vote went 220 to 215: The yea votes were 219 democrats, 1 republican.
Its quite clear from the facts that the democrats are the ones that transmogrified the bill into a transfer of wealth to the healthcare industry. Only 1 republican voted for the thing, so clearly any concessions that were made were to get democrats on board, not the republicans.
Now why do you suppose it is that you think that the republicans fucked over the healthcare bill? Seriously. Think about that. Could it be that you were lied to by the democrats and the media.. again, and you didn't bother to question it.. again?
The Democrats own the healthcare bill. Any problems you have with it are their fault, even when they (not surprisingly) tell you otherwise.
The members of state governments during those negotiations purchased the votes of the union members with money from the future. There are no caps on how much future money can be promised so it turns into reckless amounts that predictably bankrupts state governments as the future turns into the present at the present rate of 1 second per second.
Pensions and any other form of future money should not be on the table during contract negotiations for this very reason. This is entirely the point of the Republicans on this matter who are not saying that these public sectors workers can't negotiate their wages and working conditions, but instead are saying that they cannot negotiate over vast sums of future money.
It certainly seems reasonable to suspect that negotiations over future money by people in the present can only end badly for the future payer who will clearly not be fairly represented by the negotiators.
Actually, the concept of "shareware" was created first with the Mac terminal application "RedRyder" ( back then we called them "programs", sonny!).
PC-Talk was a terminal program written in BASIC, is well known to be the first shareware program as it was freeware but asked for donations, and its distribution was in fact simply the.BAS source code (so it was also open source in 1982.)
Originally the FPU was only implemented in hardware via installing a co-processor alongside the CPU. Thus, there was (for instance) the 80386 and if you wanted to add an FPU, the 80387 math co-processor. These days the instruction set is simply an extension, like SSE/etc, but is still called x87.
Windows has had a very well-defined meaning for DPI, and has done since XP. EVERYTHING is supposed to scale with the DPI setting.
Its simple to prove that you are full of shit. Win7 -> Display properties control panel -> DPI setting -> there is a checkbox which enables "use Windows XP style DPI scaling"
How can it have a well defined meaning since XP given this simple observable fact? Seriously.. you are full of shit, and have greatly over-estimated the complexity of the bullshit that is the clearly not well defined DPI setting.
After it seems clear the rewrite count is going to hell - 5000/cell for 32 nm, 3000/cell for 25 nm, SSDs are going to have a helluva time catching up in cost/GB.
With these reduced process sizes come higher capacities, so the overall erase limit as measured in GB on these devices ends up being nearly the same per unit area (32*32 = 1024, 25*25 = 625.... 1024/625 is approximately 5000/3000)
Furthermore, the erase limits as measured in GB of the higher capacity SSD's were and continue to be enormous. The (now old) 80GB X25-M drive can sustain over 200GB per day of block erases for over 5 years.. (Intel figures it to be "only" equivalent to 100GB/day in random writes due to write amplification and wear leveling inefficiencies.. note that that is larger than the entire drive, including its 16GB of hidden space)
The flash technology can go down to much lower erase cycles as long as capacities per unit area grow in lock-step with it.. it would still be "only" 200GB/day of erase limit over 5 years for the same package size.
Probably because there is no definition of "DPI aware."
Probably what you want is for firefox to scale only its UI elements.. and it can... it just doesnt do it based on an OS setting that doesnt have a clearly defined meaning (ie, should the displayed document also be scaled, or just the applications UI elements? Maybe text in the document, but not margins?).. remember that your DPI setting in all probability doesnt actually describe your monitors physical DPI.
My guess is that as you read this, that you dont even know your monitors physical DPI and have just used that setting to make the largest set of "DPI aware" programs that you use "look better" at the distance you use your computer from, while making some of them look worse with that same setting. Thats the crux of the "DPI aware" problem, and why many UI programmers say "fuck that, I'm going to let users do it independently of a global OS setting whose name itself is a fucking lie."
Video conversion, CAD, data processing, compiling very complex programs, software 3d rendering. This is slashdot, I'm sure you can think of your own use cases.
If you are really serious about that stuff specifically, you can get significantly better performance for the same cash from some server-build options such as this 32-core server.
The trouble with using expensive consumer chips for embarrassingly parallel tasks is that they dont compete vs the low end server solutions that are at the same price point. If money is no object, then here is a 48-core high end solution that will perform nearly 300% better than the best i7.
x87 is fully supported by the hardware in x64 mode but a kernel and drivers may willfully not save the x87 state during exceptions, interrupts, and system calls.
The route Microsoft finally settled on after the uproar over the rumors that x87 would be to disallow (verboten) any kernel/drivers/ring0 code from using the FPU, and because that code never trashes the FPU, they also dont need to save the FPU state. The original rumor brought a fear that the OS would also not save the FPU's state during a task switch, which would have made the FPU near impossible to use in x64 mode, but that is simply not the case.
Some OS's may not save the state during a task switch, and on those OS's the FPU wouldnt be usable. I dont believe that any of the major OS's neglect to save the state in this case, meaning that the x87 is usable in user mode on all of them.
They needed Microsoft to bail them out because otherwise they were going to go bankrupt. The position they put themselves in in the 80's, while on the surface made them money, had them struggling all through the 90's, leading to the 1997 MacWorld where my signature quote is from. Thats the MacWorld where Steve Jobs introduced BILL FUCKING GATES, the SAVIOR of Apple.
How quickly people forget how huge Apples mistakes were, and how dire their position had become. My generation watched it go down. Your generation doesnt even know that Apple was completely bankrupt by 1997, and needed Microsoft to save them.
RISC won 20 years ago, all x86 processors decode to some internal instruction set. I am certain the engineers at Intel and AMD have tested exposing the native instructions and if it could perform much faster than x86 I'm sure they'd enable applications to bypass the hardware decoder and send micro-ops directly.
No need, as they are already exposed directly. Plenty of instructions that emit a single micro-op... for example, most of AMD's DirectPath instructions emit a single micro-op and in fact, 100% of AMD's micro-op's can be found in the set of DirectPath instructions.
Most (all?) 64-bit compilers produce SSE single precision and double precision code by default. It is the x87 stack that is the odd-man out, contrary to what you are making it sound like.
All x64 CPU's support both single and double precision SSE, which is why its the default for 64-bit targets. If you are targeting a 32-bit OS, then a 32-bit binary cannot simply assume that single precision SSE is available, let alone the later double-precision support of SSE2.
Also, the x87 FPU performs calculations in 80-bit precision, so is not directly comparable to SSE's single and double precision features.
Finally, it is not "some compilers".. its ALL THE MAJOR ONES, both 32-bit and 64-bit.
First, they gambled on the education market being important (they got the big government contracts to put computers in classrooms, at considerable expense to them)
Second, they thought that developers were the market that they should try to squeeze (development tools were not free.)
Now Apple is squeezing developers again on their mobile devices, but this time it doesnt seem to matter so much. Their large market share certainly has something to do with that.
In case you were not aware, back then Microsoft was into everything.. including Apple II's.
This idea that Microsoft "rode IBM to the top" ignores the fact that no matter who won, Microsoft was going to be there on whatever platform won.
That Apple II was running a Microsoft Basic renamed Applesoft BASIC.
That Commodore 64 was running a Microsoft BASIC renamed PET BASIC and later Commodore BASIC.
That Tandy TRS-80 was running a Microsoft BASIC named Color BASIC.
That CP/M machine was running a Microsoft BASIC named MBASIC.
The ATARI's were running a Microsoft BASIC named Atari Microsoft BASIC.
In most cases, Microsoft had its hands directly into the ROM's of these machines. Sure, MSDOS eventually dominated the market.. but Microsoft was already dominating almost all of the markets ANYWAYS.
Slashdot Mirror
A wise man once said, "Neural Networks are always the second best solution to a problem"
Ah, its the old bullshit "completely free software stack for rendering the web" argument from a browser that already happily uses Flash, QuickTime, and WMP in order to render a lot of the multimedia content on the web.
Here is an idea.. stop using each and every external component installed on peoples computers that turns out to be required to render the existing web, or stop using this bullshit inconsistent argument when firefox is already more than happy to use other 3rd party stuff to render the existing web.
No, but you can do branching between each set of operations. If you're doing a matrix operation, then you can do a couple of SIMD operation on a row, then a branch based on the result. This is pretty fast on most CPUs, it's painfully slow on a GPU.
You are doing it wrong. The branching is only one of your issues. You are preventing coalesced reads, as well as causing bank conflicts in shared memory.
What you are describing is effectively "gimped" from the start. You have a single matrix but want to leverage instructions which operate on multiple data. Sure, the matrix is made up of multiple data.. but what you should be doing is operating on many matrices (hundreds.. thousands even) at the same time... Certainly you know the difference between AoS (Array of Structures), SoA (Structure of Arrays), and SoAoS (Structure of Arrays of Structures)
If you cannot do this, then performance isnt really the concern that you are making it out to be (I don't care how big the matrix is.)
And performance dies screaming at the first branch instruction.
You cant do separate branching *at all* between the multiple scalers within a SIMD vector. All the scalers have the same operations performed on them.
You seem to be confused about why the negative performance of branching matters on GPU's... its not because it impacts their SIMD capabilities.. because it doesnt.. its because it impacts their CPU-like "GPGPU" capabilities... which means... what I said is 100% correct:
If you are doing heavy SIMD work, get a pile of GPU's.
it also has two 256-bit vector pipelines that provide SIMD floating-point operations so powerful that a single 1ghz core can do 1080p at over 100 frames a second.
In these modern times, if you are going to be doing lots of SIMD on your HPC, you will replace the 10,000 CPU's with 500 GPU's + 500 CPU's to drive them.
Its cheaper to buy, and cheaper to operate.
In both the Senate and the House, only 1 republican voted for the healthcare bill. Thats it. 1 republican.
All that wheeling and dealing that destroyed any real semblance of a decent healthcare bill was done to get enough Democrats on board, not Republicans. Let me repeat.. only 1 republican voted for the healthcare bill.
It is no surprise why the Democrats want so desperately to blame the healthcare bill on the Republicans.. what is surprising is people like you, that believe them when they say it.
The inverse square law doesnt apply to coherent light like that emitted by lasers.
Only in compromising with the GOP did the plan get transmogrified into a tax money transfer to the healthcare industry. But somehow you're going to blame the Democrats for this?
The senate vote went 60 to 39: The yea votes were 58 democrats, 2 independents, 0 republicans.
The house vote went 220 to 215: The yea votes were 219 democrats, 1 republican.
Its quite clear from the facts that the democrats are the ones that transmogrified the bill into a transfer of wealth to the healthcare industry. Only 1 republican voted for the thing, so clearly any concessions that were made were to get democrats on board, not the republicans.
Now why do you suppose it is that you think that the republicans fucked over the healthcare bill? Seriously. Think about that. Could it be that you were lied to by the democrats and the media.. again, and you didn't bother to question it.. again?
The Democrats own the healthcare bill. Any problems you have with it are their fault, even when they (not surprisingly) tell you otherwise.
Translation:
The members of state governments during those negotiations purchased the votes of the union members with money from the future. There are no caps on how much future money can be promised so it turns into reckless amounts that predictably bankrupts state governments as the future turns into the present at the present rate of 1 second per second.
Pensions and any other form of future money should not be on the table during contract negotiations for this very reason. This is entirely the point of the Republicans on this matter who are not saying that these public sectors workers can't negotiate their wages and working conditions, but instead are saying that they cannot negotiate over vast sums of future money.
It certainly seems reasonable to suspect that negotiations over future money by people in the present can only end badly for the future payer who will clearly not be fairly represented by the negotiators.
Actually, the concept of "shareware" was created first with the Mac terminal application "RedRyder" ( back then we called them "programs", sonny!).
PC-Talk was a terminal program written in BASIC, is well known to be the first shareware program as it was freeware but asked for donations, and its distribution was in fact simply the .BAS source code (so it was also open source in 1982.)
You've got your history mixed up, young man.
Originally the FPU was only implemented in hardware via installing a co-processor alongside the CPU. Thus, there was (for instance) the 80386 and if you wanted to add an FPU, the 80387 math co-processor. These days the instruction set is simply an extension, like SSE/etc, but is still called x87.
Windows has had a very well-defined meaning for DPI, and has done since XP. EVERYTHING is supposed to scale with the DPI setting.
Its simple to prove that you are full of shit. Win7 -> Display properties control panel -> DPI setting -> there is a checkbox which enables "use Windows XP style DPI scaling"
How can it have a well defined meaning since XP given this simple observable fact? Seriously.. you are full of shit, and have greatly over-estimated the complexity of the bullshit that is the clearly not well defined DPI setting.
After it seems clear the rewrite count is going to hell - 5000/cell for 32 nm, 3000/cell for 25 nm, SSDs are going to have a helluva time catching up in cost/GB.
With these reduced process sizes come higher capacities, so the overall erase limit as measured in GB on these devices ends up being nearly the same per unit area (32*32 = 1024, 25*25 = 625 .... 1024/625 is approximately 5000/3000)
.. note that that is larger than the entire drive, including its 16GB of hidden space)
Furthermore, the erase limits as measured in GB of the higher capacity SSD's were and continue to be enormous. The (now old) 80GB X25-M drive can sustain over 200GB per day of block erases for over 5 years.. (Intel figures it to be "only" equivalent to 100GB/day in random writes due to write amplification and wear leveling inefficiencies
The flash technology can go down to much lower erase cycles as long as capacities per unit area grow in lock-step with it.. it would still be "only" 200GB/day of erase limit over 5 years for the same package size.
Probably because there is no definition of "DPI aware."
.. remember that your DPI setting in all probability doesnt actually describe your monitors physical DPI.
Probably what you want is for firefox to scale only its UI elements.. and it can... it just doesnt do it based on an OS setting that doesnt have a clearly defined meaning (ie, should the displayed document also be scaled, or just the applications UI elements? Maybe text in the document, but not margins?)
My guess is that as you read this, that you dont even know your monitors physical DPI and have just used that setting to make the largest set of "DPI aware" programs that you use "look better" at the distance you use your computer from, while making some of them look worse with that same setting. Thats the crux of the "DPI aware" problem, and why many UI programmers say "fuck that, I'm going to let users do it independently of a global OS setting whose name itself is a fucking lie."
Video conversion, CAD, data processing, compiling very complex programs, software 3d rendering. This is slashdot, I'm sure you can think of your own use cases.
If you are really serious about that stuff specifically, you can get significantly better performance for the same cash from some server-build options such as this 32-core server.
The trouble with using expensive consumer chips for embarrassingly parallel tasks is that they dont compete vs the low end server solutions that are at the same price point. If money is no object, then here is a 48-core high end solution that will perform nearly 300% better than the best i7.
Thats exactly what I mean. You started using computers over half way through the 80's, after the mistakes had already been made.
Apple was the king of desktops, until the strategic reality of their mistakes set in.
You are too young. Get off my lawn.
x87 is fully supported by the hardware in x64 mode but a kernel and drivers may willfully not save the x87 state during exceptions, interrupts, and system calls.
The route Microsoft finally settled on after the uproar over the rumors that x87 would be to disallow (verboten) any kernel/drivers/ring0 code from using the FPU, and because that code never trashes the FPU, they also dont need to save the FPU state. The original rumor brought a fear that the OS would also not save the FPU's state during a task switch, which would have made the FPU near impossible to use in x64 mode, but that is simply not the case.
Some OS's may not save the state during a task switch, and on those OS's the FPU wouldnt be usable. I dont believe that any of the major OS's neglect to save the state in this case, meaning that the x87 is usable in user mode on all of them.
Yeah. Squeezing developers. You can download their development tools for free.
What good is that when you cannot distribute your software without giving Apple 30% of the revenue?
Why are you being willfully obtuse to the facts of the matter? Fanboy? Is that it?
They needed Microsoft to bail them out because otherwise they were going to go bankrupt. The position they put themselves in in the 80's, while on the surface made them money, had them struggling all through the 90's, leading to the 1997 MacWorld where my signature quote is from. Thats the MacWorld where Steve Jobs introduced BILL FUCKING GATES, the SAVIOR of Apple.
Full 1997 MacWorld video Bill Gates starts at the 31 minute mark
How quickly people forget how huge Apples mistakes were, and how dire their position had become. My generation watched it go down. Your generation doesnt even know that Apple was completely bankrupt by 1997, and needed Microsoft to save them.
Now get off my lawn.
The ROM BASIC's in many of those machines was the most important feature. It was, in those cases, their native operating system.
You apparently arent old enough to know this shit, so get off my lawn.
RISC won 20 years ago, all x86 processors decode to some internal instruction set. I am certain the engineers at Intel and AMD have tested exposing the native instructions and if it could perform much faster than x86 I'm sure they'd enable applications to bypass the hardware decoder and send micro-ops directly.
No need, as they are already exposed directly. Plenty of instructions that emit a single micro-op... for example, most of AMD's DirectPath instructions emit a single micro-op and in fact, 100% of AMD's micro-op's can be found in the set of DirectPath instructions.
Most (all?) 64-bit compilers produce SSE single precision and double precision code by default. It is the x87 stack that is the odd-man out, contrary to what you are making it sound like.
All x64 CPU's support both single and double precision SSE, which is why its the default for 64-bit targets. If you are targeting a 32-bit OS, then a 32-bit binary cannot simply assume that single precision SSE is available, let alone the later double-precision support of SSE2.
Also, the x87 FPU performs calculations in 80-bit precision, so is not directly comparable to SSE's single and double precision features.
Finally, it is not "some compilers".. its ALL THE MAJOR ONES, both 32-bit and 64-bit.
In the 80's, Apple failed on two fronts.
First, they gambled on the education market being important (they got the big government contracts to put computers in classrooms, at considerable expense to them)
Second, they thought that developers were the market that they should try to squeeze (development tools were not free.)
Now Apple is squeezing developers again on their mobile devices, but this time it doesnt seem to matter so much. Their large market share certainly has something to do with that.
And Microsofts:
1) Microsoft
2) Developers
3) Publishers
4) Users
In case you were not aware, back then Microsoft was into everything.. including Apple II's.
This idea that Microsoft "rode IBM to the top" ignores the fact that no matter who won, Microsoft was going to be there on whatever platform won.
That Apple II was running a Microsoft Basic renamed Applesoft BASIC.
That Commodore 64 was running a Microsoft BASIC renamed PET BASIC and later Commodore BASIC.
That Tandy TRS-80 was running a Microsoft BASIC named Color BASIC.
That CP/M machine was running a Microsoft BASIC named MBASIC.
The ATARI's were running a Microsoft BASIC named Atari Microsoft BASIC.
In most cases, Microsoft had its hands directly into the ROM's of these machines. Sure, MSDOS eventually dominated the market.. but Microsoft was already dominating almost all of the markets ANYWAYS.