I can replicate this, and it's awe-inspiring just how bad it is: Using HDF5: 0.07s Using the serializer: 6.3s
Robert, this was with `julia -p 2` (you won't see this if you don't have multiple processes). In a sense it's not a fair comparison: you're effectively creating a custom serializer when you're using HDF5, but not when you're using Julia's native serializer. If you used decompose_particles and rebuild_particles for the remote fetching, it would be sped up, too. Alternatively, you could create custom `serialize` and `deserialize` functions for a Particle, and you might get much better performance. However, I think there's more going on than this, but I've run out of time to dig deeper. One observation is that changing Particle to immutable helps a great deal. Andre, can you open an issue so this doesn't get lost? --Tim On Sunday, November 22, 2015 10:18:54 AM Robert Gates wrote: > what were your timings? > > i get: > > size(particles) = (300000,) > > size(particles) = (300000,) > > 0.060457 seconds (300.58 k allocations: 48.089 MB) > > (300000,) > > (300000,) > > 0.000057 seconds (27 allocations: 912 bytes) > > On Thursday, November 19, 2015 at 10:11:47 PM UTC+1, Andre Bieler wrote: > > I have an array (lets call it "data") containing composite types. > > something like > > > > type MyType > > > > x::Float64 > > y::Float64 > > > > end > > > > (basically just a collection of Floats and Ints..) > > > > > > Now sending this data to a worker by > > > > remotecall_fetch(iProc, someFunc, data) > > > > is about 100 times slower than the following > > 3-step procedure: > > > > a) decompose all composite types in "data" to arrays of Floats or Ints > > (all MyType.x go into one array of Floats, etc.) > > > > b) saving those arrays to disk with h5write() > > > > c) loading the variables from disk again with h5read(), > > re-build all the composite types and put it back into > > an array of MyTypes. > > > > > > I dont quite understand why this is the case / what I am missing here. > > I expected that writing and reading from disk would be orders of > > magnitudes > > slower. > > > > I am aware of shared arrays. If > > it turns out that it is not possible to send custom type data "fast" > > between > > procs, I ll implement shared arrays instead of my composite types. > > > > I attached an example script with timings for those who care. > > > > sending a RemoteRef to the worker and fetch it from there > > gives me the same timings as for the remotecall_fetch() attempt. > > > > > > Cheers, > > Andre
