6 ms·
Twenty years of my work with Arm architecture
- zgs 3y agoI wrote the boot loader for HP's StrongARM 1110 based calculator line. Sadly the ACO was shut down before it's release. Even though it was never released to the public a few escaped the labs and I've still got the dev kits they sent for boot loader work.
- russdill 3y agoIf you want to get some nostalgia, take a dive into blob. One of the old lart projects
- tobiasfuenke 3y agoIs it common to use ARM instances for web servers? There are huge cost savings
- 8organicbits 3y agoThe last time I looked I tried to deploy a python MVP on ARM but found that some of the dependencies weren't compatible. I'd take a hard look at your ecosystem and what sort of dependencies you're likely to need in the future before committing to ARM.
- 95014_refugee 3y agoSometime around 2010, I’d guess? It’s been a long time since this has been a meaningful issue…
- 8organicbits 3y ago2023. I forget the dependency, possibly something crypto related?
- repelsteeltje 3y agoCrypto and media codecs are in that area of incompatibilities. Occasionally run into Intel - AMD issues and even subtle generational mishaps every now and then. In cloud this is often related to hypervisor hiding architecture details (or plainly lying about them). Another source of trouble is python ecosystem fighting os packages. My recommendation would definitely include inspecting your dependencies. Also, be aware of python limitations: it's easy to develop, but but of a nightmare to deploy, maintain when targeting distinct platforms.
- jeffrallen 3y agoI do development of Odoo addons for a client on my ARM server, never really thought about it, just started working there because it was convenient and it just worked.
- AeroNotix 3y agoWhich ARM server would that be?
- jeffrallen 3y agoAn Oracle always free instance.
- dingi 3y agoThis was my observation as well. Python and Node still don't have perfect support on ARM (And no, this was not 10 years ago. Couple months ago tops). Not the core language/runtime but libraries. They still rely on native libs for some stuff. The platform I haven't experienced any issues at all was the JVM. Worked perfectly all the time. At least for my use cases (Web API services).
- iraqmtpizza 3y agoI pity the people still using glorified C. Java just works everywhere.
- 15155 3y agoFor the Rust, Go, and Ruby ecosystems it's very easy.
- jpgvm 3y agoAlso trivial on JVM.
- jeffrallen 3y agoJVM: "Write once, wait around for the damn thing to start up everywhere".
- weinzierl 3y agoWell, we have GraalVM now, which is "Write twice, wait a little less for the thing to start up on supported platforms."
- razakel 3y agoI find it amusing that Oracle uses GraalVM.
- dingi 3y agoI don't think that, a slightly increased startup time affects vast majority of software projects in any meaningful way.
- toast0 3y agoCloud provisioning takes so long, language runtime startup doesn't matter. :(
- fransje26 3y agoAnd I think C might work too.
- 3y ago
- ta988 3y agoMore and more yes.Anything that you have the source of or is compiled for it. Limitations are mostly for numerical computations that may lack some instructions or not be optimised as well as x86. For standard web/micro services they are great.
- el_benhameen 3y agoAll of our newer .net stuff runs on ARM instances. Solid cost savings and performance.
- lowbloodsugar 3y agoHaven’t run a JVM on x86 for years. My first ARM was 1988 tho, so I am biased =)
- ochrist 3y agoArchimedes?
- lowbloodsugar 3y agoA310 FTW
- aidos 3y agoAt least for us, we made the switch in preparation for the release of the M1 Mac machines. It took about a year for things to simplify - originally we had to use qemu for dependencies and had to hack and compile a few other bits along the way. We have more gnarly deps than your average web app though. Now the only thing we’re running on x86 is Sentry and I’ll stop self hosting that when I get a spare moment because it’s more of a beast to run than I like.
- stn_za 3y agoDefinitely more and more common, amazon's graviton instances and container support goes a long way here
- pjmlp 3y agoAny managed language, or anything on top of JVM, .NET, BEAM, should be quite easy, minus possible dependencies on native libraries.
- jeffrallen 3y ago> Also how to avoid those who deserve to be ignored. An important skill in Open Source, alas.
- hardware2win 3y agoThe Advantage of early adopters In the peak of hype they have years or decades of exp.
- mindentropy 3y agoIs adopting RISC-V now will provide an early adoption advantage in the future?
- rollcat 3y agoYes, provided it takes off like ARM does currently. On one hand the work being done on ARM right now is helping displace the x86-64 monoculture, on the other hand it might leave no niche for RISC-V to fill. Place your bets wisely.
- Narishma 3y agoI feel like RISC-V is already successful in low end niches.
- kryptiskt 3y agoRISC-V has the "no royalties to Arm Ltd" niche locked up at least.
- rollcat 3y agoTrue, but this is something that could be relatively easy for Arm Ltd to address in an endless number of possible ways, considering their already-dominant position, the perceived seriousness of the threat, etc. Just like Microsoft basically gave up on making the average Joe pay directly for a Windows license. Another question is, at what point do you expect RoI on your RISC-V expertise, even if it was basically guaranteed to take 20% of the global CPU market 10 years from now, you still need to ask yourself, what do you want to be doing until then. I'm barely old enough to remember when VLIW was still being hyped, and while RISC-V so far has a much better outlook commercially, it would be wise to remember that this market is ruthlessly competitive. Even companies as old and dominant as Intel must remain vigilant, for the old friend next door may eat their lunch and their dog.
- kjs3 3y agoThe first ARM I spent quality time was on a StrongARM SA1110 dev board. Interesting stuff, but very mobile focused and the toolchain left much to be desired. People do forget that ARM had pretty stiff competition from MIPS and to a slightly lesser extent SuperH at the time. There was a lot of innovation and a fun time to be mucking around. SA-1110 ended up not being a fit for what we wanted to do, and in the end I did other things, but worthwhile experience.