meisel

The graphs aren't showing up for me on the site unless I click on them

No it’s not? Her Wikipedia page says “Hedy”

For a language that’s so low level and performance focused, I’m surprised that it has those extra io and allocator arguments to functions. Isn’t that creating code bloat and runtime overhead?

The real optimization here is to move off UIKit and interact with the GPU more directly

In my experience, C++ is a much more complicated language. The 8 ways to initialize something, the 5 types of values (xvalues etc.), inconsistent formatting conventions, inconsistent naming conventions, the rule of 5, exceptions, always remembering to check `this != other` when doing a move assignment operator, perfect forwarding, SFINAE, workarounds for not having a great equivalent to traits, etc. . Part of knowing the language is also knowing the conventions on top that are necessary in order to write it more safely and faster (if your move constructor is not noexcept it'll cause copies to occur when growing a vector of that object), and learning the many non-ideal competing ways that people do things, like error handling.

Would it help a lot to run it through multiple different AI systems and verify that they agree on the result?

Is there a target use case(s) for this language, at least initially? It seems to focus on programming in a platform-independent sense, but where is it most likely to actually succeed? Are there particular OS’s or other languages that they try be particularly compatible with?

How does Flix decide if it’s worth it to auto parallelize a map operation? Eg, if it’s a very trivial map operation, it may add overhead to parallelize it

Yeah, and his behavior in this LLVM discourse thread made me not want to ever try Zig: https://discourse.llvm.org/t/rfc-libc-taking-a-dependency-on...

Another speed up method here would be using simd, although it would be interesting to see in the assembly if it was auto-vectorized already.

This reminds me of a trick to sort floats faster, even if they have negatives, nans, and inf: map each float to a sortable int version of itself where one can compare them as ints (the precise mapping depending on how you want to order stuff like Nan). The one time conversion is fast and will pay off for the lg(n) comparisons. Then after sorting, map them back.

Yes, that's the one I was thinking of, thank you

I knew that name looked familiar, I thought about mentioning tpde here :)

That's interesting to hear that IR is missing a lot. I'm also surprised that it could provide much gain over hashing the preprocessed output - maybe my workflow is different from others, but typically a change to the preprocessed output implies a change to the IR (e.g., it's a functional change and not just a variable name change or something). Otherwise, why would I recompile it?

Parse caching does sound interesting. Also, a lot of stuff that makes its way into the preprocessed output doesn't end up getting used (perhaps related to the 40-50% figure you gave). Lazy parsing could be helpful - just search for structural chars, to determine entity start/stop ranges, and add the names to a set, then do parsing lazily

Very interesting stuff. However, for my day-to-day work, I'm in a large C++ code base where most of the code has to be in headers due to templating. The bottlenecks are, very roughly:

- Header parsing (40% of time)

- Template instantiation (40% of time)

- Backend (20% of time)

For my use case, it seems like this cache would only kick in when 80% of the work has already been done. Ccache, on the other hand, doesn't require any of that work to be done. On a sidenote, template instantiation caching is a very interesting strategy, but today's compilers don't use it (there was some commercially sold compiler a while back that did have it, though).

Another idea would be to still run the rest of the E2E tests pre-merge, but as a separate job that only makes itself known if a failure occurs.

I don’t think you truly get the “best” of both worlds, because the rate of accidentally omitting a broken test and letting something slip into master is now non-zero (flaky tests aside). This is still a tradeoff. But maybe it’s a good one!

I do wonder if this is as feasible at scale, where breaking master can be extremely costly (although at least it’s not running all tests for all commits, so a broken test won’t break all CI runs). Maybe it could be paired with, say, running all E2E tests post-merge and reporting breakages ASAP.

It seems like it takes just one user using a certain piece of hardware to justify it being supported in the kernel, which is surprising to me. The cost to kernel dev velocity is not weighed more heavily against that?

Yeah, I’ve hit many pain points over the years with SwiftPM. Its restrictions on compiler flags is also problematic.

Thanks for that sequence, I can really picture it now

TurboTax and other tax companies don’t just lobby to prevent a free filing solution, they also lobby for more complicated tax laws to create a greater need for their product

If you’re at the point where the shell might be a bottleneck to your script, it probably should be written in a proper language and not bash

Got it, so this could not be extended to non-literal strings

How does this work under the hood? Does Ruby keep a giant map of all strings in the application to check new strings against to see if it can dedupe? Does it keep a reference count to each unique string that requires a set lookup to update on each string instance’s deallocation? Set lookups in a giant set can be pretty expensive!

What would you call TypeScript’s tsc, which translates TS to JS? Microsoft would say it’s a compiler: https://code.visualstudio.com/docs/typescript/typescript-com...

I believe there’s no other allocator besides jemalloc that can seamlessly override macOS malloc/free like people do with LD_PRELOAD on Linux (at least as of ~2020). jemalloc has a very nice zone-based way of making itself the default, and manages to accommodate Apple’s odd requirements for an allocator that have tripped other third-party allocators up when trying to override malloc/free.

What are the advantages of this over using higher order functions? In Ruby I can do list.map { }.select { } …. That feels more natural (doesn’t require special language support), has a very rich set of functions (group_by, chunk_while, etc.), and is something the user can extend with their own methods (if they don’t mind monkeypatching)

This title should have “How” prepended to it

I figured it might, but I think that this is a top of mind question for people and would be nice to make clear in the comments of the post too. So often there’s some theoretical improvement on multiplication that isn’t actually practical. Regardless, they don’t seem to have posted results for CUDA, which is arguably more important than CPU multiplication which is what they tried

Is this like the Karatsuba algorithm, where it's theoretically faster but not actually faster when run on real hardware?

Btw, it's worth noting that if you know that the result will be symmetric (such as is the case for X * X^T), you can make things faster. For example in cuBLAS, cublas*syrk (the variant optimized for when the result is symmetric) IME isn't faster than gemm, so what you can do instead is just do smaller multiplications that fill in one of the two triangles piece by piece, and then copy that triangle to the other one.

Aren't there some scripting languages designed around seamless interop with Rust that could be used here for scripting/prototyping? Not that it would fix all the issues in that blog post, but maybe some of them.

I’m surprised this isn’t getting more love. My experience with other debuggers with Rust was quite poor, I hope this one can fare much better. For example, I couldn’t call functions with previous debuggers