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

speed please!? #537

Open
sjaeckel opened this issue Oct 3, 2022 · 1 comment
Open

speed please!? #537

sjaeckel opened this issue Oct 3, 2022 · 1 comment

Comments

@sjaeckel
Copy link
Member

sjaeckel commented Oct 3, 2022

Creating this issue in order to pull the discussion regarding a mp_isone() macro out of #532

Following up on #532 (comment)

[...] It might be tempting to generalize it but since the size of a mp_digit is not fixed over different architectures it would get too complex.

I just thought about it a bit more and had a look into mp_cmp_d() and only then realized that #define mp_isone(a) ( ((a)->used == 1u) && ((a)->dp[0] == 1u) ) would falsely claim -1 as one ...

So I have some follow up questions:

  1. maybe it'd be a better idea to have an inline version of mp_cmp_d()?
    • does the function-call overhead really matter that much? I can imagine that it matters, but have no clue to what extent. Did someone measure this?
    • are there any other candidates that could/should be inlined?
    • how will we do that? We're still providing C89 support, so I guess we can't expect all those compilers being able to handle inline functions correctly.
  2. maybe it's time to think about starting to merge in tfm?
    • Which functions should we start with?
    • Which architectures?
@czurnieden
Copy link
Contributor

I just thought about it a bit more and had a look into mp_cmp_d() and only then realized that #define mp_isone(a) ( ((a)->used == 1u) && ((a)->dp[0] == 1u) ) would falsely claim -1 as one ...

Ah, that's why I have it as is_unity elsewhere (mainly in my JS version). Shouldn't have just renamed it without thinking. My bad, sorry!

#define mp_isunity(a) ( ((a)->used == 1u) && ((a)->dp[0] == 1u) )
#define mp_isone(a) ( (!mp_isneg(a)) && mp_isunity(a) ) 

/* Or together */
#define mp_isone(a)  ( ((a)->sign == MP_ZPOS) && ((a)->used == 1u) && ((a)->dp[0] == 1u) )

/* Generalizing it like this is better done with a full function (mp_cmp_d() in this case) */
#define mp_issmallnumber(a,b)  ( ((a)->sign == MP_ZPOS) && ((a)->used == 1u) && ((a)->dp[0] == b) )

does the function-call overhead really matter that much?

Testing for zero or a small integer happens quite often in loops where a function-overhead would multiply.
I am pretty sure that modern compilers would be able to handle it but we also support a lot of the older ones. We don't offer C89 support for nothing.
On the other hand: the people who use the older compilers tend to know what they are doing, so...

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