ICache flushes are going to do nothing for a JIT anyway (most of the time), so they are little overhead too. So we've eliminated system calls and ICache invalidates as valid points for your argument. You're down to claiming that a single DCache partial store at the right point is going to be more expensive than the ridiculously complex and poor auto-flushing that x86 does. Good luck with that.
I looked up the ARM code for Linux 2.6.31 and it doesn't generally work the way you think it does.
The whole instruction cache gets invalidated.
Ouch. Even the Pentium-4 wasn't that awful.
(hint: not flush, get your vocabulary right.
Normally they go together. ARM Linux has exactly one system call for this, and the name is "cacheflush".
Properly flushing a cache line is trivial; there aren't any aliasing issues.
Maybe you should tell the ARM Linux developers how to do this if you really think it is so easy.
Properly flushing a cache line is all but impossible on x86, since it only got a cache line flush instruction with the introduction of SSE2.
Well, if you want to be explicit. Normally it comes free.
x86 depends solely on guesswork by the CPU, and guesswork is by definition going to be worse than the programmer flushing what's needed ONLY when it's needed.
You ignored my example showing that this is not the case. The delayed flushing of x86 lets you take advantage of normal background writeback and it lets you take advantage of the possibility that the data might never need to be flushed.
Finally, x86 is a horrible instruction set to JIT/translate to anyway. JIT for RISC is a lot more efficient and easier to write. And if you look at emulators that do binary translation, x86 is just about the worst possible arch for that. Translating RISC to x86 is horrendously inefficient.
Hell no.
You get full-size offsets and other constant values on x86. There is no need to screw around with painful restrictions. Look at the constant generation offered by ARM and weep. It's very limited and even redundant. Jump offsets are limited too. If you generate too much ARM code in one place, you can no longer reach constant values that had to be stored near the instruction stream.
Translating RISC to x86 requires a register allocator for decent performance. Fortunately, there is no value in RISC binaries and thus no need to translate from RISC to x86.:-)
Does it really matter if a large cache is running slower when it is attached to a ~1GHz dual-issue CPU? I'm sure ARM have already sacrificed performance however to reduce power consumption.
In any half-reasonable CPU design, you're going to have an L1 cache that is tiny and fast. It can't be big, because that would make it slow.
When code is compact, it tends to be almost 100% cached. It runs fast.
As code grows, there comes a point when it suddenly becomes **much** slower. This is called "falling out of the cache". It isn't normally gradual. If you plot a graph of bloat against speed (normally only done for data because that is easier) you'll see a sharp cliff in the graph.
For most CPUs, you have L2 or even L3 cache. For each level you have, the above-mentioned graph will show a distinct cliff.
A more-compact instruction set moves the positions of those cliffs. Your code can get away with more features, more abstraction, more copy-and-paste hacks, and so on. You have more of a safety margin before performance goes to Hell.
But not on IA32, which this Atom will be running (desktop Atoms support it, but it will be disabled here).
The initial x86 Mac was IA32 as well. That lasted for one hardware generation. These phones won't be IA32 for long.
In addition using AMD64 means longer instruction prefixes, negating your "really compact" argument.
Oddly enough, AMD64 code is more compact. The extra registers, native "long long" support, and other improvements more than make up for the occasional extra byte. (most instructions don't use the extra byte)
Of course when smartphones are coming with 512MB RAM (Nexus One), is code compactness really an issue any more?
Yes, because the cache size remains small. The L1 cache will always be small because larger caches run slower. Large code will "fall out" of the cache, causing it to run with lots of expensive cache misses.
If you're not going to run the JIT code why on earth are you compiling it anyway? There's a reason why it's called JIT. Not to mention that you can just stick the cache ops right before the JIT code is run, instead of as it is compiled.
Code contains branches. For a branch that isn't taken, you have a few choices.
A. You don't JIT until you hit the branch. On x86, this is mildly bad because you add instruction cache pressure ever time you code back into the JIT engine. On ARM, this is severely bad because you're doing a system call for every handful of JITed instructions.
B. You batch things up. You'll JIT some stuff that never runs.
I forgot to mention another difference. ARM caches tend to be virtually indexed and/or virtually tagged. This normally means that you need to flush the whole thing. Partial flushes are too complicated. On x86, the cache is physically indexed and physically tagged. Properly flushing a cache line is trivial; there aren't any aliasing issues.
On ARM, you call into the OS and store DCache/invalidate ICache ranges.
Yeah, I know. That's unusually stupid; on PowerPC at least they made those instructions unprivileged. System calls are not free.
That means only blocks you touched are stored on the D side and invalidated on the I side.
It's even cheaper on x86, because you can delay doing that work. Cache lines get flushed naturally as time passes. By the time the CPU needs things flushed, it might have already happened. Some JITed code will never run; it's best to never pay the cost of handling it.
Of course these details are only explanations of why the system as a whole might perform well or poorly. The simple fact is that ARM is terribly slow in real-world use. You can blame the compiler, the architecture, the fabrication process, the cache size, whatever... but the end result is the same.
Another large advantage is that ARM programs by definition do not use things like self-modifying code without informing the CPU (i.e. issuing a dcache store and an icache invalidate). This means that ARM CPUs can be essentially Harvard architecture machines and they practically don't need any snooping logic for the caches.
This was true until people JITed code became common. (ActionScript, JavaScript, Java,.NET CLR, etc.) Now x86 has an advantage.
x86: translate to native code and then just run it
ARM: translate to native code, call into the OS, have THE CACHE FLUSHED (**ouch**), and then run it
When do we most worry about performance? Oh, when running bloated stuff written in awful scripting languages that must be JITed. Uh oh...
An x86 chip has weird instructions for things like string manipulation that no compiler will ever emit, but which have to be supported by the decoder just in case.
Sorry, that's just wrong. Lots of compilers will emit those instructions, especially when optimizing for size or when the string is known to be small or unaligned. Both gcc and Visual Studio will do it. The string instructions perform very well for small strings, and decently for large strings.
Even if compilers wouldn't emit those instructions, they are sometimes used in C library assembly.
ARM instructions are incredibly dense. Most of them can be predicated on one or more condition registers, which means that you often don't need conditional branches for if statements in high-level languages.
In the real world, compilers almost never do this. (way too difficult) When they do, it's almost never anything more complicated than a conditional move. You can get conditional move on x86 now.
More importantly, there are things like Thumb and Thumb-2, which are 16-bit instruction sets suitable for a lot of ARM code, but which get very good cache density. Unlike x86, these are separate instruction sets.
That tosses out your beloved conditional execution and so much more. Thumb code is nasty shit, full of jumps and PC-relative constant loads. It makes x86 look almost... beautiful.:-/
Despite the waste, x86 instructions are still really compact compared to normal RISC instructions.
Is this really an advantage though? Pipelined processors are much simpler when you can just grab 32 bits (or whatever) for an instruction. I'm not a hardware guy (have worked on a CPU design but was involved more in the compiler side) but it seems that it makes more sense to be consistent. Size of binary hasn't been a factor for years, even on handhelds.
You'd have been 100% correct about 25 years ago. It used to be that CISC instruction decoding was a major cost. Today, CISC instruction decoding is fairly cheap.
Binary size still matters because the instruction cache and the TLB have limits. As code size increases, you tend to "fall out" of the cache. (no longer fitting) This is a severe performance hit.
Modern x86 gives you 16 integer registers, the same as ARM.
x86-64 made some great improvements. What did Intel actually do? Is this an entire parallel instruction set? I will admit to being a bit of a dunce when it comes to this. Can we multiply using a different result register than AX:DX (this one has always annoyed me)
Many of the more useless instructions go away when you set the "long mode" bit. That frees up bytes for a few new instructions and for 16 new prefix bytes, collectively known as the REX prefix. When you use a REX prefix on an instruction, you get access to extra registers and you can perform 64-bit operations.
Still, it makes more sense to leave optimisations to the compiler rather than on-the-fly in silicon.
Intel tried that with the Itanium. It didn't work out so well. There are two huge problems for the compiler. Parallelism is hard for the compiler to identify when dealing with typical code. Memory latency is hard for the compiler to predict. These two problems mean that the compiler will generate code that stalls quite a bit. The "smart" CPU isn't so limited because it can exploit information that is only available at run-time.
And the conditional execution is a useful feature that I really can't do without.
It is a fun feature. You do at least get conditional move on x86, which covers most of the need.
Bzzt, wrong. ARM Thumb gives you 16 registers, it's just that you can only really compute on 8. The others are still accessible by a few instructions (mov, add) and they are still extremely useful for storing values around during the life of a function without having to constantly hit the stack.
If you're going to cheat, I may as well cheat too. I can use the MMX and XMM registers you see. That's 24 registers on older CPUs, or 40 registers on newer CPUs.
Of course, that's a load of shit. (despite the fact that x86 can actually compute in MMX and XMM registers, and damn fast too)
More legitimately, one might use plain old memory. While this works for ARM too, x86 hardware can treat the near part of the stack almost like registers. It's really fast.
The BCD instructions are insignificant. They are nothing compared to stuff like vector floating point and crypto. Despite the waste, x86 instructions are still really compact compared to normal RISC instructions.
A dirty little secret about RISC compilers is that they seldom use more than a few registers. No kidding. Disassemble a wide variety of things and you'll see.
Modern x86 gives you 16 integer registers, the same as ARM. Old x86 gives you 8, the same as ARM Thumb. If there is a difference worth mentioning, it's that x86 chips are often designed to dynamically map the architectural registers onto over 100 hidden implementation-specific registers. This can even be done for memory in some cases.
In the end, it's about the implementation. Intel has the best foundries (best silicon). While optimizing x86 isn't easy, Intel has the money to throw lots of excellent engineers at the problem. In other words, a pig will fly if you provide enough thrust.
You need buttons on the device. Without that, your password could be swiped by PC malware.
A no-frills minimal device comes with 10 buttons. The password is a 10-digit number printed on a card hidden in the packaging. To avoid having the password revealed by button wear, none of the digits repeats. You put the device in, press buttons, and then it shows up to the OS.
A better device has a config setup. Press an extra recessed button, and the device appears as a USB netword device with a DHCP server and all. Go to the device's internal web page, just like setting up a home wireless router. There you could create multiple virtualized devices, each with a distinct password. (if you create more than one, then the device shows up as a hub with child devices) This also allows for data-losing recovery from password loss: you just delete the virtual device you can no longer access, then create an empty virtual device with a new password.
In the absense of antibiotics, selection pressure to remove the resistance will vary greatly by the resistance mechanism.
It appears as though the pressure to remove a resistance gene from the genome, or select in favor of bacteria lacking the gene is negligible. Here is a good example of why.
That's one resistance mechanism in one environment. It's not some cost-free universal mechanism available to all microbes.
It's well known that many resistance mechanisms have serious cost to the organism. We've seen it with tuberculosis (XDR-TB is slow) and with HIV. (and yes I know HIV is a virus; they evolve too)
Normal water is full of all sorts of man-made junk. You can find MBTE, birth control drugs, cocaine, and antibiotics. It's everywhere.
Then there exposure is still the baseline to which everything else is compared. If the resistance gene prevalence is being maintained by the levels of unavoidable antibiotic exposure, then it still shows that EU style ban is pointless.
If we cannot prevent them from any exposure, and the minimum level of exposure still maintains resistance gene abundance at similar levels to when antibiotics were being routinely administered, then what exactly is the ban achieving?
Conclusion: the EU-style ban is inadequate. A proper ban must be world-wide and complete.
Did you bother reading what I wrote in its entirety? I said that antibiotics in livestock decrease the time it takes for the resistance genes to appear and get into the human population. It's the widespread abuse of antibiotics in HUMANS that maintain the selective pressure on HUMAN colonizing microbiota to retain the resistance genes.
Antibiotics in livestock cause **antibiotics** in humans. (and in lakes, and in the sea, and in your tap water...)
I'm not suggesting anything about bacteria jumping from animals to humans. Purely HUMAN colonizing microbiota living IN HUMANS get exposed to antibiotics because of the food (especially antibiotic-treated animals but even salad) and other environmental contamination.
The resulting selective pressure is long-term, which is just the thing to cause resistance to become common.
Do you have any idea how much biohazard containment costs?? This would price antibiotics out of the range of just about everyone. I stand by my assertion, this would be moronic and lead to increased fatalities.
This is short-term thinking. Failure to fully isolate people means that all antibiotics will be useless in a century.
The tradeoff you're making: save more people (the poor included) for a century, causing everybody (both rich and poor) to suffer increased fatalities until the end of time.
No. Some of them did. Most were invented by people.
Even if it were true that they all originated from the ecosystem, it wouldn't be everywhere. Something that grows on a cantalope isn't likely to attack a wound.
Antibiotic resistance genes are not the evolutionary dead weight that you seem to believe they are.
In the absense of antibiotics, selection pressure to remove the resistance will vary greatly by the resistance mechanism.
There is a swine herd in the US that hasn't had any exposure to antibiotics for over 50 years.
I don't believe it. Where do they get the food and water? Normal water is full of all sorts of man-made junk. You can find MBTE, birth control drugs, cocaine, and antibiotics. It's everywhere.
Banning antibiotics for anything other than a full biohazard situation is moronic at best. Antibiotics save lives every year in cases that are far less serious than that, and I for one don't want those deaths on my conscience.
You're implying that people wouldn't get the antibiotics. I certainly don't mean that, unless somebody refuses to go into biohazard containment.
Got an infection? No problem, we'll give you antibiotics, but you aren't leaving the biohazard unit until all traces of antibiotic and all traces of resistant organisms are gone from your body.
However, that doesn't mean that we can't improve things by making it a general rule that otherwise healthy individuals have to wait at least a week before they will be given antibiotics for their infection, baring any serious developments in the mean time.
Now **that** will kill a few people from time to time. We do a poor job of keeping watch. Even if we do a decent job, you'll be spending time in a heavily contaminated hospital environment and picking up new diseases.
Unlike genuine alien abductions, there is actually a plausible mechanism (autoimmune disease) for vaccination to cause autism. Alien abduction claims (presumably not genuine abductions) are associated with schitzophrenia, which could in some cases be caused by autoimmune disease and thus caused by vaccines.
You can't just run a trial, at least here in the USA. You need FDA approval, which means going up against the vaccine industry lobby..
The "statistical anomalies" argument is shit. You're essentially tossing out a key pillar of modern science. If you really want to disregard modern statistics, please note that you're missing out on the chance that things go the other way, with vaccines shown to prevent autism.
Autoimmune problems can cause all sorts of weird trouble (for example all your hair falling out even eyelashes) and we know that vaccines can trigger autoimmune disease.
It's completely possible that vaccines cause autism. It's very easy to determine this: we need a double-blind trial. We can look into non-autism problems too.
This has been resisted. Can you blame anybody for being suspicious when people with obvious financial incentives are resisting a double-blind trial?
You forget the effect of residual antibiotic in food.
Once resistance appears in humans, having a bit of antibiotic in the food supply provides the selection advantage needed to make the resistant strain common.
To really solve the problem, we need to ban antibiotics WORLDWIDE for anything other than full biohazard containment situations. If somebody recently treated with antibiotics is allowed to use a toilet connected to the normal sewerage system, then that antibiotic is getting out into the environment. Absolutely every bit of waste generated by an antibiotic-treated patient needs high-temperature incineration.
Think of an antibiotic as a secret that humanity must hide from the ecosystem.
Slashdot Mirror
Sailors aren't virgin births you know. They have to get in there somehow.
Most changes to defeat birth control are going
to be mental, but other changes can work too.
In this case, semen that spills out of a condom.
(BTW, for the women and the pill: hormone arms race)
ICache flushes are going to do nothing for a JIT anyway (most of the time), so they are little overhead too. So we've eliminated system calls and ICache invalidates as valid points for your argument. You're down to claiming that a single DCache partial store at the right point is going to be more expensive than the ridiculously complex and poor auto-flushing that x86 does. Good luck with that.
I looked up the ARM code for Linux 2.6.31 and it doesn't generally work the way you think it does.
The whole instruction cache gets invalidated.
Ouch. Even the Pentium-4 wasn't that awful.
(hint: not flush, get your vocabulary right.
Normally they go together. ARM Linux has exactly one system call for this, and the name is "cacheflush".
Properly flushing a cache line is trivial; there aren't any aliasing issues.
Maybe you should tell the ARM Linux developers how to do this if you really think it is so easy.
Properly flushing a cache line is all but impossible on x86, since it only got a cache line flush instruction with the introduction of SSE2.
Well, if you want to be explicit. Normally it comes free.
x86 depends solely on guesswork by the CPU, and guesswork is by definition going to be worse than the programmer flushing what's needed ONLY when it's needed.
You ignored my example showing that this is not the case. The delayed flushing of x86 lets you take advantage of normal background writeback and it lets you take advantage of the possibility that the data might never need to be flushed.
Finally, x86 is a horrible instruction set to JIT/translate to anyway. JIT for RISC is a lot more efficient and easier to write. And if you look at emulators that do binary translation, x86 is just about the worst possible arch for that. Translating RISC to x86 is horrendously inefficient.
Hell no.
You get full-size offsets and other constant values on x86. There is no need to screw around with painful restrictions. Look at the constant generation offered by ARM and weep. It's very limited and even redundant. Jump offsets are limited too. If you generate too much ARM code in one place, you can no longer reach constant values that had to be stored near the instruction stream.
Translating RISC to x86 requires a register allocator for decent performance. Fortunately, there is no value in RISC binaries and thus no need to translate from RISC to x86. :-)
Does it really matter if a large cache is running slower when it is attached to a ~1GHz dual-issue CPU? I'm sure ARM have already sacrificed performance however to reduce power consumption.
In any half-reasonable CPU design, you're going to have an L1 cache that is tiny and fast. It can't be big, because that would make it slow.
When code is compact, it tends to be almost 100% cached. It runs fast.
As code grows, there comes a point when it suddenly becomes **much** slower. This is called "falling out of the cache". It isn't normally gradual. If you plot a graph of bloat against speed (normally only done for data because that is easier) you'll see a sharp cliff in the graph.
For most CPUs, you have L2 or even L3 cache. For each level you have, the above-mentioned graph will show a distinct cliff.
A more-compact instruction set moves the positions of those cliffs. Your code can get away with more features, more abstraction, more copy-and-paste hacks, and so on. You have more of a safety margin before performance goes to Hell.
But not on IA32, which this Atom will be running (desktop Atoms support it, but it will be disabled here).
The initial x86 Mac was IA32 as well. That lasted for one hardware generation. These phones won't be IA32 for long.
In addition using AMD64 means longer instruction prefixes, negating your "really compact" argument.
Oddly enough, AMD64 code is more compact. The extra registers, native "long long" support, and other improvements more than make up for the occasional extra byte. (most instructions don't use the extra byte)
Of course when smartphones are coming with 512MB RAM (Nexus One), is code compactness really an issue any more?
Yes, because the cache size remains small. The L1 cache will always be small because larger caches run slower. Large code will "fall out" of the cache, causing it to run with lots of expensive cache misses.
If you're not going to run the JIT code why on earth are you compiling it anyway? There's a reason why it's called JIT. Not to mention that you can just stick the cache ops right before the JIT code is run, instead of as it is compiled.
Code contains branches. For a branch that isn't taken, you have a few choices.
A. You don't JIT until you hit the branch. On x86, this is mildly bad because you add instruction cache pressure ever time you code back into the JIT engine. On ARM, this is severely bad because you're doing a system call for every handful of JITed instructions.
B. You batch things up. You'll JIT some stuff that never runs.
I forgot to mention another difference. ARM caches tend to be virtually indexed and/or virtually tagged. This normally means that you need to flush the whole thing. Partial flushes are too complicated. On x86, the cache is physically indexed and physically tagged. Properly flushing a cache line is trivial; there aren't any aliasing issues.
On ARM, you call into the OS and store DCache/invalidate ICache ranges.
Yeah, I know. That's unusually stupid; on PowerPC at least they made those instructions unprivileged. System calls are not free.
That means only blocks you touched are stored on the D side and invalidated on the I side.
It's even cheaper on x86, because you can delay doing that work. Cache lines get flushed naturally as time passes. By the time the CPU needs things flushed, it might have already happened. Some JITed code will never run; it's best to never pay the cost of handling it.
Of course these details are only explanations of why the system as a whole might perform well or poorly. The simple fact is that ARM is terribly slow in real-world use. You can blame the compiler, the architecture, the fabrication process, the cache size, whatever... but the end result is the same.
Another large advantage is that ARM programs by definition do not use things like self-modifying code without informing the CPU (i.e. issuing a dcache store and an icache invalidate). This means that ARM CPUs can be essentially Harvard architecture machines and they practically don't need any snooping logic for the caches.
This was true until people JITed code became common. (ActionScript, JavaScript, Java, .NET CLR, etc.) Now x86 has an advantage.
x86: translate to native code and then just run it
ARM: translate to native code, call into the OS, have THE CACHE FLUSHED (**ouch**), and then run it
When do we most worry about performance? Oh, when running bloated stuff written in awful scripting languages that must be JITed. Uh oh...
An x86 chip has weird instructions for things like string manipulation that no compiler will ever emit, but which have to be supported by the decoder just in case.
Sorry, that's just wrong. Lots of compilers will emit those instructions, especially when optimizing for size or when the string is known to be small or unaligned. Both gcc and Visual Studio will do it. The string instructions perform very well for small strings, and decently for large strings.
Even if compilers wouldn't emit those instructions, they are sometimes used in C library assembly.
ARM instructions are incredibly dense. Most of them can be predicated on one or more condition registers, which means that you often don't need conditional branches for if statements in high-level languages.
In the real world, compilers almost never do this. (way too difficult) When they do, it's almost never anything more complicated than a conditional move. You can get conditional move on x86 now.
More importantly, there are things like Thumb and Thumb-2, which are 16-bit instruction sets suitable for a lot of ARM code, but which get very good cache density. Unlike x86, these are separate instruction sets.
That tosses out your beloved conditional execution and so much more. Thumb code is nasty shit, full of jumps and PC-relative constant loads. It makes x86 look almost... beautiful. :-/
Despite the waste, x86 instructions are still really compact compared to normal RISC instructions.
Is this really an advantage though? Pipelined processors are much simpler when you can just grab 32 bits (or whatever) for an instruction. I'm not a hardware guy (have worked on a CPU design but was involved more in the compiler side) but it seems that it makes more sense to be consistent. Size of binary hasn't been a factor for years, even on handhelds.
You'd have been 100% correct about 25 years ago. It used to be that CISC instruction decoding was a major cost. Today, CISC instruction decoding is fairly cheap.
Binary size still matters because the instruction cache and the TLB have limits. As code size increases, you tend to "fall out" of the cache. (no longer fitting) This is a severe performance hit.
Modern x86 gives you 16 integer registers, the same as ARM.
x86-64 made some great improvements. What did Intel actually do? Is this an entire parallel instruction set? I will admit to being a bit of a dunce when it comes to this. Can we multiply using a different result register than AX:DX (this one has always annoyed me)
Many of the more useless instructions go away when you set the "long mode" bit. That frees up bytes for a few new instructions and for 16 new prefix bytes, collectively known as the REX prefix. When you use a REX prefix on an instruction, you get access to extra registers and you can perform 64-bit operations.
Still, it makes more sense to leave optimisations to the compiler rather than on-the-fly in silicon.
Intel tried that with the Itanium. It didn't work out so well. There are two huge problems for the compiler. Parallelism is hard for the compiler to identify when dealing with typical code. Memory latency is hard for the compiler to predict. These two problems mean that the compiler will generate code that stalls quite a bit. The "smart" CPU isn't so limited because it can exploit information that is only available at run-time.
And the conditional execution is a useful feature that I really can't do without.
It is a fun feature. You do at least get conditional move on x86, which covers most of the need.
Of course, a certain level of trust is implied by the use of the device. At minimum you're making one filesystem readable; it could be copied.
That doesn't mean you must make the filesystem writable unless actually needed.
That doesn't mean you must give up a password which you might (wrongly...) be using elsewhere.
That doesn't mean that you must make all filesystems available. Virtual devices allow you to make a per-computer choice.
You got the current data, and maybe (if a read-write password is used) you got to mangle it.
You don't get future access. Stealing the device next year won't do you any good.
You don't get some password that I might be improperly (humans are lazy) using for something more important.
If virtual devices are in use, you only got access to the one I activated.
Bzzt, wrong. ARM Thumb gives you 16 registers, it's just that you can only really compute on 8. The others are still accessible by a few instructions (mov, add) and they are still extremely useful for storing values around during the life of a function without having to constantly hit the stack.
If you're going to cheat, I may as well cheat too. I can use the MMX and XMM registers you see. That's 24 registers on older CPUs, or 40 registers on newer CPUs.
Of course, that's a load of shit. (despite the fact that x86 can actually compute in MMX and XMM registers, and damn fast too)
More legitimately, one might use plain old memory. While this works for ARM too, x86 hardware can treat the near part of the stack almost like registers. It's really fast.
The BCD instructions are insignificant. They are nothing compared to stuff like vector floating point and crypto. Despite the waste, x86 instructions are still really compact compared to normal RISC instructions.
A dirty little secret about RISC compilers is that they seldom use more than a few registers. No kidding. Disassemble a wide variety of things and you'll see.
Modern x86 gives you 16 integer registers, the same as ARM. Old x86 gives you 8, the same as ARM Thumb. If there is a difference worth mentioning, it's that x86 chips are often designed to dynamically map the architectural registers onto over 100 hidden implementation-specific registers. This can even be done for memory in some cases.
In the end, it's about the implementation. Intel has the best foundries (best silicon). While optimizing x86 isn't easy, Intel has the money to throw lots of excellent engineers at the problem. In other words, a pig will fly if you provide enough thrust.
There goes **everything** if I'm using the phone for everything. When I drop it down a pit toilet, I'm not getting it back.
Say, these are dirt cheap, right? I'm putting mine in the clothes washer you see...
Should it also serve as my photo album, identity, and debit card? BTW, I just might drop it next to a 600v 3rd rail. Want to fetch it for me?
You need buttons on the device. Without that, your password could be swiped by PC malware.
A no-frills minimal device comes with 10 buttons. The password is a 10-digit number printed on a card hidden in the packaging. To avoid having the password revealed by button wear, none of the digits repeats. You put the device in, press buttons, and then it shows up to the OS.
A better device has a config setup. Press an extra recessed button, and the device appears as a USB netword device with a DHCP server and all. Go to the device's internal web page, just like setting up a home wireless router. There you could create multiple virtualized devices, each with a distinct password. (if you create more than one, then the device shows up as a hub with child devices) This also allows for data-losing recovery from password loss: you just delete the virtual device you can no longer access, then create an empty virtual device with a new password.
In the absense of antibiotics, selection pressure to remove the resistance will vary greatly by the resistance mechanism.
It appears as though the pressure to remove a resistance gene from the genome, or select in favor of bacteria lacking the gene is negligible. Here is a good example of why.
That's one resistance mechanism in one environment. It's not some cost-free universal mechanism available to all microbes.
It's well known that many resistance mechanisms have serious cost to the organism. We've seen it with tuberculosis (XDR-TB is slow) and with HIV. (and yes I know HIV is a virus; they evolve too)
Normal water is full of all sorts of man-made junk. You can find MBTE, birth control drugs, cocaine, and antibiotics. It's everywhere.
Then there exposure is still the baseline to which everything else is compared. If the resistance gene prevalence is being maintained by the levels of unavoidable antibiotic exposure, then it still shows that EU style ban is pointless.
If we cannot prevent them from any exposure, and the minimum level of exposure still maintains resistance gene abundance at similar levels to when antibiotics were being routinely administered, then what exactly is the ban achieving?
Conclusion: the EU-style ban is inadequate. A proper ban must be world-wide and complete.
Something is better than nothing. :-(
Did you bother reading what I wrote in its entirety? I said that antibiotics in livestock decrease the time it takes for the resistance genes to appear and get into the human population. It's the widespread abuse of antibiotics in HUMANS that maintain the selective pressure on HUMAN colonizing microbiota to retain the resistance genes.
Antibiotics in livestock cause **antibiotics** in humans. (and in lakes, and in the sea, and in your tap water...)
I'm not suggesting anything about bacteria jumping from animals to humans. Purely HUMAN colonizing microbiota living IN HUMANS get exposed to antibiotics because of the food (especially antibiotic-treated animals but even salad) and other environmental contamination.
The resulting selective pressure is long-term, which is just the thing to cause resistance to become common.
Do you have any idea how much biohazard containment costs?? This would price antibiotics out of the range of just about everyone. I stand by my assertion, this would be moronic and lead to increased fatalities.
This is short-term thinking. Failure to fully isolate people means that all antibiotics will be useless in a century.
The tradeoff you're making: save more people (the poor included) for a century, causing everybody (both rich and poor) to suffer increased fatalities until the end of time.
Antibiotics originated from the ecosystem.
No. Some of them did. Most were invented by people.
Even if it were true that they all originated from the ecosystem, it wouldn't be everywhere. Something that grows on a cantalope isn't likely to attack a wound.
Antibiotic resistance genes are not the evolutionary dead weight that you seem to believe they are.
In the absense of antibiotics, selection pressure to remove the resistance will vary greatly by the resistance mechanism.
There is a swine herd in the US that hasn't had any exposure to antibiotics for over 50 years.
I don't believe it. Where do they get the food and water? Normal water is full of all sorts of man-made junk. You can find MBTE, birth control drugs, cocaine, and antibiotics. It's everywhere.
Banning antibiotics for anything other than a full biohazard situation is moronic at best. Antibiotics save lives every year in cases that are far less serious than that, and I for one don't want those deaths on my conscience.
You're implying that people wouldn't get the antibiotics. I certainly don't mean that, unless somebody refuses to go into biohazard containment.
Got an infection? No problem, we'll give you antibiotics, but you aren't leaving the biohazard unit until all traces of antibiotic and all traces of resistant organisms are gone from your body.
However, that doesn't mean that we can't improve things by making it a general rule that otherwise healthy individuals have to wait at least a week before they will be given antibiotics for their infection, baring any serious developments in the mean time.
Now **that** will kill a few people from time to time. We do a poor job of keeping watch. Even if we do a decent job, you'll be spending time in a heavily contaminated hospital environment and picking up new diseases.
Unlike genuine alien abductions, there is actually a plausible mechanism (autoimmune disease) for vaccination to cause autism. Alien abduction claims (presumably not genuine abductions) are associated with schitzophrenia, which could in some cases be caused by autoimmune disease and thus caused by vaccines.
You can't just run a trial, at least here in the USA. You need FDA approval, which means going up against the vaccine industry lobby..
The "statistical anomalies" argument is shit. You're essentially tossing out a key pillar of modern science. If you really want to disregard modern statistics, please note that you're missing out on the chance that things go the other way, with vaccines shown to prevent autism.
Autoimmune problems can cause all sorts of weird trouble (for example all your hair falling out even eyelashes) and we know that vaccines can trigger autoimmune disease.
It's completely possible that vaccines cause autism. It's very easy to determine this: we need a double-blind trial. We can look into non-autism problems too.
This has been resisted. Can you blame anybody for being suspicious when people with obvious financial incentives are resisting a double-blind trial?
You forget the effect of residual antibiotic in food.
Once resistance appears in humans, having a bit of antibiotic in the food supply provides the selection advantage needed to make the resistant strain common.
To really solve the problem, we need to ban antibiotics WORLDWIDE for anything other than full biohazard containment situations. If somebody recently treated with antibiotics is allowed to use a toilet connected to the normal sewerage system, then that antibiotic is getting out into the environment. Absolutely every bit of waste generated by an antibiotic-treated patient needs high-temperature incineration.
Think of an antibiotic as a secret that humanity must hide from the ecosystem.