2026/04/02

Newest at the top

2026-04-02 21:30:23 +0200 <tomsmeding> in any case, the people hacking on accelerate are aware of all this, but there's little incentive in the academic system to spend the hours to fix it
2026-04-02 21:29:41 +0200 <tomsmeding> yeah
2026-04-02 21:29:36 +0200 <davean> and I don't mean that encuragingly.
2026-04-02 21:29:33 +0200merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-04-02 21:29:32 +0200 <tomsmeding> davean: and very old stuff is more likely to still work than the fancy thing from 2 years ago
2026-04-02 21:29:30 +0200 <davean> Ah yah if you're trying to hook it yourself instead of use the compiler which is what their spec actually is ... good luck!
2026-04-02 21:28:58 +0200 <tomsmeding> doing this (instead of writing the CUDA glue code in C) was probably a mistake, and one that is in the plans of being fixed
2026-04-02 21:28:40 +0200 <tomsmeding> if you try to bind CUDA functions from Haskell, you're more exposed to the function name shuffling they do under the hood
2026-04-02 21:28:39 +0200 <davean> (I recently found out, because someone got me to fix the compile on an ancient game project)
2026-04-02 21:28:13 +0200 <davean> There is something more
2026-04-02 21:28:08 +0200 <davean> Hum, so CUDA software I have from 2008 still works fine.
2026-04-02 21:27:40 +0200 <tomsmeding> the former seems to be fine so far
2026-04-02 21:27:31 +0200 <davean> I get hesitant every time I consider designing something that relies on accelerate for this reason :)
2026-04-02 21:27:18 +0200 <tomsmeding> Mostly depends on how backwards-compatible LLVM's IR format is, and how backwards-compatible CUDA turns out to be next year round
2026-04-02 21:26:46 +0200 <tomsmeding> I dunno!
2026-04-02 21:26:40 +0200 <tomsmeding> the CPU backend worked well enough for a long time already, by the way; it was the GPU backend that was unstable
2026-04-02 21:26:39 +0200 <davean> Sure, the problem is will it work in a year? :)
2026-04-02 21:26:22 +0200 <tomsmeding> well, I think it works well enough now for people to start testing it :)
2026-04-02 21:26:13 +0200 <tomsmeding> right
2026-04-02 21:26:02 +0200 <davean> the problem with that is it so often is broken no one can rely on it to start using it,.
2026-04-02 21:26:01 +0200alter2000(~alter2000@user/alter2000) alter2000
2026-04-02 21:25:48 +0200 <davean> tomsmeding: I kinda assume for accelerate you need a lot of users to actually start testing well because of the complexity of the stack you sit on top of.
2026-04-02 21:25:16 +0200 <davean> I was impacted a lot more by it just not having features.
2026-04-02 21:25:16 +0200 <tomsmeding> davean: I can say with certainty that accelerate's current testing regime is beneath your standards, but at least it's slightly better than it was a few years ago
2026-04-02 21:25:14 +0200tusko(~uwu@user/tusko) tusko
2026-04-02 21:25:01 +0200 <davean> Software was not good then, not at all, but its complexity vs. the effort put in was a bit more in balance.
2026-04-02 21:24:55 +0200tusko(~uwu@user/tusko) (Remote host closed the connection)
2026-04-02 21:24:27 +0200 <davean> I probably am impacted by more software bugs each month now than I dealt with in the entir 2000-2005 period.
2026-04-02 21:24:15 +0200alter2000(~alter2000@user/alter2000) (Ping timeout: 272 seconds)
2026-04-02 21:22:42 +0200 <EvanR> I blame the compiler in the driver
2026-04-02 21:21:33 +0200 <davean> Its a bit harder to test GPU compilers, esp since a lot of what you're debugging is the GPU stack
2026-04-02 21:20:21 +0200 <davean> But I know a lot of people who ship it when it runs at all and think its fine.
2026-04-02 21:20:19 +0200 <tomsmeding> EvanR: tangentially, turns out that "when it compiles it works" comes crashing down HARD once you do weird stuff with a GPU driver
2026-04-02 21:20:05 +0200 <davean> If we can agree on a reasonably extensive QA process I'm happy to only say known bugs.
2026-04-02 21:19:33 +0200 <tomsmeding> :p
2026-04-02 21:19:26 +0200 <davean> tomsmeding: They sure don't think so1
2026-04-02 21:19:18 +0200 <davean> I'd have said "known-buggy" even 15 years ago.
2026-04-02 21:19:15 +0200 <tomsmeding> davean: if you haven't made an effort to look, it's kinda known-buggy, isn't it?
2026-04-02 21:19:10 +0200 <EvanR> xD
2026-04-02 21:19:07 +0200 <EvanR> this tbh
2026-04-02 21:18:57 +0200 <tomsmeding> well it's haskell already, so what can go wrong
2026-04-02 21:18:57 +0200 <davean> tomsmeding: the problem with that is people aren't putting in the effort to look much lately.
2026-04-02 21:18:47 +0200 <EvanR> just don't make mistakes smh
2026-04-02 21:18:45 +0200merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds)
2026-04-02 21:18:37 +0200 <tomsmeding> davean: if you replace "buggy" with "known-buggy", then I can get on board
2026-04-02 21:17:12 +0200 <tomsmeding> (and I was the only one willing to do the work to make an actual release, so the known-buggy release indeed didn't happen)
2026-04-02 21:17:11 +0200 <davean> Its kinda a plauge of this era that people really are so sloppy with the software they release.
2026-04-02 21:16:58 +0200 <davean> Athas: People who release buggy software should be ashamed
2026-04-02 21:16:42 +0200 <tomsmeding> Athas: having the thing segfault when running a program with more than a few kernels is not something that I'd want to release on my name
2026-04-02 21:16:12 +0200 <Athas> I have heard that some released software has bugs, so maybe fixing them all is not necessary before tagging a release.