On Oct 11, 2012, at 4:25 PM, Jonas Maebe wrote:
>
> 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
>>> f
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.
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
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 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
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
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 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
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
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 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
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
2012/10/10 :
> However when
> objects have methods, does that change memory alignment
No. As long as there are no virtual methods it will not affect the
size or the memory layout. From what I have read the new gtk3 API for
fpc will also use objects (with methods and also inheritance) instead
of r
Sven Barth wrote:
Am 10.10.2012 12:02, schrieb dhkblas...@zeelandnet.nl:
Does FPC ensure the same memory alignment for records and objects over
different platforms? If I want to be sure to have the same alignment
must I use packed (with possibly some aligning assigned) records instead
in combina
On 10.10.12 14:40, 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?
This highly depends on the architecture/processor.
Many architectures (like
On 10 Oct 2012, at 14:31, dhkblas...@zeelandnet.nl wrote:
Jonas and Sven... Endianess is indeed an issue I will be handling.
It's
my understanding now that by storing data in a packed record I will
have
the same behaviour (when it comes to aligning data in memory) over all
platforms and arc
On 10 okt '12, Jonas Maebe wrote:
> On 10 Oct 2012, at 12:02,
dhkblas...@zeelandnet.nl [1] wrote:
>
>> Does FPC ensure the same
memory alignment for records and objects
>> over different platforms?
>
> No, alignment is defined by the platform ABI.
>
>> If I want to be
sure to have the sa
On 10 okt '12, Sven Barth wrote:
> Am 10.10.2012 12:02, schrieb
dhkblas...@zeelandnet.nl: [1]
>
>> Does FPC ensure the same memory
alignment for records and objects over different platforms? If I want to
be sure to have the same alignment must I use packed (with possibly some
aligning assign
Am 10.10.2012 12:02, schrieb dhkblas...@zeelandnet.nl:
Does FPC ensure the same memory alignment for records and objects over
different platforms? If I want to be sure to have the same alignment
must I use packed (with possibly some aligning assigned) records instead
in combination with data type
On 10 Oct 2012, at 12:02, dhkblas...@zeelandnet.nl wrote:
Does FPC ensure the same memory alignment for records and objects
over different platforms?
No, alignment is defined by the platform ABI.
If I want to be sure to have the same
alignment must I use packed (with possibly some aligning
Does FPC ensure the same memory alignment for records and objects
over different platforms? If I want to be sure to have the same
alignment must I use packed (with possibly some aligning assigned)
records instead in combination with data types that are guaranteed to be
of the same size over the
21 matches
Mail list logo
