search

vallis / libstempo

libstempo — a Python wrapper for tempo2
MIT License
29 stars 33 forks source link

Compile on Apple Silicon arm processors #62

Open vhaasteren opened 9 months ago

vhaasteren commented 9 months ago

Recently it became possible to compile and run tempo2 on Apple M1/M2 processors with an arm architecture. This can be done by using the ./configure --enable-float128 option in the configure script. See here for more details on that.

libstempo cannot be compiled against that version of tempo2, because it then needs to be compiled with the gcc compiler (for the quad precision support), but it hard codes the 'long double' type of clang.

vallis commented 9 months ago

(I know I owe you lots of comments and replies... what can I say, I've been busy.) This would be nice if it worked, but I can't find documentation anywhere that __float128 is supported on arm64 on gcc. (I looked two years ago, and again now.) Are you sure you're not just getting a regular double?

vhaasteren commented 9 months ago

I am absolutely NOT sure, and I am happy you are questioning it. I simply supposed that the support for quad precision by GCC >=11 came through software emulation, and I kind of just trusted Mike Keith on his remark. I just looked at the docs as well, and I am still not sure.

vallis commented 9 months ago

Well, I just tried GCC 13.2 on my M1, and indeed libquadmath is available, so tempo2 would be able to use it (if --enable-float128 does what it claims). I haven't checked that computations are accurate. Nevertheless, surprising!

However, there remains a huge roadblock in that numpy does not recognize GCC __float128.

vhaasteren commented 9 months ago

Right. That is the same roadblock that PINT is running into. Scott mentioned that they are waiting with any solutions, hoping that someone else with the means and the money will solve that.

vallis commented 9 months ago

Yeah... Aaron and I spent some time trying to get PINT working with https://github.com/tuwien-cms/xprec, which is a numpy extension. Unfortunately PINT uses scipy which is tied to the standard long double internally. So no go.

I'm afraid the solution would be PINT using int + double (i.e., astropy Time) for all computations internally.

On the enterprise side, I want to decouple the package from both libstempo and PINT, but having an agnostic Pulsar object (I have already a prototype based on pyarrow) that can read par/tim if those libraries are present, but does not depend on them. So at least we can make Pulsar files on intel (or Rosetta) and distribute those.

vhaasteren commented 9 months ago

A lot there that is off-topic, so perhaps we should take those discussions elsewhere. A few references with context

Decoupling Enterprise from libstempo is high on many people's wishlist. Also being able to distribute Enterprise pulsars without pickles or timing packages is high on that list.

Regarding this remark: "So at least we can make Pulsar files on intel (or Rosetta) and distribute those." Aaron and I have refactored Ann's hdf5 pulsar code and made it in a separate package. Perhaps enterprise_extensions is a good home for it. It just requires a slight enterprise refactor, in this PR, which is ready for review. I have been using hdf5 to avoid the use of pickles. Updating Enterprise and still being able to use the same pulsar files is great.

I'd love to hear about the pyarrow prototype you have. Sounds like this is the time to deal with it. Perhaps we can streamline the design? Do you have an example to share?

Also, regarding the decoupling of Enterprise: I have an Enterprise MockPulsar class that holds simulated data. It can make the spin and astrometry timing models, so it's pretty realistic. With that, Enterprise is definitely usable without a timing package. But it needs convenience functions to fill the class of course, so I left it as a draft for now.

ps. PINT using astropy time objects in the back sounds like a painful change