Dear Mikael,
On 13/01/2019 18:26, Mikael Öhman wrote:
Hi all,
I told Kenneth that I would try to summarize alternatives;
https://gist.github.com/Micket/68153b209e29fc44bf0b85c7414e197d
I hope I haven't misrepresented anyones suggestion
This is a very nice summary, thanks a lot for puzzling
Hi all,
I told Kenneth that I would try to summarize alternatives;
https://gist.github.com/Micket/68153b209e29fc44bf0b85c7414e197d
I hope I haven't misrepresented anyones suggestion.
Best regards, Mikael
On Thu, Dec 27, 2018 at 12:06 PM Mikael Öhman wrote:
> @Paul Melis,
> Good question.
@Paul Melis,
Good question. I'll admit I actually filter-deps Mesa itself (we use the
system Mesa to get VirtualGL working). I just see the follow up effects,
all the packages that in turn depend on Mesa (and a couple other basic
softwares with Python bindings)
@Alan,
> I've also felt for some
On 20/12/2018 09:44, Alan O'Cais wrote:
Hi all,
We've been essentially doing what Mikael has suggested for a few years
at JSC. I see a lot of merit in how they deal with Python 2/3 at
ComputeCanada, having to currently choose one or the other at install
time creates unnecessary duplication
Hi all,
We've been essentially doing what Mikael has suggested for a few years at JSC.
I see a lot of merit in how they deal with Python 2/3 at ComputeCanada, having
to currently choose one or the other at install time creates unnecessary
duplication of a lot of software packages.
I've also
Hi,
On 12/15/18 02:43, Mikael Öhman wrote:
Yes, I know of these, but I disagree with this approach; I.M.O the
existance of this package would barely make any difference whatsoever,
as most things affected here, like Mesa, needs a runtime dep.
Slightly off-topic, but in what way does Mesa
@Bart
While I agree with basically everything you have said, I think there is
diminishing returns here. I'm not to concerned with an extra numpy, but
primarily with theentire dependency graph that gets pulled up to toolchain
level due to basic libpython
@Jack
It has been (and still is )in the
Howdy all,
It has been (and still is )in the works
https://github.com/easybuilders/easybuild-easyconfigs/pull/4962
https://github.com/easybuilders/easybuild-easyconfigs/pull/5072
Python-2.7.15-GCCcore-7.3.0-bare.eb was included in EB 3.7.1.
(meant as a builddependency only)
Its tricky.
Hey Åke, did you check the speed of intel vs gcc in python? I checked it some
months ago/last year, and there was no clear winner. Sometimes intel was a bit
faster, sometimes gcc was a bit faster. The only occasion where intel was
definitely faster was in trigonometrical and exponential
Whatever gets done, please make sure that the current method of having
Python at the intel/foss level is retained. There are too much python
code out there and we need the additional speed of using Intel compiler
for Python.
On 12/13/18 9:35 PM, Bart Oldeman wrote:
> Hi Mikael,
>
> you could
Hi Mikael,
you could actually go one step further and also compile OpenBLAS/LAPACK or
install MKL at GCCcore level. FZ Julich does something like that now:
https://apps.fz-juelich.de/jsc/llview/jureca_modules/Core/gcccoremkl/7.3.0-2019.0.117.xhtml
(they use a seperate SciPy-Stack module at the
Hi easybuilders,
We have for the 2018b toolchain been running with a shared libpython at
GCCcore level, which also let us more a lot of additional packages (e.g.
Qt) down to GCCcore level as well, significantly reducing the pointless
duplicated packages (primarily from the graphical stack).
12 matches
Mail list logo
