Some notes on long longs and the statistic counters:
Daniele Gordini wrote:
> I wrote:
> > A: I don't like long longs.
>
> I am not experienced with them, but I am about to use them in a
> project I am involved in. I would like you to explain why in your
> opinion they are wrong, so I can think more accurately before
> actually using them.
If you _really_ need 64-bit arithmetic, use them. It's really handy
for higher intermediate results, for example (a+0ll)*b/c.
It's a pain in the ass to do 64-bit arithmetic in C without long
longs.
But, you should know the consequences...
The generated code is lengthy (2 to 20 times longer than normal).
Some operators are too complicated to be coded inline and are
performed by library calls (see libgcc.a). It looks like the
optimizer is sometimes unable to optimize the code generated by
64-bit arithmetic (or is bad at it).
But the worst thing is register usage. The x86 has very few registers
and 64-bit arithmetic requires a lot. So, gcc has to generate a
lot of code just to shuffle register contents. Nearly every 64-bit
operator has to flush all registers to the stack and restore them
later. And this makes a difference in execution time and memory
usage...
Next, long long operations are not atomic. If you need atomic oper-
ations you have to create locks and this makes them even slower.
And note: often atomic operations are required in performance critical
sections.
And last, I think long longs are very seldom required (as are floats).
Most things can be handled with 32-bit arithmetic (or fixed point
integer arithmetic instead of floats, which is btw the most time more
accurate). Use them with care, and you are right...
Conclusion: long longs and floats are the lazy programmers choice ;-)
> > B: On 64-bit CPUs a long long is 128 bit. That would be overkill.
>
> I thought a long long was 64 bit on any architecture the current
> implementation of gcc supports, but I could be wrong since I never
> verified that.
No, you are right. It seems, that gcc for alpha has 64-bit long longs.
I would call this a misfeature :-)
> Anyway I think sooner or later this issue must be addressed (for all
> counters, I mean): maybe when all systems Linux runs on will be 64
> bits...
On 64-bit CPUs the counters are no issue. But I wouldn't _upgrade_
the counters on 32-bit machines. It makes not much sense. As I
said earlier, there's no much information in the absolute value of
the most of the counters. You normally want to know, how many events
occurred in a specific (short) time slice.
To collect long term data, you better write a statistic package in
userland to monitor all the data and make some sense out of this mess
of numbers. This is even required if you want statistics covering
a reboot (unless someone demands, that the values in /proc are made
writeable, so that they may be set to a state saved during shutdown :-).
> BTW: just to avoid the risk of another flame war, this mail is sent
> directly to you and not to linux-kernel
:-) Maybe, I can make the shut up :-) I do not even know if the uptime
patch makes it to the kernel...
Ciao, ET.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html