[Lognorm] [rsyslog] liblognorm

[Rainer Gerhards]

On Thu, Nov 28, 2013 at 1:19 PM, David Lang <david at lang.hm> wrote:

> On Thu, 28 Nov 2013, Rainer Gerhards wrote:
>
>  On Thu, Nov 28, 2013 at 12:40 PM, Pavel Levshin <pavel at levshin.spb.ru
>> >wrote:
>>
>>   28.11.2013 15:19, Rainer Gerhards
>>>
>>>
>>>
>>>  For external interface, I'd vote for size_t.
>>>>
>>>>
>>>>   Yeah, I know this problem for many years. I've been totally fine with
>>> size_t when we moved vom 16 to 32 bits. With 64 bits, I have a bit of
>>> concern as general use in cases like this. Thinking performance
>>> wise-manipulating 64 bits requires a lot of space in registers and cache
>>> lines. Especially when we know we will never have string that long (can
>>> you
>>> envision a 4GB syslog message that is run through lognorm -me not...).
>>> But
>>> I agree that the "clean" solution would is size_t --- I am undecided
>>> myself...
>>>
>>>  Can you give me a good argument (besides standards) why size_t would be
>>> good here? Or better said: does not hurt.
>>>
>>>
>>> I can think only of going back to 16 and 8 bits. Sometimes, I'm working
>>> with microcontrollers, where int32_t is too big, and int16_t is standard
>>> int. This is not to say that I'll use liblognorm on these platforms.
>>>
>>> Nevertheless, strlen() and sizeof() are returning size_t. There is an
>>> implicit conversion anytime you are using different type.
>>>
>>>
>> Yup - I had *excpected* (not verified) that the optimizer just throws away
>> the upper 32 bits.
>>
>>
>>  64 bits do not use more registers on 64bit architecture (x86_64, namely),
>>> it is still just one register.
>>>
>>>
>> I am not sure about GCC, but I think I read that some compilers use the
>> hardware split registers to store two 32 bit int's into a single 64Bit
>> register, thus effectively freeing more registers. Again, not sure about
>> gcc. A
>>
>>
>>  As far as I understand, it is 8 byte long on stack, also, because
>>> registers are used for stack manipulation.
>>>
>>>
>> that would be a very convincing argument, as then it really doesn't matter
>> at all (and even may be counter productive). On the other hand, this
>> sounds
>> like a bit of a waste performance wise.
>>
>> Rainer
>>
>>
>>  Therefore, this size does not matter as long as it is not used in
>>> heap/dynamic variables.
>>>
>>
> 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.
>
> In any case, this is a very small difference.
>

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.

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:

====

Vol. 1 7-7
PROGRAMMING WITH GENERAL-PURPOSE INSTRUCTIONS
7.3.1.5 Stack Manipulation Instructions in 64-Bit Mode
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.

====

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...).

Bottom line: I am now convinced that size_t is a good fit.

T



Rainer
[1]
http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-manual-325462.pdf


> 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.
>
> David Lang
> _______________________________________________
> Lognorm mailing list
> Lognorm at lists.adiscon.com
> http://lists.adiscon.net/mailman/listinfo/lognorm
>
> _______________________________________________
> Lognorm mailing list
> Lognorm at lists.adiscon.com
> http://lists.adiscon.net/mailman/listinfo/lognorm
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.adiscon.net/pipermail/lognorm/attachments/20131128/10bd8d9d/attachment-0001.html>