>
> That is stupid because this is a POSIX application and will not
> work without POSIX stuff anyway.
I don't like use words like stupid, because some times it can change
the sense of the discussion. I agree with you that it is a POSIX application,
and you can be sure it is not going to be reduced to ISO compatibility. But
it is not the issue; I like more the ISO sizes because they are better
defined.
> The idea here is that “int” is faster than either “long” or
> “int32_t” – the former is for specific cases where int is not
> enough, and the latter will be forcibly 32-bit even if int is
> 64 bit on some machines where this is faster.
I thought you were talking about the waste of space due to 32/64 bits,
but you are now talking about speed. First at all, how do you know that int is
not going to be 64 bits? ILP64 or SILP64 uses int of 64 bits, and the speed
improvement you are going to gain is near to 0, because these variables are
only used a few of times, so they are not a bottle neck. The only reason why
I am going to accept change the type is because we can save a lot of memory
(well in my case is 3*4*239*73 = 204K). And, other question, how do you
know that using a int instead of a int32_t you are going to have a speed
improvement?, maybe the memory reduction makes your code commit less
cache fails, and your code begin to fly because you use int32_t instead
of int. Stop of guessing and do some test in your machine, and if
the results are good, then repeat the tests in other machine with
other architecture, and maybe we will begin to talk about this issue.
> using “int” here is probably the right thing to do.
I am sorry, but I don't agree with you in this point.
--
Roberto E. Vargas Caballero
Received on Thu Nov 14 2013 - 19:53:40 CET