Hi,
Here are some preliminary results of an experiment on energy consumption
measurement at Grid'5000
(https://www.grid5000.fr/w/Energy_consumption_monitoring_tutorial). The goal is
to have enough to be able to submit a serious comment to a recent article
published in Nature Astronomy (Zwart,
Yeah, I get it. llvmlite would only do composition, while TACO is doing fusion.
This is more promising!
Best regards,
Compl
> On 2020-11-25, at 17:17, Hameer Abbasi wrote:
>
>
> Hello,
>
> TACO consists of three things:
> An array API
> A scheduling language
> A language for describing
Great to know.
Skimmed through the project readme, so TACO currently generating C code as
intermediate language, if the purpose is about tensors, why not Numba's
llvmlite for it?
I'm aware that the scheduling code tend not to be array programs, and llvmlite
may have tailored too much to
I'm imagining a study on programmer and maintainer's time spent on a given
problem, tackled in different programming languages, maybe Python can be shown
to reduce GHG on the contrary.
It goes like this: Many human programmers/administrators/managers eat beef or
likes as they grow up, as
Hello,
TACO consists of three things:
An array API
A scheduling language
A language for describing sparse modes of the tensor
So it combines arrays with scheduling, and also sparse tensors for a lot of
different applications. It also includes an auto-scheduler. The code thus
generated is on par
Is there some community interest to develop fusion based high-performance array
programming? Something like
https://github.com/AccelerateHS/accelerate#an-embedded-language-for-accelerated-array-computations
This always seems like such a ridiculous argument. If CO2 emissions
are directly proportional to the time it takes for a program to run,
then there's no real need to concern ourselves with it. People already
have a direct reason to avoid programs that take a long time to run,
namely, that they
On 11/24/2020 2:06 PM, Charles R Harris wrote:
There are still ozone holes over the Antarctic, last time I looked they were
explained as due to an influx of cold air.
I believe industrial CFC usage, which has fallen since the Montreal Protocol,
is still considered the primary culprit in ozone
On Tue, Nov 24, 2020 at 12:28 PM Benjamin Root wrote:
> Digressing here, but the ozone hole over the antarctic was always going to
> take time to recover because of the approximately 50 year residence time of
> the CFCs in the upper atmosphere. Cold temperatures can actually speed up
> depletion
Digressing here, but the ozone hole over the antarctic was always going to
take time to recover because of the approximately 50 year residence time of
the CFCs in the upper atmosphere. Cold temperatures can actually speed up
depletion because of certain ice crystal formations that give a boost in
On Tue, Nov 24, 2020 at 11:54 AM Benjamin Root wrote:
>
> Given that AWS and Azure have both made commitments to have their data
> centers be carbon neutral, and given that electricity and heat production
> make up ~25% of GHG pollution, I find these sorts of
>
Given that AWS and Azure have both made commitments to have their data
centers be carbon neutral, and given that electricity and heat production
make up ~25% of GHG pollution, I find these sorts of
power-usage-analysis-for-the-sake-of-the-environment to be a bit
disingenuous. Especially since GHG
Measuring running time of a program in arbitrary programming language is
not an objective metric. Otherwise force everyone code in Assembler and we
would be done as quick as possible. Hire 5 people to come to the workplace
for 6 months to optimize it and we will be done with their transportation.
Hello,
We’re trying to do a part of this in the TACO team, and with a Python wrapper
in the form of PyData/Sparse. It will allow an abstract array/scheduling to
take place, but there are a bunch of constraints, the most important one being
that a C compiler cannot be required at runtime.
On Tue, 2020-11-24 at 18:41 +0100, Jerome Kieffer wrote:
> Hi Pierre,
>
> I agree with your point of view: the author wants to demonstrate C++
> and Fortran are better than Python... and environmentally speaking he
> has some evidences.
>
> We develop with Python, Cython, Numpy, and OpenCL and
Hi Pierre,
I agree with your point of view: the author wants to demonstrate C++
and Fortran are better than Python... and environmentally speaking he
has some evidences.
We develop with Python, Cython, Numpy, and OpenCL and what annoys me
most is the compilation time needed for the development
I think we, the community, does have to take it seriously. NumPy and the
rest of the ecosystem is trying to raise money to hire developers. This
sentiment, which is much wider than a single paper, is a prevalent
roadblock.
-- Andy
On Tue, Nov 24, 2020 at 11:12 AM Ilhan Polat wrote:
> Do we
On Tue, 2020-11-24 at 16:47 +0100, PIERRE AUGIER wrote:
> Hi,
>
> I recently took a bit of time to study the comment "The ecological
> impact of high-performance computing in astrophysics" published in
> Nature Astronomy (Zwart, 2020,
> https://www.nature.com/articles/s41550-020-1208-y,
>
Do we have to take it seriously to start with? Because, with absolutely no
offense meant, I am having significant difficulty doing so.
On Tue, Nov 24, 2020 at 4:58 PM PIERRE AUGIER <
pierre.aug...@univ-grenoble-alpes.fr> wrote:
> Hi,
>
> I recently took a bit of time to study the comment "The
19 matches
Mail list logo
