I'll say it then...
I hope they know their AaaS from their elbows.
If you are a developer and you want to get a jump on the ARM server wave and port your applications from an x86 processor or another chip architecture – hey, the latter could happen – getting your hands on some of the nifty new server iron can be problematic. An ARM server is not exactly a volume product, and neither are …
I hope they know their AaaS from their elbows.
Give people the experience and get a jump on the process of migrating.
If this takes off I hope they have the ability to scale up.
The question is if you remove processor availability as a problem what other barriers exist to porting an application to a new environment.
There is also the IBM Virtual Loaner Program to let you port your software to Power Linux and AiX systems for free:
I don't know the current situation, but a few years ago Power would grind x86 into the dust, performance-wise. For software engineers, this is a real experience and eye-opener. Even if they will not sell their software or services on that platform.
And no, I am not an IBM $hill and I have been blasting them about their crappy DB/2 ODBC drivers in the past. I am happy to get rid of the Notes crapola at work. But I give credit where it is due.
"This node will be set up with Canonical's Ubuntu Server 12.10 by default, but you can also have it configured with Ubuntu Server 12.04 or Red Hat's Fedora 17."
They'll probably let you have one with RedSleeve, too, if you ask, considering we got it working with it nearly a year ago. Just in case you want some closer OS similarity with your x86 iron running an EL6 variant.
How bout a cluster of ARMs!
'This is Aaas'
is considered a good thing....
I'll get my coat....
... you are probably seriously fucked up already. Of course C was never designed to be highly portable, different platforms have different integer sizes, often not even powers of 2 and that's not hidden by the language, if your software depends on those things so much it cannot just be re-compiled from x86 to ARM you probably shouldn't be in the business of software development.
Seriously from the C standpoint x86 and ARM are essentially identical, both are 32 bit, both have the same endianes, the only thing that's different are the OP-codes, which is precisely what C hides from the programmer.
Of course if you are using any higher level language that should even hide more of the differences making porting even easier.
Porting isn't as easy as it sounds, have you ever done it? I guess not...
There are many subtle differences between ARM and x86, for example memory ordering, alignment, floating point accuracy, intrinsics etc etc. While ARM supports unaligned accesses, it doesn't on every load/store (eg. not on load/store multiple), so you can still encounter issues with badly written software which casts a char* to int* or double*. Incompetent programmers who do that should be taken out and shot but on x86 they get away with it. And this is not a C/C++ issue either, I see exactly the same thing in C# and other "high-level" languages despite all the bogus claims of being "type-safe".
Also if you rely on the results of the x87 FPU (which is not anywhere near IEEE compliant) you get different results when you run the code on an actual IEEE compliant FPU. If you use SSE and remember to configure all FP settings (like denormal flushing) identically you will still get different results for math functions.
Then there are source code bugs which happen to compile silently on one compiler but fail when you recompile for a different target. Many years ago I added a check to ensure all stack variables are always accessed within bounds. Reasonable, right? Guess what, it triggered too often when building Windows for ARM so I had to remove the check! And there are target-specific bugs you may have to work around... The list is endless, these are just a few of the issues I've encountered.
So yes, believe whatever you want, but porting millions of lines of code is a huge task, irrespectively of the language. Especially when originally written on x86.
There are legitimate reasons to cast char* to unsigned long long*, even when the char pointer is not aligned on 8 byte boundaries. x86 supports this nicely and if leadership tells me "we will only run on those cheap x86 machines", then I will use that feature. Because there are some use cases where I can speed up some rather critical stuff massively with that approach.
But yeah, as soon as the "x86 only" strategy is invalidated, you need to put that kind of stuff into #ifdefs and provide a portable alternative. No big deal, if you actually know what you do and you managers are not muppets.
The issue is not that unaligned accesses are bad, on the contrary, you can indeed improve performance that way - memcpy is a perfect example. The problem is lying about the alignment. All mainstream compilers support unaligned as an extension (__unaligned, __packed etc) to change the natural alignment of a type to 1. So if you want to explicitly do unaligned accesses or pack structures tightly, you can do so portably without causing crashes. On x86 it can be ignored in most cases (apart for SSE), and on other targets the compiler can choose the correct sequence. So you don't even need #ifdefs besides a simple macro in a portability header to add the unaligned attribute on a pointer.
The problem with the idea of "x86 only" is that can change in time, even if management claims it will never change.
Shit, I have problems porting from x86 to amd64... mainly due to management not being keen on changes that result in no visible change.
Well the differences between x86 and amd64 are actually significant. C does not abstract away different word sizes so your code will behave a lot differently.
Porting machines for ARM have been provided by Debian for over a decade, and a huge number of portability problems in upstream code has been fixed as a result. Get your code into Debian and cross-architecture issues should get fixed for you, although we do of course enormously appreciate people actually helping with that.
Things that catch x86-only code out are: char defaulting to unsigned, unaligned accesses wrapping, no FPU (on older hardware), different-sized enums, switchable endianness, and probably some other things I forgot. The exact set of issues has changed over the years as the ARM ABIs have devloped, and these days things look a lot more 'x86y' than they used to. as ARM comes out of the embedded work into 'binary distro' world where long-term ABI stability matters much more.
arm64 is even more standard-looking then ARM32 is these days. Hopefully some porter boxes for that will be along soon as building in models is super-slow.
Biting the hand that feeds IT © 1998–2018