14113

Something can only live (exclusively) in the type system if everything about it can be reified away. It's the same trade-off as in polymorphic container types: Either the type is tracked at runtime (a-la Java), or the code is instantiated per-type (a-la C++).

In the context of allocators, Zig essentially requires that the programmer perform per-allocator instantiation while writing the code. Odin does the opposite, and requires that the information is held by the allocated object. I am unfamiliar with Rust's approach, but it will be either via runtime tracking, or via instantiation.

But you need to keep track of the allocator somewhere, as otherwise you don't know how to deallocate a container, or its contents. You either pay a very small cost in memory, or have to structure all your code to keep track of the allocator for everything you create.

That works well for greenfield code, but if working on compiler optimisations has taught me anything, it's that there is a lot of legacy code out there in the world that would benefit from re-compilation with optimisations - but would be very difficult to re-write for speed (regardless of whether the work is done by a human, AI, or other machine tool). JIT compilation fits very nicely in this niche, as it means that existing Python projects can get (theoretically) better performance without re-writing.

Utter rubbish. Civil servants can't get anything done because they are chronically underfunded, and yanked around by the whims of the government of the day. Dominic Cummings' is not a reliable source either - he's ideologically at odds with the idea of government _doing_ anything, and because of that has caused a great deal of harm to the UK.

Yes, I was being a bit concise: Individual optimisations should be turned on as determined by profiling, application semantics, etc. My point was more that if you want to get as close as possible between integer and floating-point, then there is a flag that does it. That doesn't mean that you should do it, however...

> Floating point math is often slower than integer math because the compiler is being conservative about how it optimizes your code.

It's not strictly true to say that it's "being conservative". What is more correct is to say that floating point operations have different semantics to integer operations, and an optimisation that retains the semantics of an expression over integers may not do so when applied to an expression over integers. Hence, it may be possible to apply one optimisation to an integer expression, but applying that to a floating-point expression may result in a different program meaning.

C/C++ compilers give you a way out of this with the `--ffast-math` flag, which essentially allows compilers to relax the constraints on floating-point optimisation passes.

For an example of how this works in GCC, take a look here: https://gcc.gnu.org/wiki/FloatingPointMath

Seconding this - having worked on LLVM and Firefox, the performance tuning of each application was very different. Even measuring the performance of an application like Firefox (in a meaningful way) is non-trivial, wheras compilers are much more approachable with traditional profilers (either tracing or sampling).

I mildly disagree - depending on your definition of "typical app". Most applications have much greater use of multi-processing and concurrent cross-thread (or cross-process) communication. Compilers, aside from high-level parallelism across modules, tend to be quite single-threaded applications.

If you're solely interested in single-core performance, then I would agree that they are a good stress test, but I think for a processor that is being sold on it's parallelism, they are not a great benchmark.

> I feel like this is with 2026 view where browsers are so mutually compatible.

I wish this was the case. Unfortunately, companies that work on non-Chromium browsers need to employ dedicated web compatibility teams to either a) help website users fix non-standard (i.e. Chrome only) HTML/CSS/JS, or b) replicate Chromium-like behaviour for specific (very popular) websites so that they work "correctly".

There's also the websites that deliberately block certain browsers which is what tools like "chrome-mask"[1] are built to solve.

[1] https://addons.mozilla.org/en-GB/firefox/addon/chrome-mask/

There are two types of people. Those who can extrapolate from incomplete data, and

To me, the parentheses make it significantly easier to read. They make it clear which operator directly acts on the variable, and create a mental meta-object to which the next operator acts.

I accept that if you're extremely used to writing this style of C code, it might be something that you're used to, and understand implicitly. As a C++ engineer that infrequently comes across this precise pattern, having the precedence made explicit makes it much easier to understand.

As I experienced while trying to write out an AST for this pattern, the operator precedence makes it harder to read. I would at least prefer that it's written as *(foo++).

Oops, you're right - I got the operators the wrong way around! I forget the precise precedence of * and ++ in C sometimes. Assuming that it would be bracketed as *(lwr++), it should actually be:

  block
    statement (assignment)
      expression
        operator (dereference)
          operator (post-increment)
            variable
      expression
        variable

Representing code in a compiler is not precisely trivial, and the two statements are actually quite different from a compiler or AST perspective. Just looking at the first branch:

  *lwr = x; lwr++;

This could be be represented with something like this (and this is a very vague approximation of an AST):

  block
    statement (assignment)
      expression
        operator (dereference)
          variable
      expression
        variable
    statement
      expression
        operator (post-increment)
          variable

The second form, that looks this in the source:

  *lwr++ = x

might look like this in the AST:

  block
    statement (assignment)
      expression
        operator (post-increment)
          operator (dereference)
            variable
      expression
        variable
 

If these two ASTs are to take the same form in the compilation pipeline, there needs to be some kind of pass that transforms one into the other.

As for why the second form is faster (or rather, why the compiler can generate faster code): There is likely an optimisation pass somewhere in llvm that recognises a pattern that this fits into, which allows it to generate branchless instructions. For instance, in the second form, there is a pattern of:

  operator (post-increment)
    operator (dereference)

that might be recognised by a pass. In the former form, the two operators are far apart in the tree, so a pass would have to "look further" to match them up. A single pass likely won't do this, either for (compiler) performance reasons, or for correctness reasons.

Finding which pass that is can be non-trivial, as it's more than a matter of enabling individual passes until one works. It might be that an earlier pass does some code reshaping that allows the relevant pass to work. My suggestion would be to dump the llvm ir at the end, and find the rough pattern that you're looking for, then re-run the compilation with `-mllvm -print-after-all` to see what the IR looks like after each pass, and then manually "look back" until you can't see the pattern any more.

Passing by pointer (in C) reduced the difference a lot, but swapping the order of Add and Int in the Rust enum was enough to reduce the different to:

  cmp ecx, 1
  je .LBB0_3

vs

  cmp ecx, 2
  jne .LBB0_2

LBB0_3 and LBBO_2 were the same in both outputs (up to alpha renaming).

Oddly, both sources seemed to be quite sensitive to match switch and enum reordering, resulting in very different generated code. Possibly something to look into further.

It required a little bit of messing with optimisation settings and library generation in Rust, but they emit very very similar x86-64 assembly:

https://godbolt.org/z/89W4srz4d

My understanding is that churches were built next to yew trees, not yew trees planted next to churches.

Pre-Christian religions had many associations with yew trees (they live for a long time, give off mildly hallucinogenic gasses on hot days, discourage animals), and so built their holy sites around them. When Christianity came to Britain, churches were deliberately built on pagan holy sites to overrun the old religions, in the same way that early Christianity took over roman holy days (Saturnalia -> Christmas, Lemuria -> All Saint's Day). This led to churches being built next to sites with copious yew trees.

The fundamental issue with this is that many problems have a time/energy/financial threshold for success. Trying to tackle such a problem with incremental iterative solutions will consistently fail, as each individual iteration will fail.

This is most obvious when network effects are present (e.g. local immunisation efforts vs country-wide immunisation), but it's surprisingly common in other government-related areas like welfare, childcare, social security etc.

Edit: Another comment has reminded me that affordable public transport is the perfect example of this: Incrementally building out a public transport system will almost always fail, as the initial lines (be they buses, light rail, etc) will typically not be successful enough to justify the cost of building the line. If, instead, a system is built out universally and simultaneously, the utility (and thus income) of each line increases due to the interconnected nature of the network.

Because, in the latter case, you have to declare a function argument for /every possible option/ that you want your graphics API to expose, and you need to do this every time you add a new option.

On the other hand, declaring the options through composition means that the API for "plot" remains static, and adding/removing options can be done trivially without an API change.

Composition (rather than parameters) is also more flexible. Let's say you want to divide your plot into three sub-plots, two of which are 200x200, and another which is 200x400. How do you express this as a keyword parameter? In composition, you could do something like:

plot( ggsubplot(ggvsplit(ggsize(200,400), gghsplit(ggsize(200,200), ggsize(200,200)))) )

Incorrect: Star Labs have been shipping laptops since 2018, before Framework was even a company.

Star Labs have delivered a number of other high quality linux laptops - I even used one as my daily work driver for a few years at a previous job. They're not a startup.

> companies are supposed to lose money while they grow

At what point do we declare that a company has "grown" and now must make money? OpenAI is a multi-billion dollar company right now, surely that's a point at which they should be profitable, instead of propped up by further investment and borrowing.

> We have very strong indicators that inference is not a money loser for these companies

All of the economic analysis that I've read strongly states the opposite. Running a GPU is a net loss /even for the data centre operators/. For them to break even, they currently charge OpenAI/Anthropic/Etc more than OpenAI/Anthropic/Etc make per-token.

This post is actually a joke, but it does bring about an important point: For an interpreter, having more information results in faster execution. WASM is much closer to Java bytecode than you might think, and SpiderMonkey/V8 are basically the JVM. WASM also undergoes multiple different stages and kinds of JIT compilation in most browsers, and detailed type and usage information helps that produce faster execution.

Also, don't forget that WASM is designed to replace JavaScript, thus it must interoperate with it to smooth the transition. Rosetta and Prism also work to smooth the transition from x86 -> ARM, and much of the difficult work that they do actually involves translating between the calling conventions of the different architectures, and making them work across binaries compiled both for and not for ARM, not with the bytecode translation. WebAssembly is designed to not have that limitation: it's much more closely aligned to JS. That's why it wouldn't make sense to use a subset of x86 or similar, as it would simply produce more work trying to get it to interface with JavaScript.

There was a company that did compute-in-dram, which was recently acquired by Qualcomm: https://www.emergentmind.com/topics/upmem-pim-system

That's not quite correct. Snapdragon chips that are advertised as being good for "AI" also come with the Hexagon DSP, which is now used for (or targeted at) AI applications. It's essentially a separate vector processor with large vector sizes.

> More streamlined menus

For everyone here complaining about this, have you ever looked at how many ways there are to access your history on Firefox? At my last count, there were 4 different ways to do it, depending on which menu you picked first. Cutting down this kind of inconsistent, and repetitive flow is something that we should be applauding.

No, Firefox never targeted geeks. It's just that, when it came out, the only people who used a browser other than Internet Explorer happened to be geeks. The audience came to them, rather than them going to the audience.

From the article: "[...] as developers get more and more senior, they tend to ignore more and more problems, because they've gotten so used to it. That's the way it's always been done, and they've learned to live with them, so they've stopped questioning it any more."

This is wrong - triSYCL is roughly the same age as ComputeCpp, and hipSYCL is only slightly younger. There has been a lot of academic interest in SYCL, but as with any new technology (especially niche technologies) it's always going to take time to get people on board.

Also, from a quick look at your profile, you seem to have quite a lot of comments criticizing or commenting on CodePlay. Do you have some sort of relationship or animosity with them?