evmar

This (without a VM) is more or less what Wine does, but implementing the Windows ABI instead of the Linux one.

How do you read a blog that says "So either way, Balaji is 100% guaranteed to lose money on this bet, no matter what happens. It’s not a risky bet; it’s a sure loser." and then come to this conclusion?

That's true, but the styling of this modal doesn't look like any dialogs I've seen in Google Docs. (I'm not familiar with the MS equivalent.) (...it's possible this is also featuring some reskin of Google Docs that is confusing me?)

It's interesting to compare the screenshot here with the one in Google's similar announcement:

https://workspace.google.com/blog/product-announcements/gene...

They look strikingly similar. Is it just the obvious design for this, or is one company following the other's design? (I believe neither of them have actually shipped anything yet, though I'm not sure.)

I worked on JS infra for Google. One thing we found in this space is that when your apps get very large in terms of number of source files, there is a developer-impacting load time cost to the unbundled approach.

That is, your browser loads the entry point file, then parses it for imports and loads the files referenced from there, then parses those for imports and so on. This process is not free. In particular, even when modules are cached, the browser still will make some request with If-Modified-Since header for each file, and even to localhost that has time overhead cost. This impact is greater if you are developing against some cloud dev server because each check costs a network round-trip.

However this may only come up when you have apps with many files, which Google apps tended to do for protobuf reasons.

A long time ago I wrote a toy IMAP client, and ran into similarly confusing issues about how the protocol is supposed to work:

https://github.com/evmar/go-imap/blob/master/imap/doc.go

https://docs.kernel.org/x86/orc-unwinder.html (which I found when looking up ORC, as mentioned in this thread) has some stats for the Linux kernel on the cost of frame pointers: "5-10%" and "3.49% more cache misses with framepointer enabled and 6.59% more cycles".

Between this, the various sorts of C language safety checks compilers have been slowly adding, and all the spectre-related defenses, it really does feel like performance is getting slowly consumed by a series of single-digit percentage tweaks.

If I reflect over my life, what has worked is being open and showing passion at every opportunity when meeting people. Most will respond as you’ve described, but with enough rolls of the dice you’re more likely to have a lucky hit. It can be a little exhausting to miss so many times, but I think there was no particularly successful strategy beyond that.

[ninja author]

Ninja build targets in a semi-arbitrary order: the memory order of the pointers to the objects representing the build steps. This was chosen in part because it was easy but also because it was a little unpredictable (in the same sense as this nice shuffling idea). In practice I might expect the pointers to get allocated in the order they're encountered while parsing though, so perhaps similar to Make.

My recollection is we experimented a bit with different prioritizations but didn't find any that reliably were better. It does seem like you could try prioritizing "longer" tasks. (There are also more complex models that take into account the graph; I have been mentally drafting a blog post about this area, there's some interesting research history...)

To do so you'd need to keep around data from previous executions of those tasks, and perhaps multiple runs (for the case where a given task can take a varying amount of time).

In my newer n2 experiment, which was designed to be a little easier to hack on, the place you could play with prioritization is right here: https://github.com/evmar/n2/blob/d64412ae74ddff4e85329f390a0...

The "available to run" tasks are in a deque there (which also means steps go in parse order) but you could easily imagine changing it to some sort of priority structure.

[former Googler]

Yes, I occasionally saw people get highlighted for making optimizations like "this saves 1% in [some important service]". When you're running millions of machines, 1% is a lot of machines. However, it's also likely the case that the easy 1%s have already been found...

English is terrible for sure, but this comment is pretty funny to compare it to the language that spells /kɛs kə sɛ/ as "qu'est-ce que c'est".

In this thread: people getting mad about Google dropping a product they've never heard of, let alone used.

Not to defend snap, but I worked on Linux Chromium wrote this about why the apt/.deb model is difficult to make work reliably:

https://neugierig.org/software/chromium/notes/2011/08/zygote...

To be clear, I think many developers are comfortable enough with the small handful of commands most regularly use. For the more advanced case of maintaining a fork of a high-velocity codebase like WebKit, it's likely you'll need a deeper understanding of remotes and how to manage complex rebases, especially in the presence of lots of conflicts. And possibly some fancier tools like git-subtree. In particular in WebKit my recollection was it was common to patch something locally and eventually take it upstream, but after upstream's requested modifications the patch would eventually come back around and conflict with itself.

We had a similar rotation on Chrome team for merges from WebKit (pre fork), and it was similarly a lot of work and clunky tooling!

A few times in my career (including this one) I have thought, "We are sure going to a lot of effort to maintain a modified copy of that code while also preserving our changes atop it as we sync, and this is exactly the kind of workflow that Git was designed to enable." Like, the Linux kernel dev workflow is all about different maintainers maintaining different branches and merging between them, and that is where Git comes from.

So in a setting other than Chrome I have tried out using Git to try to manage these sorts of situation. I have found in practice many engineers aren't comfortable enough with Git to have it end up helping them out tooling-wise. This is disappointing but also not too unexpected given Git's UI.

I didn't have any particular expectation when I opened up this link, but because I was curious about the authors I clicked on one and found they had also published one titled:

"Evidence for a connection between coronavirus disease-19 and exposure to radiofrequency radiation from wireless communications including 5G"

Which I guess in some sense might also possibly be true, but I gotta say it's a pretty bad opening sign.

This comment is pretty ironic given that Aaron (the person you’re quoting) didn’t go to college at all.

Source: https://blog.thirdyearmba.com/not-everyone-should-attend-col...

The Economist podcast had an episode on ESG (likely related to the article) and they had Tariq Fancy come on that podcast:

https://www.economist.com/esg-pod

This article was followed by a longer book. Recommended.

http://atulgawande.com/book/the-checklist-manifesto/

Congrats on making the release! I glanced through the docs and it seems Beast works via a graph over targets and mtimes?

I recently wrote some retrospective notes about build system design in this area that seem like they might be useful for someone in exactly your place:

https://neugierig.org/software/blog/2022/03/n2.html

The other inaccuracies in this article have already been covered. I noticed there was also a weird rant about mimalloc in there ("For some insane reason, mimalloc is not shipped in Visual Studio").

My understanding is mimalloc is basically a one-person project[1] from an MSR researcher in support of his research programming languages. It sounds like it's pretty nice, but I also wouldn't expect it to be somehow pushed as the default choice for Windows allocators.

[1]: https://github.com/microsoft/mimalloc/graphs/contributors

Thank you for explaining! I think the piece I was missing is that the sigint handler is passed the instruction pointer of the faulting instruction.

The comment I was replying to made statements about both Java and JavaScript, so my questions were also about both (and whether they were different). I just added a line break to make this clearer.

[author here] Very interesting, do you have a reference on how Java implements this?

I just poked at v8 a bit and they seem to have an explicit 'null' object in the VM, though I don't know a lot about so it's possible it works as you suggest.

It seems it might be hard to distinguish language-level null pointers from null pointers within the VM implementation. E.g. v8 runs within a Chrome process that is processing HTML and other things, so if v8 had some special signal handling of null pointers it'd need to be able to distinguish those from HTML processing bugs etc., which I think you might only be able to do by examining the stack? I haven't thought this through but it seems difficult.

Thanks for this comment. In a previous draft of the post I had more about this, but I decided to omit it because I didn't have much insight about it beyond some handwaving around how it's just encoding the instructions and the optimizer will do something different. Your comments (this and the other one in this thread) are better than what I would have written, so I learned something today! (Edit: I updated the post to link to your comment.)

`static` also allows it to optimize, and it's more of a code hygiene thing. Your original code as written unintentionally defines `find` as a function that must be preserved (as a separate function) into the compiled output, and `static` undoes that.

Thanks for explaining, sorry for the mistake!

The kind of isolation in the post, where the web content doesn't have access to system resources, was part of the original Chrome release.

(You mentioned site isolation, which is a different feature, but the dates you have look right for that.)

As a person who likes Go a lot, and who finds Go bashing -- and really, bashing in general -- pretty tiresome to read, I thought this was a pretty decent article and the sort of thing we ought to encourage on HN. At least in contrast to the usual rants.

In particular I appreciated the author's interest in exploring the reasoning behind the design decisions they disagreed with, rather than stopping at "I don't like X".

(I work on Figma's renderer, but I don't know much of the history of it.) The speculation there about C++ vs JS performance in Figma seem about right to me.

Notably, some Figma views (like when you click the "play" button to view the prototype) render Figma documents using JS, no* Wasm. They are more or less comparably as fast as the C++ renderer, in part because much of the heavy lifting is done by GPU code that isn't C++ or JS anyway.

The main place I think we've seen a performance difference is, as the post observes, high throughput scenarios: for example, decompressing a large file, or parsing through a large binary serialization of a file. But particularly in a browser setting you end up wanting to get your data into a browser API at some point and that often ends up meaning copying data around that eats your performance.

The other main difference that's worth pointing out is memory efficiency. For example, pointers in Wasm are currently 32 bits, which means (at least in principle) a massive graph -- such as a Figma document DOM! -- can be represented with 32-bit C++ pointers rather than 64-bit JS pointers. But even that distinction is not so clear in the presence of pointer compression [1] and there are other graph representation options etc.

In all, my conclusion is that performance does not obviously derive from tool choice because there are so many confounding factors including algorithm choice and path dependence. For another example of this, I often think of this comment[2] by the esbuild author (coincidentally, also behind a lot of Figma code) where he found better performance with Go than Rust, which is not what I think anyone (including him) would expect up front.

[1]: https://v8.dev/blog/pointer-compression [2]: https://news.ycombinator.com/item?id=22336284

* there is some wasm in there actually but it's not for performance reasons