New-pipeline: Performance of fusion analysis
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 25/100
- Tipo de issue
- Error
- Claridad
- Bastante claro
- Estado de actividad
- Activo
- Stack tecnológico
- haskell
- Área
- performance
Línea de trabajo
Start by reading the new-pipeline fusion implementation and how it builds and solves the ILP with CBC; the issue does not name specific files or tests. Use the radixsort nofib test as the performance case, and compare solver options or approaches described here. Done means fusion performance is improved and the radixsort test is enabled again.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
In the new-pipeline, fusion uses an ILP (MIP) to find the best way to fuse the program. The ILP is solved using CBC. However, CBC is very slow on some programs. This includes the radixsort test in our nofib test suite. We should thus optimize fusion.
Possible solutions include:
- Switch to HiGHS (if HiGHS is faster than CBC on our ILP instances)
- Implement a custom constraint solver and optimize using domain knowledge (see https://github.com/ivogabe/accelerate/pull/31 for initial work in this direction)
- Settle with approximations from CBC: give CBC a timeout and let it return the best-known solution it found so far. Downside: solution becomes non-deterministic, and this fails if no solution was found before the timeout.
- Instruct CBC to use multiple cores. This does not give sufficient speedup, but would be a small quick win. CBC can run with multiple cores, but if I remember correctly, Haskell-MIP cannot parse the result as CBC prints a message that it is using multiple cores (should be easy to fix though).
- Disable in-place updates. This is not a real solution, since we really want to have in-place updates, but the ILP got a lot more complex due to the addition of in-place updates.
The radixsort test is temporarily disabled until this issue is fixed (See c6e328906f77affe2d6e9d6d1a64ba2542ada7d8). We should enable the test again when this issue is resolved.
- Lenguaje dominante
- Haskell
- Estrellas
- 1k
- Forks
- 138
- Métricas de merge de PR
- Sin PR fusionados en 30 d
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Tiene una plantilla de pull request
- Sin guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de AccelerateHS/accelerate
-
link in readme brokenAbierto
Dificultad 1/5 Menos de una hora Aptitud para principiantes 85/100
AccelerateHS/accelerate#429 · 1 comentario ·
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 25/100
AccelerateHS/accelerate#589 ·
-
bug frontend help wanted
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
AccelerateHS/accelerate#587 · 11 comentarios ·
-
Dificultad 4/5 1-2 días Aptitud para principiantes 42/100
AccelerateHS/accelerate#586 ·
-
New pipeline: atrace on PTXAbiertogood first issue
Dificultad 3/5 1-2 días Aptitud para principiantes 55/100
AccelerateHS/accelerate#582 ·
Todos los issues de AccelerateHS/accelerate
Issues similares
-
bug dependencies
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
alunduil/network-arbitrary#251 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
haskell/statistics#235 ·
-
Bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
-
pkg:crucible-mir type:bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100