The Futhark compiler can handle large arrays of monomorphic literals reasonably well (due to a specialised fast path). However, when the code generator constructs a C AST via language-c-quote and feeds it to the prettyprinter, it can take a pretty long time. I do not think language-c-quote is designed to handle array literals with that many elements. For a representative program submitted by @WilliamDue, the C backend takes 17s to generate the program, while the Python backend takes 1s - and that is including fairly naive (inefficient) prettyprinting.
I don't know if there is a quick way to hack up a fix, or if we should consider ditching language-c-quote and using a simpler representation for C. We don't need most of what it offers, and we particularly don't need its tracking of source locations (which I suspect is a major source of overhead).
The Futhark compiler can handle large arrays of monomorphic literals reasonably well (due to a specialised fast path). However, when the code generator constructs a C AST via
language-c-quote
and feeds it to the prettyprinter, it can take a pretty long time. I do not thinklanguage-c-quote
is designed to handle array literals with that many elements. For a representative program submitted by @WilliamDue, the C backend takes 17s to generate the program, while the Python backend takes 1s - and that is including fairly naive (inefficient) prettyprinting.I don't know if there is a quick way to hack up a fix, or if we should consider ditching
language-c-quote
and using a simpler representation for C. We don't need most of what it offers, and we particularly don't need its tracking of source locations (which I suspect is a major source of overhead).