Prev: image registration
Next: how to avoid NaN
From: ung on 29 Apr 2010 01:46 In some simulations, I know that a performance speed of function 'fread' for data type of 'double' is two times faster than for data type of 'single'. why is that?
From: us on 29 Apr 2010 02:31 "ung " <jangung(a)empal.com> wrote in message <hrb6es$j7n$1(a)fred.mathworks.com>... > In some simulations, I know that a performance speed of function 'fread' for data type of 'double' is two times faster than for data type of 'single'. > > why is that? hmmmmm... what happens if you replace SINGLE with a 1 and DOUBLE with a 2... us
From: Rune Allnor on 29 Apr 2010 03:04 On 29 apr, 07:46, "ung " <jang...(a)empal.com> wrote: > In some simulations, I know that a performance speed of function 'fread' for data type of 'double' is two times faster than for data type of 'single'. > > why is that? If that's correct (it sounds a bit suspicious) the likely cause is a combination of factors, that include sizes of data types, widths of data buses, and implementation overhead. First of all, the double precision (D) data type is twice as large, 64 bits, as the single presicion (S) data type, which is 32 bits. That smaller size of S is the reason why I think your claim is a bit suspicious, as half the amount of bits should translate more or less directly to half the time reading. However, the internals of the computer might be intended to work with 64-bit data batches. In that case, moving two S data items might be significantly slower than moving one D data item. The reason is that one needs to move each S item in a separate instruction, so you need two instructions instead of one, for the D data type, even if the amount of bits are the same. There is also the question of typecasting. Most computers work with D data types internally, e.g. inside FPUs, and need to convert back and forth between D and S data types. This conversion might take significant amounts of time, compared to simple shuffling of data. And last, there is the question of implementation efficiency. A lot of the details I have mentioned here can be optimized, e.g. like viewing two S type data items consecutive in memory as one 64-bit data package. While one might save some time moving one 64 bit package instead of two 32 bit packages, this method is far more tricky to implement, so most people don't do that. So all in all, reading data from files is a complicated issue. The more operations to perform, and more factors that need attention, the slower the speed. Rune
|
Pages: 1 Prev: image registration Next: how to avoid NaN |