<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Nov 28, 2013 at 1:19 PM, David Lang <span dir="ltr"><<a href="mailto:david@lang.hm" target="_blank">david@lang.hm</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class=""><div class="h5">On Thu, 28 Nov 2013, Rainer Gerhards wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
On Thu, Nov 28, 2013 at 12:40 PM, Pavel Levshin <<a href="mailto:pavel@levshin.spb.ru" target="_blank">pavel@levshin.spb.ru</a>>wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
28.11.2013 15:19, Rainer Gerhards<br>
<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
For external interface, I'd vote for size_t.<br>
<br>
<br>
</blockquote>
Yeah, I know this problem for many years. I've been totally fine with<br>
size_t when we moved vom 16 to 32 bits. With 64 bits, I have a bit of<br>
concern as general use in cases like this. Thinking performance<br>
wise-manipulating 64 bits requires a lot of space in registers and cache<br>
lines. Especially when we know we will never have string that long (can you<br>
envision a 4GB syslog message that is run through lognorm -me not...). But<br>
I agree that the "clean" solution would is size_t --- I am undecided<br>
myself...<br>
<br>
Can you give me a good argument (besides standards) why size_t would be<br>
good here? Or better said: does not hurt.<br>
<br>
<br>
I can think only of going back to 16 and 8 bits. Sometimes, I'm working<br>
with microcontrollers, where int32_t is too big, and int16_t is standard<br>
int. This is not to say that I'll use liblognorm on these platforms.<br>
<br>
Nevertheless, strlen() and sizeof() are returning size_t. There is an<br>
implicit conversion anytime you are using different type.<br>
<br>
</blockquote>
<br>
Yup - I had *excpected* (not verified) that the optimizer just throws away<br>
the upper 32 bits.<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
64 bits do not use more registers on 64bit architecture (x86_64, namely),<br>
it is still just one register.<br>
<br>
</blockquote>
<br>
I am not sure about GCC, but I think I read that some compilers use the<br>
hardware split registers to store two 32 bit int's into a single 64Bit<br>
register, thus effectively freeing more registers. Again, not sure about<br>
gcc. A<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
As far as I understand, it is 8 byte long on stack, also, because<br>
registers are used for stack manipulation.<br>
<br>
</blockquote>
<br>
that would be a very convincing argument, as then it really doesn't matter<br>
at all (and even may be counter productive). On the other hand, this sounds<br>
like a bit of a waste performance wise.<br>
<br>
Rainer<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Therefore, this size does not matter as long as it is not used in<br>
heap/dynamic variables.<br>
</blockquote></blockquote>
<br></div></div>
performance wise, 64 bit variables are just as fast or faster to use on x86-64 than 32 bit variables. This is as long as they are aligned properly (things slow down if they are not aligned, but as I understand it, it's to the same speed as 32 bit access.<br>
<br>
In any case, this is a very small difference.<br></blockquote><div><br></div><div>Yeah, I agree here. But an important question is whether the stack always holds 64 bit values, even if the variable is 32 bits wide. Then it would turn down into a cache line questions, actually the same one we have for structs.<br>
<br></div><div>I have not found the exact specifics on what gcc does quickly enough, so I looked up Intels processor manual [1]. In section 7.3.1.5 it says:<br><br>====<br><br><div dir="ltr" style="font-size:10.64px;font-family:sans-serif">
Vol. 1 7-7</div><div dir="ltr" style="font-size:12px;font-family:sans-serif">PROGRAMMING WITH GENERAL-PURPOSE INSTRUCTIONS</div><div dir="ltr" style="font-size:14.64px;font-family:sans-serif">7.3.1.5 Stack Manipulation Instructions in 64-Bit Mode</div>
<div dir="ltr" style="font-size:12px;font-family:sans-serif">In 64-bit mode, the stack pointer size is 64 bits and cannot be overridden by an instruction prefix. In implicit stack references, address-size overrides are ignored. Pushes and pops of 32-bit values on the stack are not possible in 64-bit mode. 16-bit pushes and pops are supported by us ing the 66H operand-size prefix. PUSHA, PUSHAD, POPA,and POPAD are not supported.<br>
<br>====<br><br></div><div style="font-size:12px;font-family:sans-serif">So this boils down that indeed always 64 bit are pushed onto the stack (the compiler could optimize two 32 parameters into a single one, but that doesn't always work, looks a bit clumpsy and wouldn't apply in our case anyways...).<br>
<br></div><div style="font-size:12px;font-family:sans-serif">Bottom line: I am now convinced that size_t is a good fit.<br><br></div><div style="font-size:12px;font-family:sans-serif">T</div><br></div><br><br></div><div class="gmail_quote">
Rainer<br>[1] <a href="http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-manual-325462.pdf">http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-manual-325462.pdf</a><br>
<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
The advantage os using 32 bit values starts to show up when you are storing the data, more data fits in a single CPU cache line, etc.<span class=""><font color="#888888"><br>
<br>
David Lang</font></span><br>_______________________________________________<br>
Lognorm mailing list<br>
<a href="mailto:Lognorm@lists.adiscon.com">Lognorm@lists.adiscon.com</a><br>
<a href="http://lists.adiscon.net/mailman/listinfo/lognorm" target="_blank">http://lists.adiscon.net/mailman/listinfo/lognorm</a><br>
<br>_______________________________________________<br>
Lognorm mailing list<br>
<a href="mailto:Lognorm@lists.adiscon.com">Lognorm@lists.adiscon.com</a><br>
<a href="http://lists.adiscon.net/mailman/listinfo/lognorm" target="_blank">http://lists.adiscon.net/mailman/listinfo/lognorm</a><br>
<br></blockquote></div><br></div></div>