Re: [cctbxbb] Allocators

Hello again, In light of the lack of responses, I am thinking it may be better for this to work in a branch (for cctbx and DIALS) and get to the point where we can demonstrate with a clear use case the performance improvement to try and avoid this being too abstract. As such I propose making branches in both cctbx and dials called something like “straw-man-eiger-performance” for this work to be explored, where we first get to the point where we have actually improved the performance then consider as a separate task back porting the changes to the main repositories. This will allow us to make the changes necessary without worrying at every step about possible repercussions for other platforms. Once we have demonstrated the benefits of the changes I would anticipate a review process where we discuss the best way to merge them back. I would like to keep this in the open - i.e. in a branch on the central repositories - so that people who are interested can track the work. Any objections? Many thanks Graeme

On 21 Sep 2018, at 14:02, [email protected] wrote:

Hello All,

In keeping with the spirit of

https://github.com/cctbx/cctbx_project/wiki/cctbx-contributors-guide

we would like to revisit the allocator work now Phenix 1.14 is out in the wild - however since we now know that this needs to be done we are interested in other points of view people have on ways to do this, and options people would like to have. It is important to note that we have no intention of changing the default behaviour, but we do want to be able to use customised allocators with flex arrays e.g. for handing out memory of well known and repeatedly used sizes (say, 16 M pixel double arrays) or allocate in specific areas for NUMA systems such as xeon phi.

We prototyped this a while back and stepped the changes back out again to enable the phenix release to proceed smoothly, so we have a pretty good idea of the sorts of things we would expect to do however will welcome input if you would like additional features.

As a baseline, we are talking as a parameter that PHENIX are no longer supporting CENTOS 5 32 bit (since ISTR this was a constraint before)

Any thoughts? Appreciate a number of folks will be travelling back after the PHENIX workshop.

Many thanks Graeme

-- This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail. Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message. Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom

_______________________________________________ cctbxbb mailing list [email protected] http://phenix-online.org/mailman/listinfo/cctbxbb