On 10 okt '12, dhkblas...@zeelandnet.nl wrote:
> One more
question, when using packed records, is there anything to say about
performance? Are there some tests anywhere that show how the performance
is impacted?
I did some performance tests on win32 and it appears that
both packed and unpack
On 11 Oct 2012, at 13:59, dhkblas...@zeelandnet.nl wrote:
I did some performance tests on win32 and it appears that
both packed and unpacked objects and records all show exactly the same
performance. Writing the individual variables in a record or object to
file takes about 5.5 times longer tha
In our previous episode, Nico Erfurth said:
> x86 can handle unaligned access, but most implementations (I think
> current atoms and via nano are an exception) will suffer a rather high
> performance penalty.
I thought most modern x86's only had a penalty when an unaligned
access crossed a cacheli
On 11 okt '12, Jonas Maebe wrote:
> As mentioned before, it not
only depends on the platform, but also on the contents of the
object/record. E.g., a badly misaligned double will generally give much
worse performance even on Intel.
>
>> This makes me wonder if
>>
choosing a proper value for
On 11 Oct 2012, at 15:00, dhkblas...@zeelandnet.nl wrote:
So misalignment of for instance a
double (or whatever type) will only happen if the record is packed and
the packed value is smaller than what the ABI prescribes, correct?
Yes.
Let's assume I set the record to packed 16bytes, this wo
In our previous episode, Jonas Maebe said:
> > reading and writing records as a whole safe on all platform/
> > architecture
> > combinations right? Apart from a few padding bytes, what are the
> > performance penalties of doing this then? Why would there be
> > penalties?
>
> The cpu cache wil
On 11 okt '12, Jonas Maebe wrote:
> On 11 Oct 2012, at 15:00,
dhkblas...@zeelandnet.nl [1]wrote:
>
>> So misalignment of for instance
a double (or whatever type) will only happen if the record is packed and
the packed value is smaller than what the ABI prescribes, correct?
>
>
Yes.
>
>> Le
On 11 Oct 2012, at 15:23, dhkblas...@zeelandnet.nl wrote:
Thanks, I think everything is clear now. My plan now is to
respect default padding and write records in one go to disk. The
padding
value will be written to the file header so the records can be read
back
one variable at a time when
Marco van de Voort wrote:
In our previous episode, Nico Erfurth said:
x86 can handle unaligned access, but most implementations (I think
current atoms and via nano are an exception) will suffer a rather high
performance penalty.
I thought most modern x86's only had a penalty when an unaligned
On 11 okt '12, Jonas Maebe wrote:
> On 11 Oct 2012, at 15:23,
dhkblas...@zeelandnet.nl [1] wrote:
>
>> Thanks, I think everything is
clear now. My plan now is to
>> respect default padding and write
records in one go to disk. The padding
>> value will be written to the
file header so the re
On 11 Oct 2012, at 16:11, dhkblas...@zeelandnet.nl wrote:
On 11 okt '12, Jonas Maebe wrote:
No. You really should write the fields one by one. Yes,
it's slower. That's the cost of portability. You can always
optimize by
first writing them to a buffer and then writing the buffer in one go.
11 matches
Mail list logo
