Not that it may even matter, it's unlikely the cost of selling ips will be worth the cost of changing ip ranges. Depends what the IPs are being used for and what the price per IP gets like.
I'd think the first thing to go will be free public IPs for home users. Home users tend to be on dynamic IPs anyway so the cost of readdressing them to private (or for those who pay extra for a public IP to a new smaller public block) will be relatively low and the addresses will be able to be recovered in relatively big blocks.
Low end hosting/colo/dedicated packages will probablly get less generous in their IP allocations as well but because those IPs tend to be static I'd expect those IPs to be more suited to internal reuse than to resale.
Say I'm an ISP, we have all old v4 hardware. To the extent our routers support v6, it is all in software meaning that any significant amount of IPv6 will overload them. They only have IPv4 ASICs. I don't wanna upgrade because it is expensive. So I keep getting more and more customers that want IPs. However, I run out, my allocation is gone. ARIN says "Sorry, all space is allocated." So I go looking around. Turns out I can buy a/24... But for 500x what I used to. Ouch. Well then, maybe time to get some IPv6 hardware. One big problem is that IPV4-only hosts and IPV6-only hosts cannot talk to each other. Therefore migrating to V6 only isn't an option for most hosts until large parts of the internet are on dual-stack. Migrating from V4 only to dual-stack does not save you any IPs.
Teredo and 6to4 may help a bit with this but they have issues of their own (teredo is very fragile, 6to4 needs a public v4 IP)
but eventually it will be a matter of who pays more. And in turn it will also be a matter of cost of continuing to use those public V4 addresses VS cost of other options. Other options include IPV6 and private IPV4.
and sure, there are lots of tolerances in a car engine that are much less than 1 mm, but it is about 1 meter across, not 1/3 of a km) Now lets assume there is a car engine on that aircraft carrier. Lets further assume that someone copies the "car engine" model into the "aircraft carrier" model and then later copies and pastes out the car engine and the machine it drives out of the aircraft carrier model to simulate it.
If the system is using global floating point coordinates and the engine wasn't pasted near coordinate zero then the model of the car engine copied out will be much less accurate than the model of the car engine copied in!
As I understand it there are two sides to the IEEE 754 issue.
The first is the data format. Most modern systems use the IEEE 754 formats so you can pass data arround pretty freely (there are some potential endian issues but those aren't too bad to deal with).
The second is rounding rules and the size of intermediate values etc. Afaict very few systems get these exactly as the standard specifies. For a well known example C compiled for the x87 will store values in floating point registers in much higher precision than the same value stored in memory in IEEE format.
Compilers will typically store variables both in memory (in the declared format) and in floating point registers (in the FPU internal format) depending on current register allocation pressure.
This is only a problem if you consider repeatability more important than accuracy.
Java is actually pretty unusual in giving you the option (though it doesn't do it by default) to force all intermediate values to be rounded to the variable's declared size.
The trouble with both C and Java is they don't let you define your own types that are on par with the native types so even if you write or find such a library it will be a pain to use.
C++ OTOH gives you the tools needed to build your own types that can be used like the built in ones and a quick google search finds a couple of examples of this.
However arbitrary precision has it's issues too. In particular in a long sequence of calculations your memory use can balloon out of control. Also there are still many numbers that simply cannot be represented in an arbitrary precision decimal or even an arbitrary precision vulgar fraction.
Plus it's going to be extremely slow and memory hungry compared to using the built in floating point support in your CPU.
The only right answer is to understand your algorithm and it's characteristics so you can work out what precision is sufficient precision and whether that precision should be defined in absoloute terms or as a proportion of the value being handled.
Decimal representations (BCD and/or a binary value with a power of ten scale factor*) make sense when you need to exactly replicate on a computer rules written by humans for humans. The main problem domain in which this is an issue is finance.
They also have the advantage that a greater proportion of low denominator fractions can be represented exactly.
However in general most scientific and engineering calculations won't come out nicely in either system so you will still have to round it's just a case of how much by. With both binary and decimal formats this ammount can be arbiterally small so no real advantage to either system for science/engineering/
I suspect the main reason though was complexity. Straight binary arithmetic is much simpler in logic terms than BCD arithmetic. Particularlly when multiplication becomes involved. Binary values with power of ten scale factors make multiplication and division (for fixed point) or renormalisation (for floating point) a lot trickier.
Strictfp gives you more repeatability but less performance and generally less accuracy.
It has it's place (e.g. when you have a fixed set of input data and need to be able to accurately repeat the exact same results) but generally if you think you need it you probably either misunderstood what it does or have an underlying design flaw in your system.
Integration over a time period rather than taking a single reading reduces noise. Rounding errors are NOT noise. Sometimes they are modelled as noise but under certain circumstances that model breaks down.
In particular if the numerical integration is implemented as a running sum and the input to the integration is relatively constant all the rounding is likely to be in the same direction and hence builds up in the integration rather than cancelling. In the extreme degenerate case the output may stop changing AT ALL.
One way around this would be to use a probabilistic rounding algorithm but I'm not aware of any system that does this. Other possibilities include increasing the precision and doing the integration as an addition tree [ ((a+b)+(c+d))+((e+f)+(g+h)) ]rather than a running sum [ (((((((a+b)+c)+d)+e)+f)+g)+h) ].
Back in the early days the analog computer was used for things like ballistic calculations. I would think that they would be less prone to this type of problem. With analog voltages/currents you have noise, with fixed size digital values* you have rounding errors. Both mean that you won't get an exact answer in most cases.
The big advantage of digital over analog is you can make the errors arbitrarily small. FAR smaller than you could reasonally acheive in an analog system.
The big disadvantage of digital is that rounding errors are less independent of each other than noise. Noise tends to cancel out in integration but rounding errors don't tend to cancel out anywhere near as well (consider the simple case of numeric integration of a straight line in fixed point for example: ALL the rounding errors would be in the same direction).
*This applies whether decimal or binary and whether fixed or floating point, it doesn't apply to things like bignums but there you have the problem that your numeric representation can end up arbiterally big.
I don't think you are correct about two numbers not being "nearly equal" when they are both close to zero, but with opposite signs. The function returns "true" in this case, no? Are you suggesting this is undesirable? I could see for some use cases that property might be undesirable, but if that's what you meant it wasn't clear. Certainly that property is desirable for some applications. IMO this sort of thing is a good reason NOT to write a nearlyequals(a,b) function. That will just lull you into a false sense of security that the same rules are appropriate in every case.
You need to consider each case on it's own merits to decide what is meant by "nearly equals" in context.
In some cases that may be best defined in terms of absolute error, in some cases that may be best defined in terms of error relative to the value and in yet other cases it may be best defined in terms of the error relative to the current precision which is related to the value for larger numbers but becomes fixed for smaller (subnormal) numbers.
What you correctly identified is the impact of idiot consumers on product lines and marketing. People liked the cute 7" EEEs, but they lacked a few creature comforts so the masses complained. Lets see it had a 7 inch screen in a case big enough for a 9 inch, WTF! The storage was also tiny.
It caught peoples attention by being the first in it's category (the ultraportable category was pretty dead at that stage, afaict the only real options were a refurb libretto or a VERY expensive sony) but in retrospect it was a pretty shitty machine.
Asus responded by creating shitty laptops that addressed these complaints. After the 700 series came the 900 series, these were about the same size as the 700 series but fitted a bigger screen into that case and pushed up the storage. WIN
Then came the 1000 series where for an extra inch they squeezed in a proper hard drive and a bigger keyboard. The screen resoloution was a huge disappointment though (eventually I ended up getting a HP mini 5101 because of this issue).
Then came the 12 inch ones which I agree with you are stupid when you can get a machine with a proper C2D processor in 12 inch at a similar pricetag.
why can't they put a man-sized battery in a netbook and have it last 12+ hours ? I just want a machine that will get through an entire day without charging; a programmer's notepad so I can type and test my brilliant code snippets whenever and wherever they materialize. Some ebayers were apparently selling 9-cell batteries for the mini 21xx series which may meet this requirement but I'd agree it's a niche the vendors seem to have missed out on.
I couldn't tolerate smaller screens due to the poor resolution I had (and still have) a 13 inch macbook (which spends most of it's time running linux) but I wanted something a bit smaller and less valuable for use on the train but I really didn't want to sacrifice screen resolution.
In the end I got a HP mini 5101. The build quality seems reasonable (though only time will tell for sure), the screen resolution is as good as your aspire one and depending on your criteria could be considered better than my macbook (1366x768 has more pixels than 1280x800 but I'd still rather have the latter)
Not sure about the battery life, UK long distance trains generally have power sockets so battery life is a non-issue.
The overall size is about the same as an EEE 1000 and the keyboard feels as good as the one on my macbook (it really helps that HP have taken it extremely close to the case edge).
Add ram to that list too. Laptops in my experiance have at most 2 slots and the largest laptop sticks out there are 4GB (and even those have only become a viable option fairly recently).
On the desktop side many higher end boards have 4 or even 6 slots which with 4GB modules (afaict 4GB is the largest that most current desktop boards support) gives you 16GB or 24GB of ram. Workstation boards give you even more.
My experience with dells has been that if I look up the type on crucial and then buy that type of any decent brand they are fine.
I did once have a dell BSOD a lot after a memory upgrade but i'm fairly sure that was just a bad stick (another stick of the same make and model was fine as were sticks of the same make and model put in identical machines)
Though that forum thread looks very old (it talks about P3 machines), maybe things were worse years ago (all my experiance with upgrading memory in dells has been either P4 or core 2 stuff with either DDR or DDR2 ram).
Otherwise, it will just perform a word read, and if the pointer isn't aligned you get garbage. Some but not all arm chips can be told to generate an exception in this case.
from http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/1228.html ARM processors with full MMUs (e.g. ARM920T) support optional alignment checking where the processor will check every access to ensure it is correctly aligned. The MMU will raise a data abort if an incorrectly aligned access occurs.
Some ARM partners using simple cores such as the ARM7TDMI have implemented alignment-checking for their ASIC/ASSP. This can be done with an additional hardware block external to the ARM core, which monitors the access size and the least significant bits of the address bus for every data access. The ASIC/ASSP can be configured to raise the ABORT signal in the case of an unaligned access. ARM recommends that such logic is included on ASIC/ASSP devices where code will be ported from other architectures.
Linux can use these exceptions to fix up access if you desire (or you can set it up to generate a bus error signal to help in debugging)
from http://www.mjmwired.net/kernel/Documentation/arm/mem_alignment 15 Now for user space applications, it is possible to configure the alignment 16 trap to SIGBUS any code performing unaligned access (good for debugging bad 17 code), or even fixup the access by software like for kernel code. The later 18 mode isn't recommended for performance reasons (just think about the 19 floating point emulation that works about the same way). Fix your code 20 instead!
People have managed to get a little endian kernels running on hardware that was originally intended to run big endian (the linksys NSLU2) sbut my understanding is it was nontrivial (and it took them quite some time to get all the hardware to work with the little endian kernel)
Not really. Or rather, it used to be the case, but that shit had (mostly) already hit the fan back when x64 appeared. Admittedly this is a desktop perspective but the impression I get is that only a small handful of windows apps are actually x64 (this contrasts sharply with linux where the norm is to run a system where almost everything is x64).
And even when an app adds x64 support they don't always make everything 64-bit. For example with hfss the simulation engine is 64-bit but the user interface/modelling tool is 32-bit.
Afaict datacenters generally charge based on peak current anyway since much of the cost of datacenter electricity is actually in the infrastructure (generators, UPSs etc).
Performance per watt does matter to an extent but performance of individual threads also matters. The longer each individual request takes to deal with the more ram you need and the longer you keep any DB locks open for increasing the chance of lock contention there.
Another big problem with arm is that you can't rely on the presence of any particular floating point instructions. So you either compile everything for the specific FPU variant you have or you end up using softfloat
The problem is more the apps, windows itself could probably be ported without too much trouble but most windows apps are likely to have code that makes x86 specific assumptions and are closed source so only the vendors can fix them.
Emulation is an option but unless arm cores start performing a LOT better than intel cores of a similar power envelope that won't help much.
Therefore I don't think the "hotel guests don't want to use 3G cause it's expensive" argument holds that much water. It doesn't apply to every guest but it will apply to a substantial subset of them. Especially in europe.
Every other country I've been to, phone providers normally cover the whole country. However a lot of countries aren't all that big.
EU countries are often comparable in size to american states and there are usually no border controls between them yet when you cross that barely marked border (and I suspect possiblly before if you are unlucky about coverage) you are roaming internationally. The EU has put pressure on the operators to lower voice roaming rates but afaict data roaming is still sky high.
Slashdot Mirror
Not that it may even matter, it's unlikely the cost of selling ips will be worth the cost of changing ip ranges.
Depends what the IPs are being used for and what the price per IP gets like.
I'd think the first thing to go will be free public IPs for home users. Home users tend to be on dynamic IPs anyway so the cost of readdressing them to private (or for those who pay extra for a public IP to a new smaller public block) will be relatively low and the addresses will be able to be recovered in relatively big blocks.
Low end hosting/colo/dedicated packages will probablly get less generous in their IP allocations as well but because those IPs tend to be static I'd expect those IPs to be more suited to internal reuse than to resale.
Say I'm an ISP, we have all old v4 hardware. To the extent our routers support v6, it is all in software meaning that any significant amount of IPv6 will overload them. They only have IPv4 ASICs. I don't wanna upgrade because it is expensive. So I keep getting more and more customers that want IPs. However, I run out, my allocation is gone. ARIN says "Sorry, all space is allocated." So I go looking around. Turns out I can buy a /24... But for 500x what I used to. Ouch. Well then, maybe time to get some IPv6 hardware.
One big problem is that IPV4-only hosts and IPV6-only hosts cannot talk to each other. Therefore migrating to V6 only isn't an option for most hosts until large parts of the internet are on dual-stack. Migrating from V4 only to dual-stack does not save you any IPs.
Teredo and 6to4 may help a bit with this but they have issues of their own (teredo is very fragile, 6to4 needs a public v4 IP)
but eventually it will be a matter of who pays more.
And in turn it will also be a matter of cost of continuing to use those public V4 addresses VS cost of other options. Other options include IPV6 and private IPV4.
and sure, there are lots of tolerances in a car engine that are much less than 1 mm, but it is about 1 meter across, not 1/3 of a km)
Now lets assume there is a car engine on that aircraft carrier. Lets further assume that someone copies the "car engine" model into the "aircraft carrier" model and then later copies and pastes out the car engine and the machine it drives out of the aircraft carrier model to simulate it.
If the system is using global floating point coordinates and the engine wasn't pasted near coordinate zero then the model of the car engine copied out will be much less accurate than the model of the car engine copied in!
As I understand it there are two sides to the IEEE 754 issue.
The first is the data format. Most modern systems use the IEEE 754 formats so you can pass data arround pretty freely (there are some potential endian issues but those aren't too bad to deal with).
The second is rounding rules and the size of intermediate values etc. Afaict very few systems get these exactly as the standard specifies. For a well known example C compiled for the x87 will store values in floating point registers in much higher precision than the same value stored in memory in IEEE format.
Compilers will typically store variables both in memory (in the declared format) and in floating point registers (in the FPU internal format) depending on current register allocation pressure.
This is only a problem if you consider repeatability more important than accuracy.
Java is actually pretty unusual in giving you the option (though it doesn't do it by default) to force all intermediate values to be rounded to the variable's declared size.
The trouble with both C and Java is they don't let you define your own types that are on par with the native types so even if you write or find such a library it will be a pain to use.
C++ OTOH gives you the tools needed to build your own types that can be used like the built in ones and a quick google search finds a couple of examples of this.
However arbitrary precision has it's issues too. In particular in a long sequence of calculations your memory use can balloon out of control. Also there are still many numbers that simply cannot be represented in an arbitrary precision decimal or even an arbitrary precision vulgar fraction.
Plus it's going to be extremely slow and memory hungry compared to using the built in floating point support in your CPU.
The only right answer is to understand your algorithm and it's characteristics so you can work out what precision is sufficient precision and whether that precision should be defined in absoloute terms or as a proportion of the value being handled.
Decimal representations (BCD and/or a binary value with a power of ten scale factor*) make sense when you need to exactly replicate on a computer rules written by humans for humans. The main problem domain in which this is an issue is finance.
They also have the advantage that a greater proportion of low denominator fractions can be represented exactly.
However in general most scientific and engineering calculations won't come out nicely in either system so you will still have to round it's just a case of how much by. With both binary and decimal formats this ammount can be arbiterally small so no real advantage to either system for science/engineering/
I suspect the main reason though was complexity. Straight binary arithmetic is much simpler in logic terms than BCD arithmetic. Particularlly when multiplication becomes involved. Binary values with power of ten scale factors make multiplication and division (for fixed point) or renormalisation (for floating point) a lot trickier.
Strictfp gives you more repeatability but less performance and generally less accuracy.
It has it's place (e.g. when you have a fixed set of input data and need to be able to accurately repeat the exact same results) but generally if you think you need it you probably either misunderstood what it does or have an underlying design flaw in your system.
All depends on the *type* of error.
Integration over a time period rather than taking a single reading reduces noise. Rounding errors are NOT noise. Sometimes they are modelled as noise but under certain circumstances that model breaks down.
In particular if the numerical integration is implemented as a running sum and the input to the integration is relatively constant all the rounding is likely to be in the same direction and hence builds up in the integration rather than cancelling. In the extreme degenerate case the output may stop changing AT ALL.
One way around this would be to use a probabilistic rounding algorithm but I'm not aware of any system that does this. Other possibilities include increasing the precision and doing the integration as an addition tree [ ((a+b)+(c+d))+((e+f)+(g+h)) ]rather than a running sum [ (((((((a+b)+c)+d)+e)+f)+g)+h) ].
Back in the early days the analog computer was used for things like ballistic calculations. I would think that they would be less prone to this type of problem.
With analog voltages/currents you have noise, with fixed size digital values* you have rounding errors. Both mean that you won't get an exact answer in most cases.
The big advantage of digital over analog is you can make the errors arbitrarily small. FAR smaller than you could reasonally acheive in an analog system.
The big disadvantage of digital is that rounding errors are less independent of each other than noise. Noise tends to cancel out in integration but rounding errors don't tend to cancel out anywhere near as well (consider the simple case of numeric integration of a straight line in fixed point for example: ALL the rounding errors would be in the same direction).
*This applies whether decimal or binary and whether fixed or floating point, it doesn't apply to things like bignums but there you have the problem that your numeric representation can end up arbiterally big.
I don't think you are correct about two numbers not being "nearly equal" when they are both close to zero, but with opposite signs. The function returns "true" in this case, no? Are you suggesting this is undesirable? I could see for some use cases that property might be undesirable, but if that's what you meant it wasn't clear. Certainly that property is desirable for some applications.
IMO this sort of thing is a good reason NOT to write a nearlyequals(a,b) function. That will just lull you into a false sense of security that the same rules are appropriate in every case.
You need to consider each case on it's own merits to decide what is meant by "nearly equals" in context.
In some cases that may be best defined in terms of absolute error, in some cases that may be best defined in terms of error relative to the value and in yet other cases it may be best defined in terms of the error relative to the current precision which is related to the value for larger numbers but becomes fixed for smaller (subnormal) numbers.
What you correctly identified is the impact of idiot consumers on product lines and marketing. People liked the cute 7" EEEs, but they lacked a few creature comforts so the masses complained.
Lets see it had a 7 inch screen in a case big enough for a 9 inch, WTF! The storage was also tiny.
It caught peoples attention by being the first in it's category (the ultraportable category was pretty dead at that stage, afaict the only real options were a refurb libretto or a VERY expensive sony) but in retrospect it was a pretty shitty machine.
Asus responded by creating shitty laptops that addressed these complaints.
After the 700 series came the 900 series, these were about the same size as the 700 series but fitted a bigger screen into that case and pushed up the storage. WIN
Then came the 1000 series where for an extra inch they squeezed in a proper hard drive and a bigger keyboard. The screen resoloution was a huge disappointment though (eventually I ended up getting a HP mini 5101 because of this issue).
Then came the 12 inch ones which I agree with you are stupid when you can get a machine with a proper C2D processor in 12 inch at a similar pricetag.
why can't they put a man-sized battery in a netbook and have it last 12+ hours ? I just want a machine that will get through an entire day without charging; a programmer's notepad so I can type and test my brilliant code snippets whenever and wherever they materialize.
Some ebayers were apparently selling 9-cell batteries for the mini 21xx series which may meet this requirement but I'd agree it's a niche the vendors seem to have missed out on.
I couldn't tolerate smaller screens due to the poor resolution
I had (and still have) a 13 inch macbook (which spends most of it's time running linux) but I wanted something a bit smaller and less valuable for use on the train but I really didn't want to sacrifice screen resolution.
In the end I got a HP mini 5101. The build quality seems reasonable (though only time will tell for sure), the screen resolution is as good as your aspire one and depending on your criteria could be considered better than my macbook (1366x768 has more pixels than 1280x800 but I'd still rather have the latter)
Not sure about the battery life, UK long distance trains generally have power sockets so battery life is a non-issue.
The overall size is about the same as an EEE 1000 and the keyboard feels as good as the one on my macbook (it really helps that HP have taken it extremely close to the case edge).
but I couldn't live with a screen any smaller than it has anyway.
Out of interest do you mean smaller in terms of pixel count, physical size of both?
I was REALLY disappointed when the EEE 1000 (10 inch) series came out and the screens were no higher resolution than the EEE 900 series (9 inch).
Add ram to that list too. Laptops in my experiance have at most 2 slots and the largest laptop sticks out there are 4GB (and even those have only become a viable option fairly recently).
On the desktop side many higher end boards have 4 or even 6 slots which with 4GB modules (afaict 4GB is the largest that most current desktop boards support) gives you 16GB or 24GB of ram. Workstation boards give you even more.
My experience with dells has been that if I look up the type on crucial and then buy that type of any decent brand they are fine.
I did once have a dell BSOD a lot after a memory upgrade but i'm fairly sure that was just a bad stick (another stick of the same make and model was fine as were sticks of the same make and model put in identical machines)
Though that forum thread looks very old (it talks about P3 machines), maybe things were worse years ago (all my experiance with upgrading memory in dells has been either P4 or core 2 stuff with either DDR or DDR2 ram).
Otherwise, it will just perform a word read, and if the pointer isn't aligned you get garbage.
Some but not all arm chips can be told to generate an exception in this case.
from http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/1228.html
ARM processors with full MMUs (e.g. ARM920T) support optional alignment checking where the processor will check every access to ensure it is correctly aligned. The MMU will raise a data abort if an incorrectly aligned access occurs.
Some ARM partners using simple cores such as the ARM7TDMI have implemented alignment-checking for their ASIC/ASSP. This can be done with an additional hardware block external to the ARM core, which monitors the access size and the least significant bits of the address bus for every data access. The ASIC/ASSP can be configured to raise the ABORT signal in the case of an unaligned access. ARM recommends that such logic is included on ASIC/ASSP devices where code will be ported from other architectures.
Linux can use these exceptions to fix up access if you desire (or you can set it up to generate a bus error signal to help in debugging)
from http://www.mjmwired.net/kernel/Documentation/arm/mem_alignment
15 Now for user space applications, it is possible to configure the alignment
16 trap to SIGBUS any code performing unaligned access (good for debugging bad
17 code), or even fixup the access by software like for kernel code. The later
18 mode isn't recommended for performance reasons (just think about the
19 floating point emulation that works about the same way). Fix your code
20 instead!
People have managed to get a little endian kernels running on hardware that was originally intended to run big endian (the linksys NSLU2) sbut my understanding is it was nontrivial (and it took them quite some time to get all the hardware to work with the little endian kernel)
Not really. Or rather, it used to be the case, but that shit had (mostly) already hit the fan back when x64 appeared.
Admittedly this is a desktop perspective but the impression I get is that only a small handful of windows apps are actually x64 (this contrasts sharply with linux where the norm is to run a system where almost everything is x64).
And even when an app adds x64 support they don't always make everything 64-bit. For example with hfss the simulation engine is 64-bit but the user interface/modelling tool is 32-bit.
Are things different over in server land?
And they ALMOST had 2K for alpha (they had it up to one of the release candidates but didn't take it through to a final release)
SP3 is supposed to upgrade to 7 or 8 (though I think if you're already at 7 it leaves it alone).
SP3 DOES NOT upgrade IE.
Afaict datacenters generally charge based on peak current anyway since much of the cost of datacenter electricity is actually in the infrastructure (generators, UPSs etc).
Performance per watt does matter to an extent but performance of individual threads also matters. The longer each individual request takes to deal with the more ram you need and the longer you keep any DB locks open for increasing the chance of lock contention there.
Another big problem with arm is that you can't rely on the presence of any particular floating point instructions. So you either compile everything for the specific FPU variant you have or you end up using softfloat
The problem is more the apps, windows itself could probably be ported without too much trouble but most windows apps are likely to have code that makes x86 specific assumptions and are closed source so only the vendors can fix them.
Emulation is an option but unless arm cores start performing a LOT better than intel cores of a similar power envelope that won't help much.
Therefore I don't think the "hotel guests don't want to use 3G cause it's expensive" argument holds that much water.
It doesn't apply to every guest but it will apply to a substantial subset of them. Especially in europe.
Every other country I've been to, phone providers normally cover the whole country.
However a lot of countries aren't all that big.
EU countries are often comparable in size to american states and there are usually no border controls between them yet when you cross that barely marked border (and I suspect possiblly before if you are unlucky about coverage) you are roaming internationally. The EU has put pressure on the operators to lower voice roaming rates but afaict data roaming is still sky high.