Deprecated features to remove

[tbennun]

Now that we are past version 1.0, what are some outdated features that you feel are hard to maintain, unused, and can be removed? This is an open discussion that is related to Issue #1767. One such unused deprecated feature is the TensorFlow frontend. The Octave frontend is similarly largely unused by the community, and was never more than an experimental frontend to begin with. '

Another topic is unused transformations, which we would like to move to a separate repository such as a transformation playground.

Any other ideas?

[tbennun]

Some transformations that are up for deprecation or moving out to a separate repo:

• Dataflow
  • BufferTiling
  • CopyToDevice
  • DeduplicateAccess
  • GPUTransformLocalStorage
  • MapDimShuffle
  • MapDistribution
  • {In,Out}MergeArrays (already exists as a pass)
  • MPITransform
  • OnTheFlyMapFusion
  • MapTilingWithOverlap
• Interstate
  • FPGATransformState
  • EndStateElimination
  • StartStateElimination
  • StateAssignElimination
• Subgraph
  • StencilTiling

Please complain if those are used by core dace.

[alexnick83]

I think StencilTiling is used by the auto-optimizer, but I do not know how often it matches without causing errors.

[philip-paul-mueller]

CopyToDevice is used by the code generator and can not be removed without changing the code generator itself.

[tbennun]

I don't see it being used: https://github.com/search?q=repo%3Aspcl%2Fdace%20CopyToDevice&type=code
I think you mean CopyToMap?

[philip-paul-mueller]

Yes, I mean that.
However, there are some issue with that transformation:

• The iteration order of them can not be set; It should be possible to externally trigger that, such that the maps can be processed.
• Sometimes I get compilation errors, because some symbols are not defined. I recently fixed such a bug but there are still some issues.

[tbennun]

Good point, but this is orthogonal to the discussion of whether we can remove CopyToDevice. Are there any objections to that?

[tim0s]

I fully agree with removing the Octave frontend - I think it serves no purpose and is not in line with where we want to go with dace. I am not so sure about TF (at least this is in line with where dace should go, on the other hand it might be better focusing on Pytorch). If I had to vote I would kill Octave now, and TF when DaCeML and DaCe are the same thing.
For the transformations, I think it would be good to discuss the policy first, i.e., which properties does a dace transformation need to have to be an officially supported one?

[tbennun]

I agree with all of your points.

The TensorFlow frontend is actually TensorFlow 1, which has been unsupported by the developers since ~2019. I think it has been superseded by TensorFlow 2 a while ago, and I think that now actually JAX is much more similar to TensorFlow 1. Since the frontend's target language has been End-Of-Life for so long we can likely remove it.

[romanc]

Maybe more of a tangential discussion: is DaCe following a particular versioning scheme? For example, in semantic versioning incompatible API changes (such a removing a frontend) are mapped to a major version change.

[tbennun]

Yes, as much as we can. None of these frontends and transformations are even marked yet as deprecated. This is for dace version 2