561 karma · joined February 22, 2019
If Chinese models are distilled from Fable, does it mean that security questions will be answered at most to a level equivalent to the Opus fallback? Meanwhile the ~150 companies with access to Mythos have greater security capabilities. Assuming the Chinese models are not distilling Mythos.
2. Technically, one could port the Julia compiler itself to WasmGC and get full REPL/eval semantics. However, App Store Guideline 2.5.2 states "Apps [...] nor may they download, install, or execute code which introduces or changes features or functionality of the app, including other apps.". It's not clear if this only applies to downloaded code or also local code (e.g. a playground app). If you attempt it, there is a good chance Apple will update their guidelines specifically to ban it. :P
Big if true. Does that mean we'll get a no-alloc iOS backend?
I looked into bit-slicing techniques, but they increase throughput at the cost of massive latency. This is not acceptable for realtime audio.
- Users cannot open their old projects unless they pay the subscription.
- Lower uptake in general, which affects viral adoption ("my friends use this software, so will I"). This is important if you rely on word-of-mouth instead of ad spend.
- Need to keep shipping features to justify the subscription cost. There is less focus on stability/maintenance.
Of course, compile-the-world is still going to be slow, but there is no solution for that in the C++/Rust ecosystems either.
Mojo folks (rightly) disagree.
To be more specific, you don't want Java-style-JIT. Julia JIT (which functions closer to AOT in this case) is fine for low latency.
These simulations are single core to avoid core-to-core latency. Number of cores isn't relevant unless you want to run independent voices/channels and sum them at the end.
So you start with a very optimistic ~90 GFLOPs of 64-bit FMA on Zen 4. Unfortunately, not all operations are clean multiply-adds. Realistically, you'll need trigonometric functions and LUTs, which are quite slower. Btw, the tradeoff between when to compute vs LUT is very fragile and can change due to a ton of factors (notably integrator algorithm).
Then the data you are operating on won't fit cleanly in AVX-512 registers, requiring spills to L1 cache. Ok, still fast on a modern core.
Of course, the peak theoretical number assumes clean vectorization with double-pumped AVX-512... which also won't happen in practice. Classical DSP will fare better (https://www.youtube.com/watch?v=Ssq0a-YdamM) but SPICE integrators are inherently branchy and divergent. Especially for adaptive integrators, you'll waste a lot of operations trying to "lock in" at the exact time point where the waveform turns a corner. Apple Silicon is better at this messy, branchy code.
So yeah, it's possible-but-hard to hit hard-realtime under these conditions.
We are here.
Yes, it can still produce value.
1. Your frontend needs to support emitting WASM. Ok for Rust, not for every language out there.
2. 2x-4x performance overhead.
1. It should run at FP64 if you want to preserve filter resonances, etc.
2. At 10x/100x fixed-rate oversampling, even a modern "fast" CPU will have very few cycles per (higher-rate) sample to run the DSP for 1 "module" of the software modular. Forget about interconnected modules, multiple tracks, or polyphony. For this kind of "analog"-style processing, it's better to run adaptive-rate algorithms (think SPICE) instead of wasting compute on unnecessary extra audio samples.
Or, in some cases, FP64.
> so i am very happy to see a high level language get that potential. besides go only common lisp has that ability that i am aware of.
Julia can do it.
If you need to extend it, you'll have to write custom Autodiff rules with the ergonomics of a Rust front-end and a JAX-like backend. :(
NVDA market cap is $4.7T.
The difference between a billion and a trillion is roughly a trillion.
Vulkan is mighty fine, but Julia just works for me.