[Lognorm] [rsyslog] liblognorm

[David Lang]

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.

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
-------------- next part --------------
_______________________________________________
Lognorm mailing list
Lognorm at lists.adiscon.com
http://lists.adiscon.net/mailman/listinfo/lognorm