Using libjpeg on arm64

[chriskievit]

Hi, I'm trying to integrate PhotoScrollerNetwork into an application I'm writing. The demo works great but our targets include arm64 iPads. This means that using the jpeglib included in the build doesn't work. I read in previous issues that you were trying to build an updated version. Did you have any luck? Thanks in advance!

[dhoerl]

The problem is that libjpeg-turbo won't build now. I had a long discussion with the owner of that library, will append what he sent me. Two things to keep in mind:

• you don't really need arm64 - armv7 and armv7s will work just find on a new iPad or iPhone, just like a legacy app would. Now, I understand you'd much prefer 64 bit (as would I) but there isn't much I can do about it
• you could remove libjpeg-turbo, and use libjpeg directly. That will take some time and effort, and I don't know if libjpeg itself can be built in 64 bit. When I originally coded this project, my goal was to use the libjpeg APIs and not the turbo extensions, so in theory this is possible.
• what really sucks is that Apple has their own libjpeg embedded in the frameworks, but won't expose it (I've asked in a rdar, as have others).

What I got from DRC at libjpeg-turbo:

1: Can you give me some background on why you need ARM64? I'm not clear as to why iOS developers can't continue to ship 32-bit apps. Do those not work with the latest iPhone? If they do, then why would you want to ship a 64-bit app with slow JPEG rather than a 32-bit app with fast JPEG?

It's not a matter of funding at the moment. I didn't write any of the ARM code. Nokia wrote the 32-bit NEON code, and Linaro has been working on porting it to 64-bit. Currently, there is no ARM 64-bit hardware for them to test, so they're working entirely with a simulator. Thus, the implementation is currently incomplete -- it does not yet have the same feature coverage as the ARM 32-bit code. Also, we have no clue as to its performance. I am not comfortable supporting it as a feature until both of those issues are addressed, but I have no power to do anything about it, since I am not well versed in ARM assembly code. Funding-wise, it would probably be a lot easier to just convince a corporate organization like Linaro to fund my work than to go to the trouble of doing a Kickstarter campaign. Kickstarter is also kind of funny about what they will allow, and the nature of libjpeg-turbo might raise their ire.

You can follow the progress of the ARM 64-bit development here:
https://sourceforge.net/p/libjpeg-turbo/patches/54/

Also, I really don't understand your point about using libjpeg instead of libjpeg-turbo. Why would you ever have to do that? You can still use libjpeg-turbo to build an ARM64 binary. It just won't be SIMD-accelerated at the moment, so it will only be 25 or 30% faster than libjpeg rather than 2-4x faster.

2: gasassembler. Yes, the developers of gaspreprocessor are aware of the clang issue:

yuvi/gas-preprocessor#26

but also, I fixed the issue locally in our repository:

https://sourceforge.net/p/libjpeg-turbo/code/HEAD/tree/gas-preprocessor/

Again, the new BUILDING.txt describes the correct procedure and refers to our local URL instead of the external one. I suspect that gaspreprocessor needs to be further modified to support ARM64, which may be why it isn't building properly right now.

I am happy to include ARM64 code in my official universal binaries for OS X/iOS as soon as the ARM64 code will actually build under Xcode and as soon as someone such as you can give me performance numbers on it. I suspect that, at the moment, even if we were able to make the code build, it would not perform as well as the 32-bit ARMv7s code, because like I said, the ARM64 implementation is currently incomplete.

3: The LLVM and Apple developers are aware of the clang performance issue, but there has been no movement on it:

http://llvm.org/bugs/show_bug.cgi?id=16035

It's mostly likely due to the Huffman coding routines, because that's the only significant C code whose performance would depend on the compiler. The Huffman routines were optimized 6 years ago using a very painstaking trial-and-error process, and they seem to work well for GCC, Visual C++, and Sun Studio. Clang either isn't optimizing the code as well, or it is optimizing it differently, in such a way that the manual loop unrolling and other things I did to make the code perform faster on "traditional" compilers isn't working with Clang. Really nothing I can do about it until Apple or other players investigate the issue. I certainly do not have the time to go digging into compiler optimization code. I've got a ridiculous backlog of paying work right now that is not related to libjpeg-turbo.

[macteo]

This is the most compelling reason: Apple requiring arm64 slices for apps submitted in few months (February 2015).

https://developer.apple.com/news/?id=10202014a

[dhoerl]

Hey, if you think you can fix the libjpeg code, its open source! :-)

I recall that its possible to build the code with acceleration turned off, that would at least address the 64 bit issue temporarily. Also, DRC accepts funding - if here were to get a few thousand dollars from interested parties he would probably fix this himself.

[dhoerl]

I can build turbo with NEON disabled just fine for arm64 - I tried yesterday.

However, I'm actively working now to get NEON going for turbo - I posted on Apple forums yesterday and got guidance from Apple on how to modify the .S file to compile for clang.

I should have arm64 going by December for sure.

[dhoerl]

I now have a script that modifies the output of gas-preprocessor.pl so that clang will compile the file without error. However, now I need to come up with some scripts to work around the standard libjpeg-turbo configure scripts to get it to pick the proper file. Will take a week or so.

[dcommander]

libjpeg-turbo 1.4.0 now properly supports ARM64 and includes ARM64 architectures in all of the binaries installed by the DMG file:
http://sourceforge.net/projects/libjpeg-turbo/files/1.4.0/