ASCIIHexDecode should be vectorized

[sambitdash]

The conversion is relatively simple. Hence, should be made a vector operation and not byte by byte read.

[wstaelens]

@sambitdash can you explain more how you can "vectorize" this to make it a vector operation?

[sambitdash]

The vector operation code generation is to be carried out by the compiler not human optimized as the code needs to be run on varied disparate processors. Most processors support vector operations like SIMD if the code does not have unnecessary branching. However, if you are look at the byte operation code it's full of branching. A sample code for this can be seen in the comment:

JuliaLang/julia#23267 (comment)

However, the generated code was not reviewed for potential further optimizations. Hope this explains what is needed.

Also note that you may not need error handling in stream operations but can repair errors as streams may have corrupt data. So error recovery may be desirable than exit on failure.

[sambitdash]

This may not be needed as PDF spec does not mandate the streams to have even number of hexits. It can also have control characters like CR-LF. So the branching may be significantly higher. Closing now.

[sambitdash]

Current implementation is about 60ms for a 10Mb stream on i7 processor.

Julia Version 0.6.2
Commit d386e40c17 (2017-12-13 18:08 UTC)
Platform Info:
  OS: Linux (x86_64-pc-linux-gnu)
  CPU: Intel(R) Core(TM) i7-6500U CPU @ 2.50GHz
  WORD_SIZE: 64
  BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Haswell)
  LAPACK: libopenblas64_
  LIBM: libopenlibm
  LLVM: libLLVM-3.9.1 (ORCJIT, skylake)