[Lognorm] [rsyslog] liblognorm

[Rainer Gerhards]

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.
>
>
> --
> Pavel Levshin
>
>
> _______________________________________________
> 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/a9d3e8c1/attachment.html>