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

Julia rewrite of libFastTransforms #205

Closed
jishnub opened this issue Mar 27, 2023 · 2 comments
Closed

Julia rewrite of libFastTransforms #205

jishnub opened this issue Mar 27, 2023 · 2 comments

Comments

@jishnub
Copy link
Member

jishnub commented Mar 27, 2023

This is a potentially long-term project (perhaps a GSOC), but currently there's some memory corruption occurring in this package, and it would be a good idea to port most of the core to Julia to fix such bugs quickly. In most cases, performance in Julia should be comparable to C, and memory safety and correctness are more important than performance.

@MikaelSlevinsky
Copy link
Member

I'm not sure this is the right approach. Transforms are, by definition, imperative tasks that should be written in a language with the best access to CPU optimizations (assembly, parallelism, etc...). Moreover, reimporting all methods in Julia would involve a nearly 20 s compilation (and increasing using time) of the package that is currently handled by the precompiled binaries. The best thing to do is the fix the memory corruption and issues as they arise and move forward with this framework.

To accelerate development within two languages, the package maintains the developer's "right to build from source." https://juliaapproximation.github.io/FastTransforms.jl/dev/dev/

@jishnub
Copy link
Member Author

jishnub commented Mar 27, 2023

I understand the concerns, however I don't necessarily agree with some of the points raised. E.g. SIMD and multithreading are easily accessible in Julia. In any case, I wonder if a different proposal is more acceptable: having Julia as an alternate backend?

My concern is that issues such as #175 have been open for a while, implying that the bar to fixing such bugs is rather high.

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