Faster Zlib Performance On ARM Thanks To NEON

[phoronix]

Phoronix: Faster Zlib Performance On ARM Thanks To NEON

ARM developer Adenilson Cavalcanti has been working on optimizing the Zlib compression/decompression performance on ARM systems...

http://www.phoronix.com/scan.php?page=news_item&px=Faster-Zlib-ARM-NEON

[squash]

And here is the bug on zlib attempting to get these changes merged to the official zlib tree: https://github.com/madler/zlib/issues/346

[oibaf]

There are at least two other projects aimed at improving zlib speed:

https://github.com/Dead2/zlib-ng/commits/develop

https://github.com/cloudflare/zlib/commits/gcc.amd64

It's unfortunate however that classic zlib (still used by a lot of projects) hasn't merged such optimizations, as happened e.g. on libjpeg-turbo.

[busukxuan]

By making use of ARM's NEON instructions for SIMD

So what about ARMv8.2's new Scalable Vector Extension? How much hardware support is there for this new extension?

If chips like the Snapdragon 850 (CPUs derived from Cortex A-55 and A-75) accelerate anything with it, it could be helpful for ARM considering their "champion" Qualcomm is trying to get into the laptop market.

[Marc Guillot]

So what about ARMv8.2's new Scalable Vector Extension? How much hardware support is there for this new extension?

If chips like the Snapdragon 850 (CPUs derived from Cortex A-55 and A-75) accelerate anything with it, it could be helpful for ARM considering their "champion" Qualcomm is trying to get into the laptop market.

The Fujitsu Post-K supercomputer implements them. I wouldn't expect it for phone SOCs any time soon, although on new generations of Server cores, like the ThunderX2, or desktop intended cores, like the Snapdragon 1000, it could be another story.

[ldesnogu]

And here is the bug on zlib attempting to get these changes merged to the official zlib tree: https://github.com/madler/zlib/issues/346

That's so representative of what often happens: given the lack of wide availability of proper ARM development machines, everything takes a long time to get merged compared to x86.

[latalante]

That's so representative of what often happens: given the lack of wide availability of proper ARM development machines, everything takes a long time to get merged compared to x86.

It is identical with the x86_64 architecture.
https://github.com/madler/zlib/pull/292

Fortunately, they find a place in other leading projects.
https://chromium-review.googlesource.com/c/chromium/src/+/601694

[caligula]

Can't wait to have these on Raspbian / Rpi 3B+.

[brrrrttttt]

Can't wait to have these on Raspbian / Rpi 3B+.

Don't hold your breath, PRs have been dormant for months awaiting maintainer response.

[name99]

So what about ARMv8.2's new Scalable Vector Extension? How much hardware support is there for this new extension?

If chips like the Snapdragon 850 (CPUs derived from Cortex A-55 and A-75) accelerate anything with it, it could be helpful for ARM considering their "champion" Qualcomm is trying to get into the laptop market.

NO-ONE has shipped SVE hardware. The only *announced* HW is Fujitsu's chip (which is for supercomputing, not mass market, and only due in a few years).

Apple may surprise us all by including SVE in the A12, but right now it's very much the future, and targeting it makes no sense until NEON optimizations are in place.