The STEM industry is bending over backwards to get them into the business, organizations in college and professional organizations and they aren't biting.
Mostly because we're doing it too late. There was a study a few years ago that showed that one of the big reasons women get put off mathematics is that they have primary school teachers who are female and don't really understand the subject. They pick up on the teachers' fear of the material, but the boys (who don't tend to develop that level of empathy until later) don't. Children taught by male maths teachers from about ages 5-11 show a fairly gender-neutral distribution in their teenage years. By the time the 'hey girls, STEM is great!' marketing gets going around age 14, the rest have already been put off.
Sure. But only after they've spent the first 18 years of their lives without a combination of obvious and subtle social pressures telling them what they should like...
The politics of projects like the kernel keep the insecure out.
The politics of the Linux kernel panders to the insecure, but only a select few. Those on the inside belittle people making valuable contributions and massage their egos.
Don't get me wrong, I'm totally in favour of Linux doing this this: the FreeBSD project has picked up some very competent developers over the years because they get past the age of about 30 and realise that they're competent professionals and don't have to put up with that shit.
It's more of an issue of constraints. Back then, there was tight, efficient code, and there was code that didn't work at all - no middle ground. Now, there's tight, efficient code, and there's code that's finished in time for the deadline. Guess which one is preferred? More importantly, there's often a choice between efficiency and maintainability. Maintainable code has abstractions built in the right places to allow parts of it to be replaced, but this hurts efficiency. Code from the '50s and '60s was maintained by throwing it away and rewriting it. When 30K of memory filled a room, software had to do exactly what was needed and no more, no less. It was unusual for a program to be more than a few days worth of work, so rewriting it (rather than refactoring it) was not a problem. The IBM System/360 machines were the first to encourage the idea that you would run programs that were written for one computer on another. Before then, rewriting all of your software was just something you did when you bought a new computer, and compared to the cost of the computer it was very cheap.
A lot of modules are using things like FastCGI so that they have process isolation between them and the web server (for both security and stability). The main advantage of Nginx isn't the speed, it's that it's easier to configure than Apache, and that's a fairly compelling advantage for people who don't need all of the features of Apache.
you most likely are going to be using Apache/Nginx.
IIS market share dipped a bit after 2008 and is now back to about where it was. Apache jumped a lot since 2008 and is now back a bit below where it was. Nginx has gone from 1% to 14% in the same time. IIS has hovered between 20-30% for a while. It's now closer to 30%. Apache has been in the 50-70% range for a long time, but is now dipping a lot. The only reason we're using Apache is that Nginx doesn't work as a reverse SSL proxy in front of Jenkins (apparently it can, with some magic incantations, but they didn't work for us). For everything else, Nginx is an obvious choice. It's somewhat sad to see that Nginx has completely displaced Lighttpd, as it would have been nice to have some more active competition.
You can still avoid US taxes by moving to another country, renouncing your US citizenship, and not returning to the USA (border controls are even more annoying for former US citizens than for those of us who have never been US citizens, and that's saying something).
You know, having a few more managers with a solid background in science is probably not that bad a problem to suffer from. If you could also have a side effect of getting more people with science degrees into politics, then that would be even better...
It's a problem in the UK, that anyone competent in any computing or mathematical subject can earn at least double, sometimes as much as ten times as much working for a bank playing a huge zero-sum game as they can contributing to the economy. We used to have a brain drain to the US, now we have one to the City of London.
Absolutely not. Scholarships pay schools, not students
That's not true. Scholarships (in the UK, at least) usually come with a maintenance grant and so, as well as covering the cost of tuition, they will provide the student with money to cover their cost of living.
Individual researchers are less likely to make significant contributions, but small teams still do. Individuals have ideas. Small teams produce proof-of-concept implementations. Larger teams produce working prototypes. Big teams produce finished products. It's hard to compete with a large company when it comes to bringing products to market, but it's quite easy for university research labs to get things to the proof-of-concept stage. They then have the choice of spinning out a company to try to commercialise it or licensing their work to a bigger company who will do the prototype to product bit.
That's an idea that predates MIPS. You'd do better if you claimed MIPS heritage because AArch64 removes the PC as a GPR, but (unlike MIPS) it does provide PC-relative addressing (MIPS does PC-relative memory accesses by forcing the calling convention to make every function call in position-independent code a JALR $25, so that $25 is guaranteed to contain the PC on function entry). MIPS also lacks the complex addressing modes of AArch64 (and AArch32). Unlike AArch64, it has branch delay slots, doesn't have the store/load pair instructions, condition code registers (all conditions in MIPS are stored in GPRs), bitfield manipulation instructions, and so on. ARM and MIPS are both derivatives of Berkeley RISC, but they have diverged a lot from that common inspiration.
Great for assembly programmers, not so great for pipeline designers. One of the weaknesses of the ARM design is that making the PC a general-purpose register meant that every instruction needs a little bit of extra logic in the decoder to tell you whether it's a branch, which then complicates the branch predictor. It's fun being able to do a ldr with the pc as the destination register, right up until you have to implement a long pipeline with that instruction. This is why ARMv8 makes the pc a special register (but still provides pc-relative loads and stores).
By having many different manufacturers there is no worry about ARM playing some games like cutting you off, or strongarming you into some new marketing ploy. If one manufacturer tries to screw you there are many others happy to do business.
This is part of ARM's strategy with ARMv8. They intentionally delayed their own designs so that they wouldn't compete with their partners. Now, if you want to license a 64-bit core from ARM, they have a low-power in-order design and a better-performing out-of-order superscalar design, but several of their partners also have their own ARMv8 implementations that were built with advice from ARM engineers but are independent implementations. They will each have different power/price/performance trades, helping to diversify the ARM ecosystem. Between multiple independent implementations of the core designs, and multiple potential companies to fab them, the ARM ecosystem is in quite a strong position.
The nVidia drivers on FreeBSD are pretty solid, but they got a poor reputation for their open source drivers in the early releases. I was running a room full of Linux boxes about 10 years ago, and they'd all kernel panic about once a day, typically while running nothing more strenuous graphically than the log-in screen, and always with a backtrace in the nVidia drivers. The open source ATi drivers of the same era (R200) were a lot slower, but were very stable.
nVidia also had that embarrassing incident where a crafted image could cause arbitrary code execution in the kernel, which turned out to be exploitable by just putting a picture on a web page, and didn't fix it until about two years after they were first notified of it. For the last 4-5 years, their proprietary drivers have been pretty reasonable though.
Is Amazon shipping more expensive in the US? I can't remember the last time I bought anything from Amazon that didn't come with free shipping. The only difference is that Prime gives you next day, whereas their super-saver free delivery gives you 3-5 days (typically closer to 3). I've found that if I need something very urgently then I will go into town and buy it - there are few situations where tomorrow is soon enough, but in a few days time is not.
There are two things wrong with your post. The first is that the electricity cost just from the CPU is significantly higher than the value of the BitCoins created. The second is the assumption that there are a lot of spare cycles on EC2. The entire design of datacentres like this is to ensure that the computers are used efficiently by ensuring that there is always some job ready to run.
The point of the broken window fallacy is that it assumes that causing work to be done will not cause other work to go undone and it therefore ignores opportunity cost. The glass maker in the story will be employed making the glass to replace the window, which increases economic activity on the assumption that the glass blower would otherwise have had no work to do. The point of the story is to highlight the fact that this assumption is usually untrue. It is very often misused, however.
In particular, it does not apply when you're talking about subsidies / investment that is required to produce a demand that will cause economies of scale to lower prices to the degree that would increase real demand. If, rather than one window being broken, a few thousand were, then that might cause the glazier in the story to invest in machinery to produce glass in high volumes. Once all of the windows have been replaced, the glazier is still able to produce glass at significant volumes and lower costs, and so reduces his prices to stimulate demand. This then triggers the development of industries that depend on the cheap and ready availability of glass.
That's stretching the story a little bit, because the production of glass is very well understood and there are few changes in the process that are more than small incremental improvements. It is very different in a comparatively new field, for example the production of solar cells, where new processes regularly produce 50% better (more efficient, cheaper, etc.) technology. It would be true of microprocessors, if not for the fact that this market has already moved on to the stage where there is sufficient demand to drive investment without needing external priming.
The motivation is largely irrelevant. The broken window fallacy would apply to the TSA if the TSA is hiring people who would otherwise be employed doing something productive. It is, of course, not the only way in which the TSA costs the economy. On my last trip to the US, I spent a total of around two hours in queues for security theatre, which could have been time spent in the airport lounge working. The same is true of most business travellers.
And this post highlights exactly why: when a trend that's been going on for decades across administrations from both major parties continues (or, worse, accelerates slightly), what happens? Half of Americans loudly blame the current incumbent, causing the other half to reflexively defend whatever this trend is.
Hint: Government is not like sports. Don't mindlessly support the Red Team or the Blue Team, they're supposed to stand for something.
Small business users probably have it hardest. But the UK government is spending £200m/year on MS Office. Cut that in half, and now you have a budget of £100m/year to improve LibreOffice. There are a load of small UK companies that would love to take that money. The average salary for a software developer in the UK is £40K/year (less in places where the cost of living is low). Throw in overhead of 100% and that means that it will cost around £80K/year to employ one to work full time on LibreOffice. The UK government could pay companies to employ 125 software developers to add the features they need and fix the bugs that they hit. If they did this, then:
They would be spending £100m less of taxpayers' money each year.
The money that they spent would be going to people working in the UK and circulating in the local economy, not being sent directly to the USA.
There result of the £100m/year spending would be available for public use, making it LibreOffice a more viable alternative for businesses every year.
It seems like an obvious choice to me. The pragmatic business choice isn't 'do we pay Microsoft or try to use a free alternative', it's 'do we get better value for money by paying Microsoft to provide whatever they decide to provide and hoping that it's what we need, or by taking an off-the-shelf open source product and paying for the customisations that we want?'
AArch64 doesn't yet have a Thumb mode. Thumb and Thumb-2 were created by examining large numbers of binaries, determining the instructions that compilers most frequently used, and then generating an instruction encoding that makes the most common instructions 16 bytes long. This is not possible with AArch64 until there is a large corpus of code to analyse and there are relatively mature compilers. In contrast, a lot of the shorter x86 instructions were ones that were used on the original 8086 / 8088, and are no longer regularly emitted by compilers. The AArch64 instruction set, however, was designed as a compiler target and so does produce quite dense code without the compression scheme. For example, it has a single instruction that allow spilling a pair of registers to the stack, which compresses function prologs and epilogs quite considerably (not compared to the ARM store-multiple and load-multiple instructions, but these add a lot of microarchitectural complication to the pipeline, whereas the store-pair and load-pair instructions are trivial to implement).
Yes, it is a slight problem with ARM. It's also a big problem on x86 - there are a large number of ways of interpreting a two-instruction sequence depending on where you start within the first instruction. ROP (and BOP) benefit a lot from this, unfortunately. There isn't really a good solution.
The Pentium M is a good example of how Intel remains dominant. It takes about 5 years to bring a CPU to market, for any vendor. You start with an approximate transistor and power budget and an estimate of what the market will want in 5-7 years. You then start work. Hopefully, the process technology gets where you need it to be and the market does what you expect. With the Pentium 4, neither happened: they were expecting to get to 10GHz with a thermal envelope of around 60W and didn't, and the market started caring about power as laptops and dense servers became big markets. If AMD had made this mistake, it would have cost the company a huge amount. Intel's size means that they don't start just one processor design, they start ten, and gradually cull them as either it becomes clear that the market isn't doing what they expected or that their designs aren't working out. They typically have 2-3 that can be ready to go in under a year, which is how they were able to pull the Pentium-M out of a hat.
This is also why ARM's strategy has changed with ARMv8 (and, to a lesser extent, with the later ARMv7 designs). Previously, most ARM customers build chips that were an ARM design plus some customisation. This was fine for ARM's traditional markets, because they were predictable and ARM could happily succeed with a small set of designs that covered this space. With ARMv8, they intentionally delayed the launch of their own designs and worked with other manufacturers (nVidia, AMD, and so on) to produce completely in-house implementations. This makes the ARM ecosystem a lot more resilient, because individual manufacturers can aim for different niches and they can bring them all to market. And, because many of these companies make money from producing SoCs, if they don't have a CPU core that makes sense for the current market, they can license one from one of the other manufacturers and add their own things on the side.
Actually x86 IS efficient for for something completely different. The architecture itself is totally unimportant as deep inside it is yet another micro code translator and doesn't differ significantly from PPC or Sparc nowadays.
This is true, unless you care about power. The decoder in an x86 pipeline is more accurately termed a parser. The complexity of the x86 instruction set adds 1-3 pipeline stages relative to a simpler encoding. This is logic that has to be powered all of the time (except in Xeons, where they cache decoded micro-ops for tight loops and can power gate the decoder, reducing their pipeline to something more like a RISC processor, but only when running very small loops).
x86 short instructions allow for highly efficient memory usage and for a much, much, much higher Ops per Cycle.
It is more efficient than ARM. My tests with Thumb-2 found that IA32 and Thumb-2 code were about the same density, plus or minus 10%, with neither a clear winner. However, the Thumb-2 decoder is really trivial, whereas the IA32 decoder is horribly complex.
This is just that big of a deal that ARM has created a short command version of ARM opcodes just to close in. But then this instruction set is totally incompatible and also totally ignored.
Thumb-2 is now the default for any ARMv7 (Cortex-A8 and newer) compiler, because it always generates denser code than ARM mode and has no disadvantages. Everything else in your post is also wrong, but others have already added corrections to you there.
That depends on how you're measuring success. If it's by fastest available CPU, by most sales, or by highest profits, then neither AMD nor Intel has been dominant since the '80s.
Slashdot Mirror
The STEM industry is bending over backwards to get them into the business, organizations in college and professional organizations and they aren't biting.
Mostly because we're doing it too late. There was a study a few years ago that showed that one of the big reasons women get put off mathematics is that they have primary school teachers who are female and don't really understand the subject. They pick up on the teachers' fear of the material, but the boys (who don't tend to develop that level of empathy until later) don't. Children taught by male maths teachers from about ages 5-11 show a fairly gender-neutral distribution in their teenage years. By the time the 'hey girls, STEM is great!' marketing gets going around age 14, the rest have already been put off.
Sure. But only after they've spent the first 18 years of their lives without a combination of obvious and subtle social pressures telling them what they should like...
The politics of projects like the kernel keep the insecure out.
The politics of the Linux kernel panders to the insecure, but only a select few. Those on the inside belittle people making valuable contributions and massage their egos.
Don't get me wrong, I'm totally in favour of Linux doing this this: the FreeBSD project has picked up some very competent developers over the years because they get past the age of about 30 and realise that they're competent professionals and don't have to put up with that shit.
It's more of an issue of constraints. Back then, there was tight, efficient code, and there was code that didn't work at all - no middle ground. Now, there's tight, efficient code, and there's code that's finished in time for the deadline. Guess which one is preferred? More importantly, there's often a choice between efficiency and maintainability. Maintainable code has abstractions built in the right places to allow parts of it to be replaced, but this hurts efficiency. Code from the '50s and '60s was maintained by throwing it away and rewriting it. When 30K of memory filled a room, software had to do exactly what was needed and no more, no less. It was unusual for a program to be more than a few days worth of work, so rewriting it (rather than refactoring it) was not a problem. The IBM System/360 machines were the first to encourage the idea that you would run programs that were written for one computer on another. Before then, rewriting all of your software was just something you did when you bought a new computer, and compared to the cost of the computer it was very cheap.
A lot of modules are using things like FastCGI so that they have process isolation between them and the web server (for both security and stability). The main advantage of Nginx isn't the speed, it's that it's easier to configure than Apache, and that's a fairly compelling advantage for people who don't need all of the features of Apache.
you most likely are going to be using Apache/Nginx.
IIS market share dipped a bit after 2008 and is now back to about where it was. Apache jumped a lot since 2008 and is now back a bit below where it was. Nginx has gone from 1% to 14% in the same time. IIS has hovered between 20-30% for a while. It's now closer to 30%. Apache has been in the 50-70% range for a long time, but is now dipping a lot. The only reason we're using Apache is that Nginx doesn't work as a reverse SSL proxy in front of Jenkins (apparently it can, with some magic incantations, but they didn't work for us). For everything else, Nginx is an obvious choice. It's somewhat sad to see that Nginx has completely displaced Lighttpd, as it would have been nice to have some more active competition.
You can still avoid US taxes by moving to another country, renouncing your US citizenship, and not returning to the USA (border controls are even more annoying for former US citizens than for those of us who have never been US citizens, and that's saying something).
You know, having a few more managers with a solid background in science is probably not that bad a problem to suffer from. If you could also have a side effect of getting more people with science degrees into politics, then that would be even better...
It's a problem in the UK, that anyone competent in any computing or mathematical subject can earn at least double, sometimes as much as ten times as much working for a bank playing a huge zero-sum game as they can contributing to the economy. We used to have a brain drain to the US, now we have one to the City of London.
Absolutely not. Scholarships pay schools, not students
That's not true. Scholarships (in the UK, at least) usually come with a maintenance grant and so, as well as covering the cost of tuition, they will provide the student with money to cover their cost of living.
Individual researchers are less likely to make significant contributions, but small teams still do. Individuals have ideas. Small teams produce proof-of-concept implementations. Larger teams produce working prototypes. Big teams produce finished products. It's hard to compete with a large company when it comes to bringing products to market, but it's quite easy for university research labs to get things to the proof-of-concept stage. They then have the choice of spinning out a company to try to commercialise it or licensing their work to a bigger company who will do the prototype to product bit.
That's an idea that predates MIPS. You'd do better if you claimed MIPS heritage because AArch64 removes the PC as a GPR, but (unlike MIPS) it does provide PC-relative addressing (MIPS does PC-relative memory accesses by forcing the calling convention to make every function call in position-independent code a JALR $25, so that $25 is guaranteed to contain the PC on function entry). MIPS also lacks the complex addressing modes of AArch64 (and AArch32). Unlike AArch64, it has branch delay slots, doesn't have the store/load pair instructions, condition code registers (all conditions in MIPS are stored in GPRs), bitfield manipulation instructions, and so on. ARM and MIPS are both derivatives of Berkeley RISC, but they have diverged a lot from that common inspiration.
Great for assembly programmers, not so great for pipeline designers. One of the weaknesses of the ARM design is that making the PC a general-purpose register meant that every instruction needs a little bit of extra logic in the decoder to tell you whether it's a branch, which then complicates the branch predictor. It's fun being able to do a ldr with the pc as the destination register, right up until you have to implement a long pipeline with that instruction. This is why ARMv8 makes the pc a special register (but still provides pc-relative loads and stores).
By having many different manufacturers there is no worry about ARM playing some games like cutting you off, or strongarming you into some new marketing ploy. If one manufacturer tries to screw you there are many others happy to do business.
This is part of ARM's strategy with ARMv8. They intentionally delayed their own designs so that they wouldn't compete with their partners. Now, if you want to license a 64-bit core from ARM, they have a low-power in-order design and a better-performing out-of-order superscalar design, but several of their partners also have their own ARMv8 implementations that were built with advice from ARM engineers but are independent implementations. They will each have different power/price/performance trades, helping to diversify the ARM ecosystem. Between multiple independent implementations of the core designs, and multiple potential companies to fab them, the ARM ecosystem is in quite a strong position.
The nVidia drivers on FreeBSD are pretty solid, but they got a poor reputation for their open source drivers in the early releases. I was running a room full of Linux boxes about 10 years ago, and they'd all kernel panic about once a day, typically while running nothing more strenuous graphically than the log-in screen, and always with a backtrace in the nVidia drivers. The open source ATi drivers of the same era (R200) were a lot slower, but were very stable.
nVidia also had that embarrassing incident where a crafted image could cause arbitrary code execution in the kernel, which turned out to be exploitable by just putting a picture on a web page, and didn't fix it until about two years after they were first notified of it. For the last 4-5 years, their proprietary drivers have been pretty reasonable though.
Is Amazon shipping more expensive in the US? I can't remember the last time I bought anything from Amazon that didn't come with free shipping. The only difference is that Prime gives you next day, whereas their super-saver free delivery gives you 3-5 days (typically closer to 3). I've found that if I need something very urgently then I will go into town and buy it - there are few situations where tomorrow is soon enough, but in a few days time is not.
There are two things wrong with your post. The first is that the electricity cost just from the CPU is significantly higher than the value of the BitCoins created. The second is the assumption that there are a lot of spare cycles on EC2. The entire design of datacentres like this is to ensure that the computers are used efficiently by ensuring that there is always some job ready to run.
In particular, it does not apply when you're talking about subsidies / investment that is required to produce a demand that will cause economies of scale to lower prices to the degree that would increase real demand. If, rather than one window being broken, a few thousand were, then that might cause the glazier in the story to invest in machinery to produce glass in high volumes. Once all of the windows have been replaced, the glazier is still able to produce glass at significant volumes and lower costs, and so reduces his prices to stimulate demand. This then triggers the development of industries that depend on the cheap and ready availability of glass.
That's stretching the story a little bit, because the production of glass is very well understood and there are few changes in the process that are more than small incremental improvements. It is very different in a comparatively new field, for example the production of solar cells, where new processes regularly produce 50% better (more efficient, cheaper, etc.) technology. It would be true of microprocessors, if not for the fact that this market has already moved on to the stage where there is sufficient demand to drive investment without needing external priming.
The motivation is largely irrelevant. The broken window fallacy would apply to the TSA if the TSA is hiring people who would otherwise be employed doing something productive. It is, of course, not the only way in which the TSA costs the economy. On my last trip to the US, I spent a total of around two hours in queues for security theatre, which could have been time spent in the airport lounge working. The same is true of most business travellers.
And this post highlights exactly why: when a trend that's been going on for decades across administrations from both major parties continues (or, worse, accelerates slightly), what happens? Half of Americans loudly blame the current incumbent, causing the other half to reflexively defend whatever this trend is.
Hint: Government is not like sports. Don't mindlessly support the Red Team or the Blue Team, they're supposed to stand for something.
It seems like an obvious choice to me. The pragmatic business choice isn't 'do we pay Microsoft or try to use a free alternative', it's 'do we get better value for money by paying Microsoft to provide whatever they decide to provide and hoping that it's what we need, or by taking an off-the-shelf open source product and paying for the customisations that we want?'
AArch64 doesn't yet have a Thumb mode. Thumb and Thumb-2 were created by examining large numbers of binaries, determining the instructions that compilers most frequently used, and then generating an instruction encoding that makes the most common instructions 16 bytes long. This is not possible with AArch64 until there is a large corpus of code to analyse and there are relatively mature compilers. In contrast, a lot of the shorter x86 instructions were ones that were used on the original 8086 / 8088, and are no longer regularly emitted by compilers. The AArch64 instruction set, however, was designed as a compiler target and so does produce quite dense code without the compression scheme. For example, it has a single instruction that allow spilling a pair of registers to the stack, which compresses function prologs and epilogs quite considerably (not compared to the ARM store-multiple and load-multiple instructions, but these add a lot of microarchitectural complication to the pipeline, whereas the store-pair and load-pair instructions are trivial to implement).
Yes, it is a slight problem with ARM. It's also a big problem on x86 - there are a large number of ways of interpreting a two-instruction sequence depending on where you start within the first instruction. ROP (and BOP) benefit a lot from this, unfortunately. There isn't really a good solution.
The Pentium M is a good example of how Intel remains dominant. It takes about 5 years to bring a CPU to market, for any vendor. You start with an approximate transistor and power budget and an estimate of what the market will want in 5-7 years. You then start work. Hopefully, the process technology gets where you need it to be and the market does what you expect. With the Pentium 4, neither happened: they were expecting to get to 10GHz with a thermal envelope of around 60W and didn't, and the market started caring about power as laptops and dense servers became big markets. If AMD had made this mistake, it would have cost the company a huge amount. Intel's size means that they don't start just one processor design, they start ten, and gradually cull them as either it becomes clear that the market isn't doing what they expected or that their designs aren't working out. They typically have 2-3 that can be ready to go in under a year, which is how they were able to pull the Pentium-M out of a hat.
This is also why ARM's strategy has changed with ARMv8 (and, to a lesser extent, with the later ARMv7 designs). Previously, most ARM customers build chips that were an ARM design plus some customisation. This was fine for ARM's traditional markets, because they were predictable and ARM could happily succeed with a small set of designs that covered this space. With ARMv8, they intentionally delayed the launch of their own designs and worked with other manufacturers (nVidia, AMD, and so on) to produce completely in-house implementations. This makes the ARM ecosystem a lot more resilient, because individual manufacturers can aim for different niches and they can bring them all to market. And, because many of these companies make money from producing SoCs, if they don't have a CPU core that makes sense for the current market, they can license one from one of the other manufacturers and add their own things on the side.
Actually x86 IS efficient for for something completely different. The architecture itself is totally unimportant as deep inside it is yet another micro code translator and doesn't differ significantly from PPC or Sparc nowadays.
This is true, unless you care about power. The decoder in an x86 pipeline is more accurately termed a parser. The complexity of the x86 instruction set adds 1-3 pipeline stages relative to a simpler encoding. This is logic that has to be powered all of the time (except in Xeons, where they cache decoded micro-ops for tight loops and can power gate the decoder, reducing their pipeline to something more like a RISC processor, but only when running very small loops).
x86 short instructions allow for highly efficient memory usage and for a much, much, much higher Ops per Cycle.
It is more efficient than ARM. My tests with Thumb-2 found that IA32 and Thumb-2 code were about the same density, plus or minus 10%, with neither a clear winner. However, the Thumb-2 decoder is really trivial, whereas the IA32 decoder is horribly complex.
This is just that big of a deal that ARM has created a short command version of ARM opcodes just to close in. But then this instruction set is totally incompatible and also totally ignored.
Thumb-2 is now the default for any ARMv7 (Cortex-A8 and newer) compiler, because it always generates denser code than ARM mode and has no disadvantages. Everything else in your post is also wrong, but others have already added corrections to you there.
That depends on how you're measuring success. If it's by fastest available CPU, by most sales, or by highest profits, then neither AMD nor Intel has been dominant since the '80s.