14113

قبل 14 يومًاdiscuss

> 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/

14113

قبل 15 يومًاdiscuss

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

14113

قبل 15 يومًاdiscuss

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.

14113

قبل 15 يومًاdiscuss

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++).

14113

قبل 15 يومًاdiscuss

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

14113

قبل 15 يومًاdiscuss

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.

14113

قبل 17 يومًاdiscuss

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

  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.

14113

قبل 18 يومًاdiscuss

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

14113

قبل 24 يومًاdiscuss

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.

14113

قبل 24 يومًاdiscuss

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.

14113

الشهر الماضيdiscuss

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)))) )

14113

قبل 3 أشهرdiscuss

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

14113

قبل 3 أشهرdiscuss

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.

14113

قبل 4 أشهرdiscuss

> 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.

14113

قبل 4 أشهرdiscuss

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.

14113

قبل 7 أشهرdiscuss

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

14113

قبل 7 أشهرdiscuss

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.

14113

قبل سنتينdiscuss

> 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.

14113

قبل سنتينdiscuss

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.

14113

قبل 4 سنواتdiscuss

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."

Submissions

Say Hi to Kit

Stargazer: understanding the π-calculus, visually

Could a Neuroscientist Understand a Microprocessor?

CUDA 8 Features Revealed

The Post Correspondence Programming Language

Links: Linking Theory to Practice for the Web

Designing Posters for Conferences

The Researcher's Bible (1985)

comments