Because it certainly does n't sound like it is in object orientated program design. Being able to code is just one part of being a skilled programer, being a "rockstar" style coder may seem impressive but banging out pages of code at a time is never a good sign and I say this as someone who spent a good five years working this way.
It is only when you have to maintain your own code for years that you start to step back and think more because at the end of the day you can not code your way out of trouble, well you can but the result is never pretty or maintainable.
Personally I find that I spend around 25% thinking, 25% coding, 25% testing and 25% documenting any one problem. The 50% spent testing and documenting is n't fun by anymeans but it's a necessary discipline. It's all about taming your inner coder and I think this is what the majority of these frameworks do indirectly by creating road blocks so that you have to hit the breaks every so often.
I use Visual Studio and never heard of it before today yet apparently I should have because it is now being integrated in to a product that I use on a daily basis.
Just saying that going with Android makes Nokia another "me too" company totally discounts that Noka phones are always beautifully designed and very robust.
The last two nokia phones I've had have terrible software problems but I could not fault the hardware. Where as my experience with HTC phones one had a joystick that broke and my current HD2 has had the USB power connector fail on me.
If they had gone with Android they could have easily competed with Samsung and had a good percentage of the Android smartphone market. The problem is Elop somehow managed to convince people that with Windows Mobile he could restore past glory and be like Apple. Sure they now have nearly have 100% of the Windows Mobile market, but whats that at the moment? 1% of smartphones?
The thing is Elop does n't understand the industry, he came from Microsoft. He's a Microsoft man, the question at the time should have been something like this "We have two available OS options, one has a proven record of being something customers want and the other has failed pretty badly up to now." . Which one would you go with? Sure you will have to compete with Samsung with the same OS, but they're now competing with Apple, Samsung and everyone else with a different OS and failing badly.
Regardless, it's a moot point now but I don't recall anyone at the time saying this was going to end well for Nokia.
There is no way the goverrnment could enforce that kind of behaviour, if they could they would have used that ability to collect the correct amount of corporation tax in the first place.
The problem is VAT is n't a tax on companies, it is a tax on consumers with the companies being able to claim back their VAT expenses due to them acting as tax collectors for the government. An increase in VAT would immediately be passed on to the consumer.
> In the end, the few uses of conditional execution
That why x86 introduced cmov for doing conditional mov ?
I'd wager that there is n't a conditional move uOP when the x86 cmov instruction is decoded, in fact on the original P6 arch there is n't a major speed improvement by using cmov in fact cmov performance various considerably from processor to processor.
I'd wager that a large percentage of the 47% are businesses with a large number of seats and pretty much a standard application set, introducing a new application into these kind of environments are normally a big descision anyway with the likelyhood of a role out of new hardware/OS.
If the support contract for your software has come to an end and the supplier is no longer willing to support older software then you obviously have a business case for an upgrade. However as Microsoft will provide security updates for XP until 2016 why upgrade now?
If you are a company that has a working system that runs fine, why would you force an upgrade just because XP is n't used by consumers any more? Even if you put the economic costs at zero which it certainly is n't and the summary brushes aside way to casually; you always have a risk factor of unforseen issues getting passed testing.
No business should upgrade for the sake of technology fashion, weather it be OS or applications. Hell you see companies running custom DOS programs all the time.
in essence: the x86 instruction set is *extremely* efficiently memory-packed. it was designed when memory was at a premium. each new revision added extra "escape codes" which kept the compactness but increased the complexity. by contrast, RISC instructions consume quite a lot more memory as they waste quite a few bits. in some cases *double* the amount of memory is required to store the instructions for a given program [hence where the L1 and L2 cache problem starts to come into play, but leaving that aside for now...]
New x86 instructions did n't use escape codes, they used unused opcode space, the instruction format has n't changed much since the 386. In fact when going to 64-bits the default data size and some of the fields meanings where changed but other than that nothing radical.
so what that means is that *regardless* of the fact that CISC instructions are translated into RISC ones, the main part of the CPU has to run at a *much* faster clock rate than an equivalent RISC processor, just to keep up with decode rate. we've seen this clearly in an "empirical observable" way in the demo by ARM last year, of a 500mhz Dual-Core ARM Cortex A9 clearly keeping up with a 1.6ghz Intel Atom in side-by-side running of a web browser, which you can find on youtube.
This makes no sense, instructions on modern x86 processors are decoded and stored in the trace cache, in a loop the processor is executing pre-translated instructions. In fact on AMDs latest CPU architecture instructions cant be sent to the execution units fast enough.
intel know this, and AMD don't. it's why intel will sell their fab R&D plant when hell freezes over. AMD have a slight advantage in that they've added in parallel execution which *just* keeps them in the game i.e. their CPUs have always run at a clock rate that's *lower* than an intel CPU, forcing them to publish "equivalent clock rate" numbers in order to not appear to be behind intel. this trick - of doing more at a lower speed - will keep them in the game for a while.
AMD has n't done this for years, and when they did it was because their processors had higher a IPC count than Intels at the time so MHz was not a fair metric to compare the processors.
but, if intel and AMD don't come out with a RISC-based (or VILW or other parallel-instruction) processor soon, they'll pay the price. intel bought up that company that did the x86-to-DEC-Alpha JIT assembly translation stuff (back in the 1990s) so i know that they have the technology to keep things "x86-like".
Erm, Intel had VLIW, remember Itanium? Other than in highly parallel number crunching workloads it was being outperformed by Intels own x86s. For general computing VLIW sucks, program execution is just too dynamc.
Every modern CISC chip is basically a dynamic translator on top of a RISC core.
And that's the problem for power consumption. You can cut power to execution units that are not being used. You can't ever turn off the decoder ever (except in Xeons, where you do in loops, but you leave on the micro-op decoder, which uses as much power as an ARM decoder) because every instruction needs decoding.
If it was just the case of turning off execution units for a processor with a simpler decoder then the Cortex-A9 would n't have the need for the extra low-power fifth core.
Well there has never been a CISC-RISC instruction conversion from an Intel processor, AFAIK the AMD-K5 was the only processor to do so and the original Pentiums pretty much out performed them.
Out of order Intel processors since the Pentium Pro have converted instructios into very simple uOPs, in fact many RISC processors do the same thing.
Intel have always designed their processors for performance first where as with ARM it was for power consumption, hell only recently did ARM get a hardware integer divide instruction. x86 instruction decode is not so complicated that it requires four times the amount of power, if it did Intel would never be able to produce high performance chips.
The CISC/RISC debate is pretty much a red-herring but it keeps on coming up over and over again, because as you increase performance the instruction decode becomes a smaller part of the processor, this is why on the A9 you have a fifth extra core for stand-by which has been engineered for low power.
This definitely has something to do with Microsoft. Remember all those Netbooks running Linux? They would n't want that happening again, especially now that Microsoft want to be like Apple in the table space. Maybe the WinTel allience is n't dead afterall.
Accessing global memory on GPUs is extremely slow and there is a strict memory heirarchy that you have to adhere to in order to get any kind of performance.
It could be seen as being the same as the CPU, except will automatically cache it to fast memory for you.
Any problem where you need random access over a large amount of data is just not feasible on GPUs.
What makes you think it would be faster with the MIC?
Granted it is the hardware doing the work, but you have four threads per core on Knights Corner with a cacheline miss causing a context switch masking the latencies. You also do n't have the extra overhead of your code setting up the copies between global and shared memory (which is limited to 48K on CUDA) everytime you want to access a data structure. Obviously you have many more cores on a GPU but how much performance do you think you will get once you have to jump through all the hoops and basically implement your own caching mechanisms? Ultimately GPUs are limited to simple problems where your dataset can be broken into very small peices with very little logic and simple random memory access which is fine for big number crunching problems, with MIC you atleast will have more flexibility.
You will be parallelizing, and each thread will only ever be able to use max_mem/N for its own processing. When you parallelize, you avoid sharing memory between threads. Your data set is split over the threads and synchronization is minimized. In a SMP/NUMA model, this is done transparently by simply avoiding to access memory that other threads are working on. In other models, you have to explicitly send the chunk of memory that each thread will be working on (through DMA, the network, an in-memory FIFO or whatever), but it doesn't change anything from a conceptual point of view.
If your parallel decomposition is much more efficient if your data per thread is larger than 1GB, then you cannot possibly run 64 threads set up like this on the MIC platform. There is often a minimum size required for a parallel primitive to be efficient, and if that minimum size is greater than max_mem/N then you have a problem. This is the limiting factor I'm talking about.128 MB, however, is IMO quite large enough.
For algorithms where you have a basically regular streaming data then yes, your working data set will be mem/n but as I mentioned there are a number of problems where you have a large mainly static dataset such as raytracing or financial modeling. In these scenarios being able to access a large shared pool of memory has big advantages.
In fact this is a major advantage of MIC versus GPUs.
The advantage of MIC lies in ease of programming thanks to compatibility with existing tools and the more flexible programming model. Memory on GPUs is global as well, so I have no idea what you're talking about. There is also so-called "shared" memory (CUDA terminology, OpenCL is different) which is per block, but that's just some local scratch memory shared by a group of threads.
Accessing global memory on GPUs is extremely slow and there is a strict memory heirarchy that you have to adhere to in order to get any kind of performance. This heirarchy is what makes it a pain to program for and why you need special tools and kernels in the first place. Any problem where you need random access over a large amount of data is just not feasible on GPUs.
There is nothing nighmarish of the above
Please stop deforming what I'm saying. What is nightmarish is finding the optimal work distribution and scheduling of a heterogeneous or irregular system. Platforms like GPUs are only fit for regular problems. Most HPC applications written using OpenMP or MPI are regular as well. Whether the MIC will be able to enable good scalability of irregular problems remains to be seen, but the first applications will definitely be regular ones.
For those kinds of problems there is n't anything in the MIC that will set the world on fire other than the easier programming model as it basically comes down to bandwidth and FLOPS. However from what I have seen in terms of architecture there are a number of areas where it should perform nicely. FYI, if you havee n't already read it:
On a card with 8GB your effective memory accessible per core is 8GB, lots of problems have large data sets that can be shared over cores such as the example I gave. In fact this is a major advantage of MIC versus GPUs.
There is nothing nighmarish of the above, it would appear just a shared memory area to the process.
Slashdot Mirror
However unlikely it is that Oracle wins this, if this were to pass it would be the end of the software industry as we know it.
I really hope that somehow there is some kind of backlash against Oracle when this ends. Well I can dream at least.
Because it certainly does n't sound like it is in object orientated program design. Being able to code is just one part of being a skilled programer, being a "rockstar" style coder may seem impressive but banging out pages of code at a time is never a good sign and I say this as someone who spent a good five years working this way.
It is only when you have to maintain your own code for years that you start to step back and think more because at the end of the day you can not code your way out of trouble, well you can but the result is never pretty or maintainable.
Personally I find that I spend around 25% thinking, 25% coding, 25% testing and 25% documenting any one problem. The 50% spent testing and documenting is n't fun by anymeans but it's a necessary discipline. It's all about taming your inner coder and I think this is what the majority of these frameworks do indirectly by creating road blocks so that you have to hit the breaks every so often.
Netscape navigator introduced the notorious BLINK tag and things like frames, back in the early days it pretty much was a free for all.
http://en.wikipedia.org/wiki/Neandertal
I get that my point is, I'm aware of flash, dreamweaver, etc even though I don't use them yet I've never heard of this product.
I use Visual Studio and never heard of it before today yet apparently I should have because it is now being integrated in to a product that I use on a daily basis.
that Microsoft even had a design suite. I guess that shows how successful it was.
Just saying that going with Android makes Nokia another "me too" company totally discounts that Noka phones are always beautifully designed and very robust.
The last two nokia phones I've had have terrible software problems but I could not fault the hardware. Where as my experience with HTC phones one had a joystick that broke and my current HD2 has had the USB power connector fail on me.
If they had gone with Android they could have easily competed with Samsung and had a good percentage of the Android smartphone market. The problem is Elop somehow managed to convince people that with Windows Mobile he could restore past glory and be like Apple. Sure they now have nearly have 100% of the Windows Mobile market, but whats that at the moment? 1% of smartphones?
The thing is Elop does n't understand the industry, he came from Microsoft. He's a Microsoft man, the question at the time should have been something like this "We have two available OS options, one has a proven record of being something customers want and the other has failed pretty badly up to now." . Which one would you go with? Sure you will have to compete with Samsung with the same OS, but they're now competing with Apple, Samsung and everyone else with a different OS and failing badly.
Regardless, it's a moot point now but I don't recall anyone at the time saying this was going to end well for Nokia.
Your blender only goes up to 9? Mines goes to 11.
I was under the impression that Itanium was all but dead. I'm guessing Intel must be contract bound to bring out new versions.
There is no way the goverrnment could enforce that kind of behaviour, if they could they would have used that ability to collect the correct amount of corporation tax in the first place.
The problem is VAT is n't a tax on companies, it is a tax on consumers with the companies being able to claim back their VAT expenses due to them acting as tax collectors for the government. An increase in VAT would immediately be passed on to the consumer.
> In the end, the few uses of conditional execution
That why x86 introduced cmov for doing conditional mov ?
I'd wager that there is n't a conditional move uOP when the x86 cmov instruction is decoded, in fact on the original P6 arch there is n't a major speed improvement by using cmov in fact cmov performance various considerably from processor to processor.
I meant 43% not 47%.
I'd wager that a large percentage of the 47% are businesses with a large number of seats and pretty much a standard application set, introducing a new application into these kind of environments are normally a big descision anyway with the likelyhood of a role out of new hardware/OS.
If the support contract for your software has come to an end and the supplier is no longer willing to support older software then you obviously have a business case for an upgrade. However as Microsoft will provide security updates for XP until 2016 why upgrade now?
If you are a company that has a working system that runs fine, why would you force an upgrade just because XP is n't used by consumers any more? Even if you put the economic costs at zero which it certainly is n't and the summary brushes aside way to casually; you always have a risk factor of unforseen issues getting passed testing.
No business should upgrade for the sake of technology fashion, weather it be OS or applications. Hell you see companies running custom DOS programs all the time.
This is why modern x86 processors have a trace-cache for decoded instructions.
in essence: the x86 instruction set is *extremely* efficiently memory-packed. it was designed when memory was at a premium. each new revision added extra "escape codes" which kept the compactness but increased the complexity. by contrast, RISC instructions consume quite a lot more memory as they waste quite a few bits. in some cases *double* the amount of memory is required to store the instructions for a given program [hence where the L1 and L2 cache problem starts to come into play, but leaving that aside for now...]
New x86 instructions did n't use escape codes, they used unused opcode space, the instruction format has n't changed much since the 386. In fact when going to 64-bits the default data size and some of the fields meanings where changed but other than that nothing radical.
so what that means is that *regardless* of the fact that CISC instructions are translated into RISC ones, the main part of the CPU has to run at a *much* faster clock rate than an equivalent RISC processor, just to keep up with decode rate. we've seen this clearly in an "empirical observable" way in the demo by ARM last year, of a 500mhz Dual-Core ARM Cortex A9 clearly keeping up with a 1.6ghz Intel Atom in side-by-side running of a web browser, which you can find on youtube.
This makes no sense, instructions on modern x86 processors are decoded and stored in the trace cache, in a loop the processor is executing pre-translated instructions. In fact on AMDs latest CPU architecture instructions cant be sent to the execution units fast enough.
intel know this, and AMD don't. it's why intel will sell their fab R&D plant when hell freezes over. AMD have a slight advantage in that they've added in parallel execution which *just* keeps them in the game i.e. their CPUs have always run at a clock rate that's *lower* than an intel CPU, forcing them to publish "equivalent clock rate" numbers in order to not appear to be behind intel. this trick - of doing more at a lower speed - will keep them in the game for a while.
AMD has n't done this for years, and when they did it was because their processors had higher a IPC count than Intels at the time so MHz was not a fair metric to compare the processors.
but, if intel and AMD don't come out with a RISC-based (or VILW or other parallel-instruction) processor soon, they'll pay the price. intel bought up that company that did the x86-to-DEC-Alpha JIT assembly translation stuff (back in the 1990s) so i know that they have the technology to keep things "x86-like".
Erm, Intel had VLIW, remember Itanium? Other than in highly parallel number crunching workloads it was being outperformed by Intels own x86s. For general computing VLIW sucks, program execution is just too dynamc.
Every modern CISC chip is basically a dynamic translator on top of a RISC core.
And that's the problem for power consumption. You can cut power to execution units that are not being used. You can't ever turn off the decoder ever (except in Xeons, where you do in loops, but you leave on the micro-op decoder, which uses as much power as an ARM decoder) because every instruction needs decoding.
If it was just the case of turning off execution units for a processor with a simpler decoder then the Cortex-A9 would n't have the need for the extra low-power fifth core.
Well there has never been a CISC-RISC instruction conversion from an Intel processor, AFAIK the AMD-K5 was the only processor to do so and the original Pentiums pretty much out performed them.
Out of order Intel processors since the Pentium Pro have converted instructios into very simple uOPs, in fact many RISC processors do the same thing.
Intel have always designed their processors for performance first where as with ARM it was for power consumption, hell only recently did ARM get a hardware integer divide instruction. x86 instruction decode is not so complicated that it requires four times the amount of power, if it did Intel would never be able to produce high performance chips.
The CISC/RISC debate is pretty much a red-herring but it keeps on coming up over and over again, because as you increase performance the instruction decode becomes a smaller part of the processor, this is why on the A9 you have a fifth extra core for stand-by which has been engineered for low power.
It is n't the 80s and 90s any more.
This definitely has something to do with Microsoft. Remember all those Netbooks running Linux? They would n't want that happening again, especially now that Microsoft want to be like Apple in the table space. Maybe the WinTel allience is n't dead afterall.
It could be seen as being the same as the CPU, except will automatically cache it to fast memory for you.
What makes you think it would be faster with the MIC?
Granted it is the hardware doing the work, but you have four threads per core on Knights Corner with a cacheline miss causing a context switch masking the latencies. You also do n't have the extra overhead of your code setting up the copies between global and shared memory (which is limited to 48K on CUDA) everytime you want to access a data structure. Obviously you have many more cores on a GPU but how much performance do you think you will get once you have to jump through all the hoops and basically implement your own caching mechanisms? Ultimately GPUs are limited to simple problems where your dataset can be broken into very small peices with very little logic and simple random memory access which is fine for big number crunching problems, with MIC you atleast will have more flexibility.
You will be parallelizing, and each thread will only ever be able to use max_mem/N for its own processing.
When you parallelize, you avoid sharing memory between threads. Your data set is split over the threads and synchronization is minimized. In a SMP/NUMA model, this is done transparently by simply avoiding to access memory that other threads are working on. In other models, you have to explicitly send the chunk of memory that each thread will be working on (through DMA, the network, an in-memory FIFO or whatever), but it doesn't change anything from a conceptual point of view.
If your parallel decomposition is much more efficient if your data per thread is larger than 1GB, then you cannot possibly run 64 threads set up like this on the MIC platform. There is often a minimum size required for a parallel primitive to be efficient, and if that minimum size is greater than max_mem/N then you have a problem. This is the limiting factor I'm talking about.128 MB, however, is IMO quite large enough.
For algorithms where you have a basically regular streaming data then yes, your working data set will be mem/n but as I mentioned there are a number of problems where you have a large mainly static dataset such as raytracing or financial modeling. In these scenarios being able to access a large shared pool of memory has big advantages.
The advantage of MIC lies in ease of programming thanks to compatibility with existing tools and the more flexible programming model.
Memory on GPUs is global as well, so I have no idea what you're talking about. There is also so-called "shared" memory (CUDA terminology, OpenCL is different) which is per block, but that's just some local scratch memory shared by a group of threads.
Accessing global memory on GPUs is extremely slow and there is a strict memory heirarchy that you have to adhere to in order to get any kind of performance. This heirarchy is what makes it a pain to program for and why you need special tools and kernels in the first place. Any problem where you need random access over a large amount of data is just not feasible on GPUs.
There is nothing nighmarish of the above
Please stop deforming what I'm saying. What is nightmarish is finding the optimal work distribution and scheduling of a heterogeneous or irregular system.
Platforms like GPUs are only fit for regular problems. Most HPC applications written using OpenMP or MPI are regular as well. Whether the MIC will be able to enable good scalability of irregular problems remains to be seen, but the first applications will definitely be regular ones.
For those kinds of problems there is n't anything in the MIC that will set the world on fire other than the easier programming model as it basically comes down to bandwidth and FLOPS. However from what I have seen in terms of architecture there are a number of areas where it should perform nicely. FYI, if you havee n't already read it:
http://newsroom.intel.com/servlet/JiveServlet/download/38-11511/Intel_Xeon_Phi_Hotchips_architecture_presentation.pdf
On a card with 8GB your effective memory accessible per core is 8GB, lots of problems have large data sets that can be shared over cores such as the example I gave. In fact this is a major advantage of MIC versus GPUs.
There is nothing nighmarish of the above, it would appear just a shared memory area to the process.