Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Compile on Apple Silicon arm processors #62

Open
vhaasteren opened this issue Dec 14, 2023 · 6 comments
Open

Compile on Apple Silicon arm processors #62

vhaasteren opened this issue Dec 14, 2023 · 6 comments

Comments

@vhaasteren
Copy link
Collaborator

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
Copy link
Owner

vallis commented Dec 14, 2023

(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
Copy link
Collaborator Author

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
Copy link
Owner

vallis commented Dec 14, 2023

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
Copy link
Collaborator Author

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
Copy link
Owner

vallis commented Dec 14, 2023

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
Copy link
Collaborator Author

vhaasteren commented Dec 15, 2023

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants