LibreOffice Ported To 64-bit ARM (AArch64)

[Nille]

Why is it difficult to compile LibreOffice on a different arch?

No one say thats difficult. Only that no Builds exist.

[curaga]

BTW i'd be all over a light, nicely designed AArm64, Coreboot, Linux, feature full Foss GPU driver, HiDPI screen, 16gb ram, fast SSD, looooong baterry life laptop. Hope someone makes it.

I'll make it if you get me a few thousand prepaid preorders. Though I'd rather it have a normal-resolution screen and a large HDD (perhaps builtin flash for main OS in addition, to save power).

The cost and power requirements in 4k screens vs 1920x1080 are huge, for fairly little advantage. See the recent Intel discussion where such a screen cost ~four watts more than a standard-resolution one, both without FBC.

[89c51]

I'll make it if you get me a few thousand prepaid preorders. Though I'd rather it have a normal-resolution screen and a large HDD (perhaps builtin flash for main OS in addition, to save power).

Let's make a kickstarter/indiegogo project


As for the storage i prefer a 256GB (or more) pci-e ssd.

[caligula]

There are a few good foss gpu drivers, and more WILL happen as android moves towards board standards like uefi/acpi.
The built-in battery is much more about maximizing the size of the battery than profit...or at least you can make that argument as easily since samsung doesn't seem to charge less for their flagship phones than htc.
What do you mean "The hw requirements on my Android for calendar / email are much higher than on 64-bit desktop"? Even the highest end arm chip is about half as fast (per core) as four year old i7-2500K (completely ignoring the 32/64bit distinction as that's not too important for this purpose).

Don't get me wrong, but I don't follow your logic. Surely an app like email client has some fixed hardware requirements. What's the point in adding more and more bloat if the hardware is fast? Consider something like sylpheed or claws mail. I've used both. They have tons of features unlike the standard android email app, which is very minimal. These email clients (at least the statically built version) use only few megabytes of memory. Meanwhile Android email app uses tens or hundreds of megabytes. It's funny cause the Android app has much simpler gui toolkit, the VM is designed for low end hardware, it has much less features. It's like 90% less features, 900% more size. Very bad tradeoff.

When it comes to CPU perf comparisons, I don't think i5-2500K (2500k is i5, 2600k is i7) is only twice as fast as ARM chips per core. 2500k goes up to 3.7 GHz, many high end ARM cores are 1.6 - 2.0 GHz. When you run traditional single threaded code, x86 has better branch predictors etc. When you need power, it has 256bit AVX. It also has faster buses and memory controllers. You can't really compare apples and oranges.

[liam]

Don't get me wrong, but I don't follow your logic.

Hey, no problem. I appreciate you being polite (something that's really been bugging me lately on this board).

Surely an app like email client has some fixed hardware requirements.

Not necessarily. It completely depends on what it does. For one thing, there's a world of difference between Mutt and Outlook and Gmail (web). If you specify what features the client has, then you can pin down minimum reqs (at least if you assume the use of libraries rather than an all-in-one blob which could be more efficient but requires a rewrite of much common functionality).

What's the point in adding more and more bloat if the hardware is fast?

There's never a good reason to add bloat. However, I don't think the additions made are necessarily considered bloat.

Consider something like sylpheed or claws mail. I've used both. They have tons of features unlike the standard android email app, which is very minimal. These email clients (at least the statically built version) use only few megabytes of memory. Meanwhile Android email app uses tens or hundreds of megabytes. It's funny cause the Android app has much simpler gui toolkit, the VM is designed for low end hardware, it has much less features. It's like 90% less features, 900% more size. Very bad tradeoff.

Some of it is that gmail is spending some space on a nice UX (the android toolkit isn't simple, especially compared to gtk). Other is spent on significant caching (since the disk is quite slow). The app itself is arounf 14MB. Not as small as it could be, but small enough for modern devices with .5GB, or more ram.

When it comes to CPU perf comparisons, I don't think i5-2500K (2500k is i5, 2600k is i7) is only twice as fast as ARM chips per core. 2500k goes up to 3.7 GHz, many high end ARM cores are 1.6 - 2.0 GHz. When you run traditional single threaded code, x86 has better branch predictors etc. When you need power, it has 256bit AVX. It also has faster buses and memory controllers. You can't really compare apples and oranges.

I'm referring to geekbench 3. They set the baseline at 2500 (which corresponds to the aforementioned core i7). The apple cyclone core, running at 1.3GHz (iirc) get about half the score of the i7. The upcoming apple a8 suppoedly runs at 2GHz, so the gap should close considerably.
Regarding branch predictors, that is an area that was hugely improved in the most modern arm cores (a17/53/57). It's difficult to say how it compares to intel but my looking at benchmarks arm has done a magnificent job with far fewer resources.
NEON is a the simd alternative for arm has 32 64bit (128bit for aarch64) registers while haswell's registers are currently 256bit but no idea how many they have. NEON has also had good support for integers for a long while (still doesn't have gather, though). The numbers I found were: haswell 32 sp flops vs a15 8 sp flops (probably doubled for aarch64).
The new bus krait design on snapdragon 805 actually has a very wide and fast memory bus (2x64bit at 1600MHz, so as fast as haswell). Memory controllers have been a big weakness, but have gotten hugely better starting with the cortex a9.

[Fito]

How about they work on polishing the entire suite and gut out the remaining Java?

Perhaps, focus more on OpenCL to work towards an HSA enabled solution?

You don't get to establish on what the developers of an open source project should work on, unless you're paying them. This also applies to the volunteers, who work on whatever LibreOffice component they please. They do not (and should not) obide the wishes of a naysayer on a random Internet forum. Sorry to disappoint you.

The defaults for the color picker seem to be designed by someone on LSD 24/7. The choice of presets for colors are moronic.

The only moron here is you, judging by your post history on this forum. And FYI, work has already started on replacing the legacy color picker and default palette.

Really? We have to wait until 4.4 to get something that should have been in 0.1?

You're going to wait less than five months. I don't think that's such a huge problem, unless you're going to die before that.
Also, the first LibreOffice version was numbered 3.3. We've never released a 0.1 version.

Seriously? What's next? Linux will require an OpenGL 4.x mininimum GPU to run it?

I don't see that as a problem, since OS X native apps have been 64-bit-only for a long time.