About rust lib #13
Comments
|
Sorry no good news. Unless someone shows up to lead this, it is unlikely to happen within 2024. Personally, I should have enough experience with Rust by ~2025 (I am actively gaining experience with Rust app with another project while 2024). |
|
@mario4tier Hello, I have extensive experience in Rust development. My idea is to wrap the TALIB library through Rust FFI. How can I contribute Rust code to talib? |
|
Sure. You are welcome to contribute with a PR. For FFI, ideally your change would be isolated into its own directory, therefore making it easier for others to review and merge "without worrying". As an alternative to FFI, consider that TA-Lib are fairly simple array processing functions. It would be great to tweak tool/gencode to make the source code compatible to native Rust (in same way that the existing code builds in Java, C, C++ and managed C++ after running through a C preprocessor). It is more work, but a more solid contribution that should reward you for the next 25 years 😄 If you can pull this off... you would likely become an admin for TA-Lib (can more freely merge and maintain it). One way or another, you are OK to proceed with your FFI solution (nobody else working on this approach right now). |
|
Chad (@chadfurman) is evaluating to generate native Rust. That would be ideal since it would eliminate all "C" tool dependencies for the Rust users... bringing us one step closer to generate a ta-lib-rs crate. Feel free to join the Native Rust effort or keep going with FFI as an alternative. |
|
Good news, hopefully we can all use secure rust code, I wrapped secure talib through ffi, which is time-consuming. |
|
Looking forward to talib computing performance built with native rust code. I'm optimistic about the future. I use any infrastructure in the trading broker data center for free, including servers and switches. talib continues to generate revenue for me as strategy core code on low-latency trading systems and low-latency hardware (exanic and x2522). I wrapped talib with ffi just because I was worried about my ability to optimize my C project. Tongda software also has a library similar to talib, using C language development, although the performance is better than talib, but the use of a large number of macros, which leads to later optimization difficulties, I dare not adopt. For now, talib is the only choice and the right one, offering high enough performance and good code optimization. Expect execution latency and performance from talib built with native rust code. |
|
@halohsu, Thanks for the feedback. Will be interesting to learn how Native Rust performance will compare to Rust/FFI/C. I do not dare to predict, may eventually need you to measure 😉 ** if you can share a few examples of your Rust API, it may inspire us to do the same. |
|
It's going to be fun to see whether "rewrite it in Rust" or "rewrite it in Zig" wins this race. :-) |
|
@mrjbq7, glad to see you 😄 I recently fix gen_code and ta_regtest (now works with Linux/autoconf), and doing some refactoring to reduce the "ugliness". @chadfurman is evaluating what needs to be done for Rust be generated in same way as done for Java.... so there is "hope" to have all the functions working at once. I estimate sometimes within 2025. The other priority is continuous integration and scripted release (did gain some github actions experience the last ~2 years)... that should help keep all TA-Lib variants "fresher". |
|
I like Mario's realistic, grounded approach and timeline estimates.
First target is _something_ in rust. Already doing some initial
experiments and expecting to dive deeper closer to EOY. I've been looking
into pyo3 vs cython a bit also. Looks like performance should be
comparable. Biggest costs are around rust's memory safety, but
optimizations exist.
Excited to see all the excitement here.
…On Wed, Nov 13, 2024, 17:28 Mario Fortier ***@***.***> wrote:
@mrjbq7 <https://github.com/mrjbq7>, glad to see you 😄
I recently fix gen_code and ta_regtest (now works with Linux/autoconf),
and doing some refactoring to reduce the "ugliness".
@chadfurman <https://github.com/chadfurman> is evaluating what needs to
be done for Rust be generated in same way as done for Java.... so there is
"hope" to have all the functions working at once. I estimate sometimes
within 2025.
The other priority is continuous integration and scripted release (did
gain some github actions experience the last ~2 years)... that should help
keep all TA-Lib variants "fresher".
—
Reply to this email directly, view it on GitHub
<#13 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAE3CITAGGJF3X4EMST2FHT2APHCFAVCNFSM6AAAAABP4PWVRKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINZUHE2TCOJXG4>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
Is the goal of Rust to use PyO3?
What would that add that the current Python bindings aren’t providing?
|
|
The goal is to get to rust with all current indicators and no loss of
functionality. I was mostly just curious about pyo3 and polars native rust
extensions are also interesting and I'm curious about that comparison as
well.
…On Wed, Nov 13, 2024, 18:43 John Benediktsson ***@***.***> wrote:
Is the goal of Rust to use PyO3?
What would that add that the current Python bindings aren’t providing?
—
Reply to this email directly, view it on GitHub
<#13 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAE3CIWB2LYBHV6TIYFMCGD2APPYTAVCNFSM6AAAAABP4PWVRKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINZVGA2DONJYGA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
It would be interesting if polars and rust bindings would provide any efficiency gain versus cython taking polars objects and passing backing memory to the C functions.
|
|
@mrjbq7 Just to also confirm, the primary goal is a Rust native "Core" library. Once we get that delivered, we can evaluate if/how it could be used as an "easier" dependency than the stumbling "C library" ( https://github.com/PyO3/maturin ? ) I do not desire stretching us into having multiple competing "high performance" python project. Instead, I feel an alternative installation procedure using only Pypi packages (with wheels) would be welcome by many... and this would ideally be done as part of the project/community you have built over the years. |
|
I agree.
And regarding wheels, I should probably just do it. I’ve resisted for
awhile to separate the Python wrapper from the underlying C library. But it
seems like the community needs it. Mostly for windows users that don’t seem
as easily supported by their package managers.
It just felt like a giant matrix of binaries to build and test and support,
but I know GitHub actions can help us with the most common ones.
Also, a related issue is some of the Python users apply the “small numbers”
patch to their TA-Lib C library to allow doing technical analysis on crypto
which sometimes has small prices. And I didn’t want to orphan them by
building with the upstream C library that didn’t have that patch applied.
|
OK, will prioritize including this as a "0.6.0" release by EOY, with updated autoconf (+github to build windows 64-bits binaries). This release will be more about learning what still works or not on various platform. |
|
@mrjbq7 Double checking that we are on the same page. The code in the TA-Lib repos already has that small numbers fix. What is missing is a new ".tar.gz" release. Correct? === On another subject, made a lot of progress on the Linux support. There is now a ta-lib-0.6.0-src.tar.gz "release candidate" in the directory "dist". Feel free to try, but do not change your installation instructions yet... (it will eventually be release as a Github binary asset). |
|
Yes, I don’t personally use the small number patch but that’s my understanding also. See for example this thread:
TA-Lib/ta-lib-python#157
If you need any help testing or docs or other things for new releases let me know!
|
About rust lib:
I had seen Contact mario4tier on github if interested.
i wonder the progression about it.
tks a lot
The text was updated successfully, but these errors were encountered: