> On 14 Dec 2015, at 12:07, Dimitris Chloupis <kilon.al...@gmail.com> wrote: > > 30% - 100% wow thats quite a speed boost, well done guys! > And 2GB images are more than welcomed , especially for me that I have to deal > with 3d data. > > Does that ThreadedFFIPlugin means we can now use C libraries that use > threading ?
not yet… but that is the path :) > > On Mon, Dec 14, 2015 at 1:01 PM Guillermo Polito <guillermopol...@gmail.com > <mailto:guillermopol...@gmail.com>> wrote: > Thanks! > > > On 14 dic 2015, at 11:32 a.m., Esteban Lorenzano <esteba...@gmail.com > > <mailto:esteba...@gmail.com>> wrote: > > > > > >> On 14 Dec 2015, at 11:24, Esteban Lorenzano <esteba...@gmail.com > >> <mailto:esteba...@gmail.com>> wrote: > >> > >> We will start migration to Spur today. > >> To complete it, we will require some time, specially to adapt the CI and > >> check everything is ok. > >> > >> Spur will allow us to do a big step forward in Pharo development, in the > >> concrete you will see it immediately for this: > >> - We have noticed a speed increment of 100% in tiny benchmarks (and > >> according to Eliot, it will be at least 35% in general on the system). > >> - No more GC stops (noticeable when running large systems) > >> - We will be able to scale our systems up to 2G memory consumption without > >> loosing performance. > >> > >> But, this will have some drawbacks in the first times: > >> > >> 1) VM will not be compatible between versions anymore: Pharo 5.0 will have > >> a Pharo Spur VM associated (and they are not compatible). > >> - There WILL NOT be a "non-spur" version of Pharo 5.0. Once completed > >> the transitions, this will be the only one. > >> > >> 2) NativeBoost-FFI implementation has been replaced with a new > >> implementation who relies in ThreadedFFIPlugin and IA32Plugin. While we > >> worked a lot to do this transition as painless as possible and we achieve > >> a good level of backward compatibility (most uses of #nbCall: should work > >> out of the box), there are some problems we cannot solve: > >> - there are some stuff not possible to compatibilise, notably: > >> - Structures now need to inherit from FFIExternalStructure > >> - Arrays now are now shadowed > >> - in general is a bit slower (impossible to compete with ASM) but in > >> general is not perceptible. > >> - THERE WILL BE BUGS AND NON-IMPLEMENTED FEATURES: Current > >> implementation is validated with Athens and even Roassal was working, but > >> of course that does not covers all cases. > >> 2.1) ASMJIT will be removed from system and put in a separated packages. > >> NOTE: There will be a blog post explaining FFI-NB architecture during the > >> week. > >> > >> 3) There are more or less 70 new failing tests, some of them important > >> than we need to fix as soon as possible. Please, please, please, help us > >> with them :) > >> > >> 4) In general we foresee the system will became unstable some weeks, > >> before it gets back to normal. Please be patient. > >> > >> 5) You will need to adapt your Pharo 5.0 related apps and CI processes (to > >> take care about new VM). Some programs will stop work at all (for example, > >> I think Pharo-launcher will need to be adapted). > >> > > > > ah, I forget it! > > > > 6) Some changes to the VM accumulated during the time of transition (some > > months now). So, some changes introduced there will not be present in new > > VM. I will merge this changes in the next weeks. > > > > cheers! > > Esteban > >
