BadInformatics

I think it's more complicated than that. The projects that are getting the funding are usually the hard, technical ones, but that funding also supports better docs + more time for API design. This doesn't apply to bleeding edge stuff, but look back through the core SciML libraries and there's no shortage of effort directed towards "dull" stuff like docs + improving compile times. Likewise for the core language: a lot of recent work is bread and butter engineering like (again) improving compile times, filing rough edges off of APIs and (gradually) tackling the deployment story.

Now, one area where this dull problem work isn't as noticeable is on the "core" deep learning libraries (Flux and Zygote). AFAICT those two haven't received any significant funding for a couple of years, and there is at most 1 full time, active contributor for both of them. Compare with JAX or even higher-level wrapper libraries like Flax, Haiku or PyTorch Lightning, which have 5-10+ full time core devs. Given this, is it surprising that progress on anything (including docs + interface design) is slow?

You're in luck, because (assuming the scans are in a compatible format), this is exactly what 3D Slicer was designed for.

Who is doing more than a couple rounds of interviews outside of (pardon the scare quotes) "tech companies"? Has anyone run into, say, a bank pulling 4+ rounds of interviews, or is this limited to FAANG(M), SV companies and startups that seek to emulate them?

It does not, and any discussion of whether certain public health measures should've been implemented should take that into consideration. Toronto-area hospitals were literally sending ICU patients to smaller cities because their own wards were overflowing. Moreover, attrition rates among clinicians (nurses especially) has been atrocious over the past year or so. People are only willing to put up with so much shit for so long, and most provincial systems have zero slack at the moment.

That said, measures like GP described were/are in play in many cities. Seniors time was a fixture in the first few months of the pandemic, especially in smaller areas that did not experience a large caseload.

That's another point too: I think a lot of HN commenters are unaware of just how fragmented and regional the Canadian healthcare system is. No two provinces implemented the same restrictions or policies at the same time, and only a couple put in strict stay-at-home style lockdowns. Note how the article mentions large increases in both Ontario (lax policies, then sudden strict lockdowns) with Alberta (very few restrictions). Even in Ontario, walking outside the biggest few cities would result in an immediate drop of most of the strict measures present in, say, the GTA. I know it's hard to capture this nuance discussing with strangers on some random online forum, but it's essential if we are to properly discuss cause and effect.

Vancouver may have "no industry" relative to SV, but it is a veritable black hole for tech on the west coast of Canada. The same rat race of high-skilled, well-paying jobs only being available in HCoL cities is just as much of an issue north of the border. The even smaller gap between compensation and CoL in Vancouver, Toronto, etc. just serves to make things more miserable.

Saying all the underdog competitors should team up is a nice idea, but as anyone who has seen how the standards sausage is made (or, indeed, has tried something similar) will tell you, it is often more difficult than everyone going their own way. It might be unintuitive, but coordination is hard even when you're not jockeying for position with your collaborators. This is why I mentioned the silver bullet part: a surface level analysis leads one to believe collaboration is the optimal path, but that starts to show cracks real quickly once one starts actually digging into the details.

To end things on a somewhat brighter note, there will be no sea change unless people put in the time and effort to get stuff like Vulkan compute working. As-is, most ML people (somewhat rightfully) expect accelerator support to be handed to them on a silver platter. That's fine, but I'd argue by doing so we lose the right to complain about big libraries and hardware vendors doing what's best for their own interests instead of for the ecosystem as a whole.

> Do you think AMD should solve every problem CUDA solves for their customers too?

They had no choice. Getting a bunch of HPC people to completely rewrite their code for a different API is a tough pill to swallow when you're trying to win supercomputer contracts. Would they have preferred to spend development resources elsewhere? Probably, they've even got their own standards and SDKs from days past.

> everyone else using GPU's is running fast as they can towards Vulkan

I'm not qualified to comment on the entirety of it, but I can say that basically no claim in this statement is true:

1. Not everyone doing compute is using GPUs. Companies are increasingly designing and releasing their own custom hardware (TPUs, IPUs, NPUs, etc.)

2. Not everyone using GPUs is cares about Vulkan. Certainly many folks doing graphics stuff don't, and DirectX is as healthy as ever. There have been bits and pieces of work around Vulkan compute for mobile ML model deployment, but it's a tiny niche and doesn't involve discrete GPUs at all.

> Is it just too soon too early in the adoption curve

Yes. Vulkan compute is still missing many of the niceties of more developed compute APIs. Tooling is one big part of that: writing shaders using GLSL is a pretty big step down from using whatever language you were using before (C++, Fortran, Python, etc).

> do ya'll think there are more serious obstructions long term to building a more Vulkan centric AI/ML toolkit

You could probably write a whole page about this, but TL;DR yes. It would take at least as much effort as AMD and Intel put into their respective compute stacks to get Vulkan ML anywhere near ready for prime time. You need to have inference, training, cross-device communication, headless GPU usage, reasonably wide compatibility, not garbage performance, framework integration, passable tooling and more.

Sure these are all feasible, but who has the incentive to put in the time to do it? The big 3 vendors have their supercomputer contracts already, so all they need to do is keep maintaining their 1st-party compute stacks. Interop also requires going through Khronos, which is its own political quagmire when it comes to standardization. Nvidia already managed to obstruct OpenCL into obscurity, why would they do anything different here? Downstream libraries have also poured untold millions into existing compute stacks, OR rely on the vendors to implement that functionality for them. This is before we even get into custom hardware like TPUs that don't behave like a GPU at all.

So in short, there is little inevitable about this at all. The reason people may have been frustrated by your comment is because Vulkan compute comes up all the time as some silver bullet that will save us from the walled gardens of CUDA and co (especially for ML, arguably the most complex and expensive subdomain of them all). We'd all like it to come true, but until all of the aforementioned points are addressed this will remain primarily in pipe dream territory.