I am struggling with minimizing my code size. While I was checking my code I found a ten kilobyte table here in core. First of all I am curious what's the goal of this table and how can I avoid it?
pub static POWER_OF_FIVE_128: [(u64, u64); N_POWERS_OF_FIVE] = [
(0xeef453d6923bd65a, 0x113faa2906a13b3f), // 5^-342
(0x9558b4661b6565f8, 0x4ac7ca59a424c507), // 5^-341
(0xbaaee17fa23ebf76, 0x5d79bcf00d2df649), // 5^-340
This sounded so unbelievable that I had to do some research.
core::num::dec2flt - Rust looks like it's a giant cache for converting decimal numbers to floating point ?
The table is used by float parsing, that is, turning "3.14" to 3.14. You can't avoid it as long as you are using std's implementation of float parsing.
yes it is some how caching
surprisingly, I am using core. Is there any solution to change float in rust?
Don't parse any floats?
Or, if you have to, use a naive multiply-and-add algorithm, which will be slow and subject to rounding errors, but fit in fewer bytes.
I don't know if it's possible to do an exact nearest-float parsing algorithm without at least this much table. If it is possible, it'll probably be a lot slower.
The problem is that in crates float may be used. I am looking for best solution.
What makes you think the best solution is not the one in
Maybe "10 kilobytes" sounds like a lot because it's all in one table. It's not a lot. Could you describe to someone who doesn't know what binary or exponents are, how to convert numbers in scientific notation into binary (without losing more precision than you have bits in the answer, even for extremely large and extremely tiny numbers) in under 2000 words, with no pictures?
the thing is when you're working on an embedded system with only 280kb flash size. 10 kilobyte is like 3% of your code excluding all other flt2dec codes. I also do not need any float number because the hardware doesn't even support hardware float calculation.
I thought wasm was bad. You deserve some type of award for Rust on stingiest environment.
If nothing uses floats, then this table shouldn't be linked into your final binary. Have you confirmed that this table is actually linked into your binary?
Have you enabled LTO and in case you run the linker yourself
--gc-sections (rustc does it by default on all platforms other than windows when it runs the linker)? Also have you traced back from the table to the (indirect) users to find out why it is preserved?
I feel your pain, but I don't think it is right solution for std to give up on Eisel-Lemire algorithm, which is considered state of the art for this problem.
At your level of size constraint, I think you should analyze call graph, including your dependencies, figure out what is calling float parsing, and either get rid of it if possible or patch it to call lightweight float parsing you write if necessary.