All the patents required to implement MIPS IV (64-bit) have expired. The ones on SPARCv9 expire this year. Alpha expired last year. There's a reason for caring about the 20-year mark: it makes implementing the architecture a lot safer. We have a research processor that implements the MIPS IV instruction set for this exact reason: we may accidentally infringe some patents, but it is definitely possible to work around them by implementing things however the R4K did.
There is no logical reason that an x86-64 procressor in 64 bit mode would perform faster than 32 bit mode unless you are memory constrained
Or you benefit from more registers. Or you benefit from vastly more 64-bit registers. Or you're doing floating point and benefit from the compiler being able to assume SSE is present and never use x87 arithmetic. Or you're using shared libraries so benefit form faster position-independent code. But, apart from that, no logical reason at all...
The 64-bit address space doesn't give much advantage in typical desktop applications. Even my web browser with a silly number of tabs open at the moment is using
PC-relative addressing makes position-independent code significantly faster. This is useful for shared libraries, but also for position-independent executables which, in combination with address space randomisation, add some security.
SSE is guaranteed to exist. This alone accounts for most of the speedup, because compiling for x87 is really hard (crazy hybrid of a stack- and a register-based architecture), so generating SSE ops for floating point, even if you're only doing scalar arithmetic, is a lot more efficient.
More GPRs. x86-32 code ends up with a lot of stack spills because it only has a tiny number of general-purpose registers. x86-64 has 16, which makes it a lot easier to work with.
64-bit registers. On x86-32, 64-bit arithmetic is painful, because you need two registers for each of the operands, and you only have 6 registers to use (two of which must be used for the destination in a lot of ops). On x86-64, it's a lot easier to do sequences of 64-bit arithmetic without spills.
It also depends a huge amount on the workload. For example the latest Z series and POWER chips have a reasonable amount of die area dedicated to floating point binary coded decimal. For most code, this is wasted space. For COBOL applications, it can be an order of magnitude speedup.
The difference between the vertical integration of a mainframe is that the handful of hard drive suppliers and the two x86 CPU vendors are competing independently for your business. Your choice of hard drive vendor isn't limited by your choice of CPU vendor, or vice versa.
Don't forget the low-cost dumb terminals – I'm sorry: "thin clients" – which are incapable of doing anything at all independently of the centrally-adminstered silicon
The reason that those tend to die out is that the cost of the processor is an increasingly small part of the total cost. Dumb terminals gave way to X terminals because the CRT, keyboard, I/O controllers and packaging were the majority of the cost. Adding in a frame buffer and a little display controller added a little bit to the cost, but a lot to the utility. Of course, once you'd got a display controller and RAM, adding a CPU and a hard disk didn't add very much either. If you wanted to build a thin client now, you'd stick a cheap ARM chip in as the CPU. Even something like a dual or quad-core 1GHz chip will only add $5-10 to the total cost, and adding 32GB or so of Flash also doesn't add much, at which point you have a general purpose computer. These days, the advantage of the remote service is not really to do with consolidating hardware cost, it's:
Better backups, because your data is on a single file server rather than scattered over your organisation.
Easier upgrades, because you just upgrade one machine and all of the thin clients start using the new version immediately.
These aren't really intrinsic to cloudy services. If you have a decent file server then you can use it remotely from fat client applications and get the same storage support, and deploying applications to a whole network is something that was a solved problem even in the NetWare days.
That's great if you are doing something that offloads the entire computation to the GPU. If you have a three-step calculation and it can do the first and third step on the GPU but needs to do the second on the CPU, then the overhead of copying the data across the bus can make that even slower than doing the whole thing on the CPU.
Yes, it does a great deal of that. Since about 2009 or so, a large chunk of basic MATLAB libraries (most matrix operations, including FFTs) automatically use multiple cores with zero added effort.
That's not what he's asking. The individual computation steps in the MATLAB libraries are heavily optimised as individual steps. They're not, however, anywhere near optimal when composed. On the kinds of computation that are typically run with MATLAB, you can often get a one to two order of magnitude speedup by, for example, propagating partial results through the entire pipeline rather than writing them all out to memory and back. It's very easy, if your data set is larger than your CPU's cache, for the memory access times to dominate the calculation time for a MATLAB program.
I'm currently involved in a clean-slate redesign project which involves hardware, compiler and operating systems specialists trying to overcome some of the siloing that the fields have encountered over the past decade or so. I'm nominally a compiler person, but it would be very hard for me to work in this team without a pretty good understanding of how the architecture and operating system work. Now, I don't need to know as much about the hardware as the people who are building it, but when I want to modify the instruction set to make life easier for the compiler then it helps a lot to know about the pipeline structure and the latency of various primitive operations so that I can tell if it's actually possible to implement what I want. The same is true of any interdisciplinary work, and more true the further apart the disciplines are. If you fundamentally don't understand what your colleagues are doing then it's hard to have a common vocabulary to communicate with.
What kind of acceleration do you think you need for non-antialiased, fixed-width text? A bitblt might speed it up in a framebuffer console, but these days memcpy on the CPU is faster, which is why X11 won't use hardware bitblt anymore. On x86, however, the hardware / BIOS provides a text console, and the GPU is free to accelerate it however it wishes. Given that the XT could scroll text faster than the kernel boot messages appear, I doubt this is a bottleneck on any vaguely modern system. You'll get more slowdown from lock contention around the kernel's version of printf than you will from outputting the result to the screen.
The main use is C++ code coexisting in an environment with other high-level languages. By relaxing this constraint, they make it possible to compile C++ to Java or.NET bytecode (handling multiple inheritance is painful, but possible) and have it run in a completely GC'd world. Having conservative GC in C++ isn't that useful, but being able to take a large legacy C++ codebase, recompile it, and run it in today's environment of choice (whatever that happens to be) is.
You might want to look at LLVM a bit more closely, as Juniper, which ships a pretty large number of your chips, is about to start their GCC to Clang migration in the next few months...
It's likely to be very difficult, depending on how the GC is implemented. It would be easy to mix if you don't share objects between thread, but then you may as well use different processes. Mixing different GC policies in a single application is usually quite difficult, but it's possible if your primitive operation is reference counting and you create a full GC by adding concurrent cycle detection. You can then control at different granularities when the cycle detector is run. This gives you realtime allocation and deallocation for acyclic objects in the realtime thread (assuming that your allocator is deterministic), and allows you to explicitly schedule the cycle detector runs.
My understanding was that the GC stuff was added at the request of Microsoft, so that the C++ dialect that they use in.NET can become closer to the standard. The idea is more that you'd have a single C++ codebase that would either run in a.NET VM, or compiled to native code, depending on your deployment target.
It's being worked on. There are patches from Intel that add support, but they're currently under review. There was a big discussion at the last LLVM DevMeeting about the correct way to add support. GCC adds the calls to the OpenMP runtime library very early on in the compile pipeline, which destroys a lot of potential optimisation opportunities. The goal with LLVM is to preserve the parallel loop structure through optimisations and then insert the calls out to the runtime library much later on.
The GPL might encourage that, in theory, but it doesn't in practice. For example, take every MIPS vendor ever. They start with GCC, and then hack it up to support their extensions. In the process, they break every other MIPS target, so their extensions are never pushed upstream. They ship their GCC version to their customers, who are then stuck with an old implementation, with support for old language dialects. This is even worse for supercomputers, with a typical operational life of a decade or so. There are still IBM supercomputers in service that ship with a hacked-up gcc 2.95. This is why there's a lot of interest in BlueGene/Q support in LLVM: it is upstream and the vectorisation support is all in the target-independent layer, so keeping it up to date is simple.
I don't see why C++ needs language-based or standardized garbage collection support
The C++ standard doesn't specify GC, it merely relaxes the constraints on when destructors are called and when memory is reclaimed in such a way that an implementation using garbage collection is now possible. This is more a standard library issue than a compiler one, although in theory a compiler might use GC-managed storage for objects with automatic storage. This support basically means that if you take C++ code and link it against the operator new() implementation provided by the Boehm GC it remains a standards-compliant implementation.
It's not a question of good vs evil, it's a question of generosity vs self interest. The grandparent was claiming that Apple open sourced clang out of generosity. This is not the case, they did so because it is in their best interests to do so. These days, the two biggest contributors to LLVM and Clang are likely Apple and Google, but companies like ARM, Qualcomm, MIPS (or whoever owns them this week), TI, Adobe, and a load of smaller contributors all contribute and Apple gets all of these for free. Some of those contributions aren't necessarily useful to Apple (for example, the MIPS back end), but a lot are (for example, the autovectorisation support).
So it is just like C. It will run anywhere if coded to the standard but you need to take care to optimize for a specific architecture
No, not really. Pretty much any architecture that you run C on will implement the C abstract machine pretty directly. If you restrict yourself to mainstream CPUs (i.e. anything you might run a *NIX OS on, not embedded microcontrollers) then you have very similar performance characteristics, and you improve performance by doing things like reducing data-dapendent flow control and increasing data locality. On a GPU, the differences are far more pronounced. Some will implement operators in microcode, some with dedicated logic. OpenCL encourages you to write kernels that run in parallel, but the synchronisation primitives in hardware and the cost of having kernel flow control diverge vary massively between GPUs (and even more if you compare GPUs to CPUs).
The problem is that there often isn't a better candidate. There are two candidates who have slightly different strengths. Either can do the job you need, and either will bring something extra (but not the same thing) to the team. So you pick one because of some subconscious factor, which you're probably not aware of. Picking based on some algorithm that attempts to guarantee fairness helps suppress these biases.
Affirmative action also has some nasty negative side effects. First, if people are aware of it, then there is a perception that anyone in the group that is being discriminated in favour of got there because of it. If you have to hire a woman for a particular job, and the best qualified woman has ten years more experience than the nearest-qualified man, better references, and does much better in the interview, then she will still have to fight the perception from people who weren't directly involved in the hiring that she only got the job because of her gender.
Beyond that, if people in group X have lower standards of entry into job Y, then the average quality of people of group X performing job Y will be lower. People will notice this, and assume that it's because people in group X suck at Y. It then becomes much harder for the ones that are capable and qualified.
You don't get more competent people into a job by fostering the perception that they aren't able to do it.
If they were predominantly picking the man previously in this situation, then women were discriminated against. If they are picking women if they have under a certain percentage and men if they have over a certain percentage then they are effectively doing round-robin selection.
It's a question of the ratio of the value of owning it to the depreciation. Let's say I'm buying a new laptop and I'm spending $2,000. If it is going to cost $1,000 tomorrow, then I'll buy it tomorrow. But if it's going to cost $1,000 in a year's time, and cost $1,997 tomorrow, then I'll buy it today because the value (to me) of having the laptop over the course of the year is more than $1,000 and the value of having it today is greater than $3. If the value of the laptop would vary by plus or minus 50% over the course of each day, then I'd probably wait for a week and buy it when it the first time it dipped below $1,300 (or some other arbitrary point around there), because then I'd be saving a large amount but still have the new laptop for about as long. Selling laptops in such a market would be very hard, because the profit margin is typically about 5-20%, so I'd end up paying less than the cost of manufacture.
In that case H1B visa holders would not be cheaper and who's going to hire them?
If the problem is really that companies are unwilling to pay the prevailing wage, but the talent is available, then H1Bs are not required. If the problem is really that (as Microsoft, IBM, Google, and so on have claimed) that the talent is not available in the USA at any price, then the companies would happily pay immigrants with full citizenship at the same price that they'd pay US citizens if they were available with the required skills.
Slashdot Mirror
All the patents required to implement MIPS IV (64-bit) have expired. The ones on SPARCv9 expire this year. Alpha expired last year. There's a reason for caring about the 20-year mark: it makes implementing the architecture a lot safer. We have a research processor that implements the MIPS IV instruction set for this exact reason: we may accidentally infringe some patents, but it is definitely possible to work around them by implementing things however the R4K did.
There is no logical reason that an x86-64 procressor in 64 bit mode would perform faster than 32 bit mode unless you are memory constrained
Or you benefit from more registers. Or you benefit from vastly more 64-bit registers. Or you're doing floating point and benefit from the compiler being able to assume SSE is present and never use x87 arithmetic. Or you're using shared libraries so benefit form faster position-independent code. But, apart from that, no logical reason at all...
PC-relative addressing makes position-independent code significantly faster. This is useful for shared libraries, but also for position-independent executables which, in combination with address space randomisation, add some security.
SSE is guaranteed to exist. This alone accounts for most of the speedup, because compiling for x87 is really hard (crazy hybrid of a stack- and a register-based architecture), so generating SSE ops for floating point, even if you're only doing scalar arithmetic, is a lot more efficient.
More GPRs. x86-32 code ends up with a lot of stack spills because it only has a tiny number of general-purpose registers. x86-64 has 16, which makes it a lot easier to work with.
64-bit registers. On x86-32, 64-bit arithmetic is painful, because you need two registers for each of the operands, and you only have 6 registers to use (two of which must be used for the destination in a lot of ops). On x86-64, it's a lot easier to do sequences of 64-bit arithmetic without spills.
It also depends a huge amount on the workload. For example the latest Z series and POWER chips have a reasonable amount of die area dedicated to floating point binary coded decimal. For most code, this is wasted space. For COBOL applications, it can be an order of magnitude speedup.
The difference between the vertical integration of a mainframe is that the handful of hard drive suppliers and the two x86 CPU vendors are competing independently for your business. Your choice of hard drive vendor isn't limited by your choice of CPU vendor, or vice versa.
Don't forget the low-cost dumb terminals – I'm sorry: "thin clients" – which are incapable of doing anything at all independently of the centrally-adminstered silicon
The reason that those tend to die out is that the cost of the processor is an increasingly small part of the total cost. Dumb terminals gave way to X terminals because the CRT, keyboard, I/O controllers and packaging were the majority of the cost. Adding in a frame buffer and a little display controller added a little bit to the cost, but a lot to the utility. Of course, once you'd got a display controller and RAM, adding a CPU and a hard disk didn't add very much either. If you wanted to build a thin client now, you'd stick a cheap ARM chip in as the CPU. Even something like a dual or quad-core 1GHz chip will only add $5-10 to the total cost, and adding 32GB or so of Flash also doesn't add much, at which point you have a general purpose computer. These days, the advantage of the remote service is not really to do with consolidating hardware cost, it's:
These aren't really intrinsic to cloudy services. If you have a decent file server then you can use it remotely from fat client applications and get the same storage support, and deploying applications to a whole network is something that was a solved problem even in the NetWare days.
That's great if you are doing something that offloads the entire computation to the GPU. If you have a three-step calculation and it can do the first and third step on the GPU but needs to do the second on the CPU, then the overhead of copying the data across the bus can make that even slower than doing the whole thing on the CPU.
Yes, it does a great deal of that. Since about 2009 or so, a large chunk of basic MATLAB libraries (most matrix operations, including FFTs) automatically use multiple cores with zero added effort.
That's not what he's asking. The individual computation steps in the MATLAB libraries are heavily optimised as individual steps. They're not, however, anywhere near optimal when composed. On the kinds of computation that are typically run with MATLAB, you can often get a one to two order of magnitude speedup by, for example, propagating partial results through the entire pipeline rather than writing them all out to memory and back. It's very easy, if your data set is larger than your CPU's cache, for the memory access times to dominate the calculation time for a MATLAB program.
I'm currently involved in a clean-slate redesign project which involves hardware, compiler and operating systems specialists trying to overcome some of the siloing that the fields have encountered over the past decade or so. I'm nominally a compiler person, but it would be very hard for me to work in this team without a pretty good understanding of how the architecture and operating system work. Now, I don't need to know as much about the hardware as the people who are building it, but when I want to modify the instruction set to make life easier for the compiler then it helps a lot to know about the pipeline structure and the latency of various primitive operations so that I can tell if it's actually possible to implement what I want. The same is true of any interdisciplinary work, and more true the further apart the disciplines are. If you fundamentally don't understand what your colleagues are doing then it's hard to have a common vocabulary to communicate with.
What kind of acceleration do you think you need for non-antialiased, fixed-width text? A bitblt might speed it up in a framebuffer console, but these days memcpy on the CPU is faster, which is why X11 won't use hardware bitblt anymore. On x86, however, the hardware / BIOS provides a text console, and the GPU is free to accelerate it however it wishes. Given that the XT could scroll text faster than the kernel boot messages appear, I doubt this is a bottleneck on any vaguely modern system. You'll get more slowdown from lock contention around the kernel's version of printf than you will from outputting the result to the screen.
The main use is C++ code coexisting in an environment with other high-level languages. By relaxing this constraint, they make it possible to compile C++ to Java or .NET bytecode (handling multiple inheritance is painful, but possible) and have it run in a completely GC'd world. Having conservative GC in C++ isn't that useful, but being able to take a large legacy C++ codebase, recompile it, and run it in today's environment of choice (whatever that happens to be) is.
You might want to look at LLVM a bit more closely, as Juniper, which ships a pretty large number of your chips, is about to start their GCC to Clang migration in the next few months...
It's likely to be very difficult, depending on how the GC is implemented. It would be easy to mix if you don't share objects between thread, but then you may as well use different processes. Mixing different GC policies in a single application is usually quite difficult, but it's possible if your primitive operation is reference counting and you create a full GC by adding concurrent cycle detection. You can then control at different granularities when the cycle detector is run. This gives you realtime allocation and deallocation for acyclic objects in the realtime thread (assuming that your allocator is deterministic), and allows you to explicitly schedule the cycle detector runs.
My understanding was that the GC stuff was added at the request of Microsoft, so that the C++ dialect that they use in .NET can become closer to the standard. The idea is more that you'd have a single C++ codebase that would either run in a .NET VM, or compiled to native code, depending on your deployment target.
It's being worked on. There are patches from Intel that add support, but they're currently under review. There was a big discussion at the last LLVM DevMeeting about the correct way to add support. GCC adds the calls to the OpenMP runtime library very early on in the compile pipeline, which destroys a lot of potential optimisation opportunities. The goal with LLVM is to preserve the parallel loop structure through optimisations and then insert the calls out to the runtime library much later on.
The GPL might encourage that, in theory, but it doesn't in practice. For example, take every MIPS vendor ever. They start with GCC, and then hack it up to support their extensions. In the process, they break every other MIPS target, so their extensions are never pushed upstream. They ship their GCC version to their customers, who are then stuck with an old implementation, with support for old language dialects. This is even worse for supercomputers, with a typical operational life of a decade or so. There are still IBM supercomputers in service that ship with a hacked-up gcc 2.95. This is why there's a lot of interest in BlueGene/Q support in LLVM: it is upstream and the vectorisation support is all in the target-independent layer, so keeping it up to date is simple.
I don't see why C++ needs language-based or standardized garbage collection support
The C++ standard doesn't specify GC, it merely relaxes the constraints on when destructors are called and when memory is reclaimed in such a way that an implementation using garbage collection is now possible. This is more a standard library issue than a compiler one, although in theory a compiler might use GC-managed storage for objects with automatic storage. This support basically means that if you take C++ code and link it against the operator new() implementation provided by the Boehm GC it remains a standards-compliant implementation.
It's not a question of good vs evil, it's a question of generosity vs self interest. The grandparent was claiming that Apple open sourced clang out of generosity. This is not the case, they did so because it is in their best interests to do so. These days, the two biggest contributors to LLVM and Clang are likely Apple and Google, but companies like ARM, Qualcomm, MIPS (or whoever owns them this week), TI, Adobe, and a load of smaller contributors all contribute and Apple gets all of these for free. Some of those contributions aren't necessarily useful to Apple (for example, the MIPS back end), but a lot are (for example, the autovectorisation support).
So it is just like C. It will run anywhere if coded to the standard but you need to take care to optimize for a specific architecture
No, not really. Pretty much any architecture that you run C on will implement the C abstract machine pretty directly. If you restrict yourself to mainstream CPUs (i.e. anything you might run a *NIX OS on, not embedded microcontrollers) then you have very similar performance characteristics, and you improve performance by doing things like reducing data-dapendent flow control and increasing data locality. On a GPU, the differences are far more pronounced. Some will implement operators in microcode, some with dedicated logic. OpenCL encourages you to write kernels that run in parallel, but the synchronisation primitives in hardware and the cost of having kernel flow control diverge vary massively between GPUs (and even more if you compare GPUs to CPUs).
I've been using eJabberd for about a decade but I've heard a few people mention OpenFire recently. What advantage does it have?
The problem is that there often isn't a better candidate. There are two candidates who have slightly different strengths. Either can do the job you need, and either will bring something extra (but not the same thing) to the team. So you pick one because of some subconscious factor, which you're probably not aware of. Picking based on some algorithm that attempts to guarantee fairness helps suppress these biases.
Affirmative action also has some nasty negative side effects. First, if people are aware of it, then there is a perception that anyone in the group that is being discriminated in favour of got there because of it. If you have to hire a woman for a particular job, and the best qualified woman has ten years more experience than the nearest-qualified man, better references, and does much better in the interview, then she will still have to fight the perception from people who weren't directly involved in the hiring that she only got the job because of her gender.
Beyond that, if people in group X have lower standards of entry into job Y, then the average quality of people of group X performing job Y will be lower. People will notice this, and assume that it's because people in group X suck at Y. It then becomes much harder for the ones that are capable and qualified.
You don't get more competent people into a job by fostering the perception that they aren't able to do it.
If they were predominantly picking the man previously in this situation, then women were discriminated against. If they are picking women if they have under a certain percentage and men if they have over a certain percentage then they are effectively doing round-robin selection.
The US educational system has done a serious mindfuck on you if you believe that a right means something that is enumerated in the constitution.
It's a question of the ratio of the value of owning it to the depreciation. Let's say I'm buying a new laptop and I'm spending $2,000. If it is going to cost $1,000 tomorrow, then I'll buy it tomorrow. But if it's going to cost $1,000 in a year's time, and cost $1,997 tomorrow, then I'll buy it today because the value (to me) of having the laptop over the course of the year is more than $1,000 and the value of having it today is greater than $3. If the value of the laptop would vary by plus or minus 50% over the course of each day, then I'd probably wait for a week and buy it when it the first time it dipped below $1,300 (or some other arbitrary point around there), because then I'd be saving a large amount but still have the new laptop for about as long. Selling laptops in such a market would be very hard, because the profit margin is typically about 5-20%, so I'd end up paying less than the cost of manufacture.
In that case H1B visa holders would not be cheaper and who's going to hire them?
If the problem is really that companies are unwilling to pay the prevailing wage, but the talent is available, then H1Bs are not required. If the problem is really that (as Microsoft, IBM, Google, and so on have claimed) that the talent is not available in the USA at any price, then the companies would happily pay immigrants with full citizenship at the same price that they'd pay US citizens if they were available with the required skills.