User: Password:
|
|
Subscribe / Log in / New account

Haley: We're doing an ARM64 OpenJDK port!

Haley: We're doing an ARM64 OpenJDK port!

Posted Oct 26, 2012 6:28 UTC (Fri) by imgx64 (guest, #78590)
In reply to: Haley: We're doing an ARM64 OpenJDK port! by aryonoco
Parent article: Haley: We're doing an ARM64 OpenJDK port!

> It's actually an extremely interesting design and much more of a clean break than AMD64 is compared to x86/IA32.

That's a bit worrying. I hope it doesn't end up as a second Itanium.


(Log in to post comments)

Haley: We're doing an ARM64 OpenJDK port!

Posted Oct 26, 2012 8:42 UTC (Fri) by khim (subscriber, #9252) [Link]

Itanic was doomed from the onset not because it had radically different 64-bit mode, but because it's 32-bit mode sucked (and still sucks: original one was so bad it was eventually just removed and emulation is still slow as hell). From what I'm seeing ARM does not plan to repeat that mistake.

Haley: We're doing an ARM64 OpenJDK port!

Posted Oct 26, 2012 9:12 UTC (Fri) by arnd (subscriber, #8866) [Link]

I work on ARM stuff, so you can call me biased, but I certainly don't expect it to end up that way. Itanium's fault wasn't that it diverged from the older 32 bit architecture, but that it did a lot of extravagant things that had not been tried before in mainstream computing and that turned out to be a bad design choice in hindsight.

64-bit ARM is by comparison the most boring architecture you can imagine, it takes the 32 bit design, and replaces most of the oddities of that architecture with more common ideas from other RISC designs. Nothing to see here really, and that's how we like it!

Haley: We're doing an ARM64 OpenJDK port!

Posted Oct 26, 2012 9:55 UTC (Fri) by nhippi (subscriber, #34640) [Link]

few differences:

1) During Itanium time, people still had lots of binary-only proprietary server applications, thus binary compatibility was much more needed. These days most server apps are in some kind of interpreted languages (java, php, python, ...). Also, many people will porting to Arm64 from mips, ppc, x86, etc, so break between a32 and a64 is not relevant to them.

2) While lack of proper backward compatibility was one reason of Itaniums demise, the other was just pure business failure. Itanium was just too expensive, Opteron and Xeon offered much better bang for buck. The whole idea was "Let's make people replace expensive UNIX RISC servers with expensive Itanium servers running UNIX". Customers were more like "Umm no thanks, let's rather replace them with cheap x86_64 servers running Linux". A lot will depend on what bang/buck and bang/watt a64 offers compared to competitors.

Haley: We're doing an ARM64 OpenJDK port!

Posted Oct 26, 2012 23:21 UTC (Fri) by aryonoco (guest, #55563) [Link]

A few things to note:

1) Though AArch64/ARM64 is not backwards compatible with AArch32, the chips that will be produced will themselves be running ARMv8, which does support running both Aarch32 and AArch64 code (without emulation or anything like that). They will run both codes just fine next to each other. This PDF from ARM is a good overview of ARMv8 http://goo.gl/2u8X2

2) Since people seem to be interested in ARM64 and what path its designers have taken, I highly recommend having a look at http://www.realworldtech.com/arm64/ The conclusion says: "Like x86, ARMv7 had a fair bit of cruft, and the architects took care to remove many of the byzantine aspects of the instruction set that were difficult to implement. The peculiar interrupt modes and banked registers are mostly gone. Predication and implicit shift operations have been dramatically curtailed. The load/store multiple instructions have also been eliminated, replaced with load/store pair. Collectively, these changes make AArch64 potentially more efficient than ARMv7 and easier to implement in modern process technology. "

3) As for Itanium, let's not forget that Itanium is a $4 billion business that's also highly profitable. Sure $4 billion might be peanuts for Intel and it certainly didn't live to the (very) high expectations that the industry had of it in late 90s, but many businesses would be perfectly happy with a $4 billion, profitable "side business".

Power and energy

Posted Oct 27, 2012 11:13 UTC (Sat) by man_ls (guest, #15091) [Link]

A lot will depend on what bang/buck and bang/watt a64 offers compared to competitors.
Also, the bang/watt·hour: while the power (watts) requirements may be the same, a processor may consume less while idle and thus eat up less energy (watts·hour) overall. Given their history, it would not be surprising if this was the sweet spot for ARM64: you don't need to run all processors at close to 100% all the time to save energy.

I am thinking about a service like Amazon EC2 which needs to have a reservoir of idle machines to handle traffic spikes (to be really elastic) and will have to eat up their energy costs while idle. Energy costs are nowadays the highest cost of running a server. Given that reserved instances may be half the price of on-demand instances, and that spot instances may be something like 5 times cheaper, I suppose that Amazon would be grateful to reduce costs. I can't wait to rent an AMD64 instance actually!


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds