---
# System prepended metadata

title: '[DaCe] JaCe II'
tags: [cycle22]

---

# [DaCe] JaCe II

<!-- Add the tag for the current cycle number on top -->

- Shaped by: Philip
- Appetite (FTEs, weeks): full
- Developers: <!-- Filled in at the betting table unless someone is specifically required here -->

## Problem
In [cycle 21](https://hackmd.io/8rwD7rcpTpySRReNlVGJ8g) we started the productizion of the [Jax to DaCe prototype](https://github.com/philip-paul-mueller/jax_to_dace).
Currently, cooldown of cycle 21, the [initial PR](https://github.com/GridTools/jace/pull/3) is under review and should be merged by the end of the cooldown or soon after.
This PR only consists the bare minimum of functionality, such as
- manual translation, i.e. no decoration of functions,
- the translated result is not cached,
- no compossibility with other Jax functionality, i.e. apply `jax.grad` to a `jace.jit` annotated function.
- only arithmetic operations.

However, even in its current state the PR is already able to translate and run functions.

Most of these issues are addressed in a [development branch](https://github.com/philip-paul-mueller/jace/tree/initial_implementation_cont), albeit at a very basic level.


## Appetite
The whole cycle.


## Solution
In its current state, the most important goal should be to make JaCe work.
For this we should see problems under a kind of 80:20 rule, i.e. the code must not be super nice or perfect, but acceptable, such that an early ~~ducktape~~ usage is possible.
All other decisions should be seen and judged under these aspect.

Our top most priority is the completion of the initial PR.

Our second priority should be the merging of the development branch into `master`, which already addresses most of the missing features mentioned above, with the exception of the missing subtranslators.
For this we should focus on:
- Compossibility with Jax transformations.
- Decorators (is in tandem with the first point).
- Caching


The third priority should be the porting and implementing more subtranslators.
However, since they are small and isolated, they should be considered as a side project.


In cycle 21 we mentioned that we should aim to pass the [pyhpc benchmark suite](https://github.com/dionhaefner/pyhpc-benchmarks/tree/master) by the end of this cycle.
While it is possible to achieve it is not likely.
However, under the assumption that we are able to merge the development branch in this cycle, a suitable project for _next_ cycle could be passing this suite.     
This will also give us the opportunity to further optimize and "polish" the current 

Another interesting target would be a project once done by Felix Thaler, where he used Jax in a project with mixed success.
It would be interesting to see how JaCe perform on it.



## Rabbit holes
What is still something that is not yet fully decided is, how close JaCe should integrate into Jax.
An example for this question is the cache used to store the compiled functions.
It seems that Jax uses a global cache that is partially written in C++.
Eventually we will have to go to that route, but not now.

Furthermore, Jax has native support for multi device and multi node environments.
Which DaCe partially supports, but we ignore in the mean time.






## No-gos
<!-- Anything specifically excluded from the concept: functionality or use cases we intentionally aren’t covering to fit the ## appetite or make the problem tractable -->



## Progress
<!-- Don't fill during shaping. This area is for collecting TODOs during building. As first task during building add a preliminary list of coarse-grained tasks for the project and refine them with finer-grained items when it makes sense as you work on them. -->

- [ ] Merge the initial [PR](https://github.com/GridTools/jace/pull/3) (still under review).
- [ ] Finalizing the work on the current development branch.
- [ ] Start to port some of the subtranslators such that more elaborated tests can be done.

