You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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.
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.
The text was updated successfully, but these errors were encountered: