cwzwarich

Do you have an example of a real-world package dependency situation that generates a truly difficult SAT instance?

The name "Wuhan coronavirus" was pretty common in January (e.g. https://www.cnn.com/2020/01/21/health/wuhan-coronavirus-firs...), since the SARS-CoV-2/COVID-19 names only came out February 11th.

> does LLVM recognize its C++-centricity as a problem in delivering on its mission of being a multilingual target platform, or has it tacitly changed its mission to be more-or-less implicitly C++-centric?

LLVM is a mostly corporate-sponsored open source project. There isn't really a global LLVM roadmap, and developers usually work on things that help their employers.

There has rarely been explicit opposition to features that help other languages, but at the same time it is very difficult to make a large nontrivial change to LLVM at this point. Someone who is not already an active LLVM developer might be overwhelmed and give up on upstreaming their changes. IMO the most successful use of LLVM for a sufficiently non-C++ language has been Azul's work on last-tier JIT compilation using LLVM:

https://llvm.org/devmtg/2017-10/#talk12

> And specifically, what sway does Rust hold on the LLVM project and its goals?

As far as I can tell (and this may be a bit out-of-date), basically none.

> And Go was announced very close to its 1.0 launch while Rust was announced very, very early in its development cycle. So in reality they actually align neither in timing, nor in target domain.

Back when Rust was announced, it was much more similar to Go than it is now, even having a similar runtime for concurrency. Go did a better job than Rust of delivering this paradigm, largely because the Go implementors weren't relying on commodity technologies like LLVM and libuv.

As time went on, Rust was given more support by Mozilla, and it evolved into something more suited for browser implementation. It had other major influences at this point:

- The constraints of using LLVM. Many projects have failed trying to make LLVM do something that it's bad at doing. At the end of the day, LLVM is good at compiling C++ and things that look like C++, so if you stick to using LLVM and want an efficient language, your language will end up looking more like C++ over time.

- The swell of momentum around C++11. All of a sudden, programming idioms from the "Modern C++" movement were becoming mainstream.

- The halo of academic research into type-safe systems languages. Very few of the ideas in Rust are new, but some type system features from academia became more palatable for ordinary programmers when combined with the C++11 style.

> compilers and linkers had identical code folding optimizations for a looooong time (20+ years for msvc, a decade or so for GNU gold (--icf option) and GCC (-fipa-icf))

If you look at the resulting binaries, they don't work as well as you might think.

Google also only needs to put enough telemetry in their browser to correlate your browsing with the other data they already have.

> I'm curious what kinds of tasks require a binary with a 300 MB text size…

C++ lends itself to bloated binaries. Template instantiations are duplicated even for types where the instantiations could have identical code. Compilers have traditionally favored overly aggressive inlining over whole-program optimization.

Rust didn't solve the problem; it just duplicated the C++ approach, and made it worse by effectively compiling with the equivalent of C++ exceptions enabled. The next great systems language should target binary size and CPU frontend overhead.

The README doesn't link to the final version of their article: https://research.fb.com/publications/bolt-a-practical-binary...

This site openly admits the obvious flaws in their model:

- R0s for interventions are guesses, in some cases informed by data. There is no historical precedent for what is going on right now to draw from.

- The default R0 used in this model is an average. The model does not adjust for the population density, culturally-determined interaction frequency and closeness, humidity, temperature, etc in calculating R0.

- This is not a node-based analysis, and thus assumes everyone spreads the disease at the same rate. In practice, there are some folks who are “super-spreaders,” and others who are almost isolated. Interventions should be targeted primarily at those most likely to spread the disease.

Are there any epidemiologists using less naive statistical models who are producing easily readable results like this? The "average R0" logistic function model seems better suited for examining historical epidemics than estimating risk to inform decision-making for ongoing epidemics.

They picked a fixed thermal budget based on realistic usage scenarios, and then translated that into a fixed power budget. They balance the power budget between CPU and GPU using SmartShift (https://www.amd.com/en/technologies/smartshift), which is their marketing name for the power management on the control plane of their fabric.

Some animals show more viral diversity than others. Amongst mammals, bats are somewhat unique:

https://www.the-scientist.com/news-opinion/where-coronavirus... https://www.the-scientist.com/notebook/why-bats-make-such-go... http://nature.com/articles/doi:10.1038/nature22975

The research on Chinese coronavirus outbreaks indicates that bats are a large reservoir for these viruses, and they frequently infect other animals, but it is difficult to pinpoint the final jump to humans exactly. Given the unique status of bats in this regard, it's probably best to keep live ones away from humans or other animals intended for human consumption.

> Further it brings into question the items that are good or bad. Is "Racoon Dog" ok or not? Can they sell "Bats"?

As far as I understand things (which is only from reading articles and watching YouTube videos of people visiting these markets), most of the animals like bats, civets, pangolins, etc. that are implicated in zoonotic diseases are delicacies rather than staples. If they were banned, nobody would starve.

The vast majority of meat comes from factory farms, so for factory-farmed meat to go away, total meat consumption has to drop dramatically.

> No JS JIT, only interpreter. I don’t care that much about JS performance as a user and the difference in complexity is astounding.

One of the cool techniques we used in earlier versions of JSC (although someone told me it's been dialed back since then) was caching property accesses / method calls in the bytecode interpreter. This technique ended up getting published by someone else in a different context:

https://web.cs.upb.de/cp/download.py?key=ecoop10

I think there's more to be explored along these lines.

Since we've worked on the same browser engine before, I should ask the obvious question: what do you plan to do differently that will make it better than existing engines?

It depends what you mean by "specialist in microprocessors". There is enough publicly / academically available information about CPU architecture / microarchitecture to become highly knowledgable on the subject without ever having worked on a CPU before. But once you get to the level of implementation, physical design, and manufacturing, you need real specialists, since all of the relevant knowledge only exists in industry.

It’s for a conference that’s in June.

What about a dystopian future where sites only work via SGX-like secure compute environments that remotely attest the execution environment to the server?

The new UI increases the similarity between posts and ads, making you more likely to mistakingly click on an ad.

To get linear time validation, you need conditions at each control flow transfer that can be checked locally but together imply that stack usage in the function is well-formed.

The funclet approach (in more ordinary terminology) is to ensure that the stack difference from function invocation upon entry to a basic block is the same across entries to that basic block, and that those additional stack entries all have the same (statically specified) type in each invocation. This is very natural when generating code from an SSA optimizer.

Java bytecode traditionally didn't contain any of this branch target or type information, and required the bytecode verifier to do an iterative combined control/data-flow analysis. Even now that they added some of that type information with stack maps, it's still more complicated than it needs to be due to the historical legacy of this approach.

A lot of those bad WebAssembly decisions are carried over from Emscripten/Asm.js and don't have any real rationale behind them beyond that.

Obviously, since JS doesn't support arbitrary control flow, Emscripten/Asm.js would need to convert to some simplified form of control flow (although not necessarily fully structured). It seems that this solution was carried over to WebAssembly without much deep thought given.

There does seem to be some backwards association with Java's bytecode verification complexity issues (which are the result of a bad design, not unstructured control flow). In the big GitHub Issue (https://github.com/WebAssembly/design/issues/796) on the topic, one of the core V8 developers even claims that the Java experience justifies the WebAssembly decision. However, the funclets proposal for WebAssembly (https://github.com/WebAssembly/funclets/blob/master/proposal...) shows that you can support arbitrary control flow with linear time verification if you choose a different design than Java.

The extent to which modern CPUs are “like JIT compilers” is highly overrated by SW people.

Most important instructions map 1:1 to CPU micro-ops, with memory operands (on x86) being mapped to separate load/store micro-ops. There are cases where instructions map to long sequences (e.g. VMENTER) or get combined into one micro-op (e.g. compare-and-branch), but this is far from a JIT compiler.

The term "in-place" almost always means O(1) additional space, whereas this uses O(n) additional space.

You already take a page fault with DWARF exceptions, since the unwind / LSDA info is probably on a different page from any of your code, as well as the personality routine itself.

With the C++ memory model you can make std::atomic<char> larger than char.

> Not being able to do byte-granular writes means you simply can't implement things like this at all unless you: > 1) Decide that "char" will be 32 bits (i.e., make a byte on your system 4x larger than usual).

With the C++ memory model you can make std::atomic<char> larger than char. A lot of code assumes that this is not the case and that it is possible to cast between the two, but it's (surprise) undefined behavior.

The author apparently works for Facebook, which makes all of the vague language in the story make a lot more sense.

Would Facebook really let somebody do this to every external frontend server on a Sunday without some boring authorization first? The authorization could simply be denied with a boilerplate response about the right way to do things, with less emotional resources spent than the author apparently did.

I don't think that health care (or the things you mention) should be treated as a market. I was only responding to the claim that this is a "cartel market" and not basic market behavior.

Isn't it natural to want to only "sell" to "customers" that are profitable? This is a natural function of other markets.

RWI doesn't own the Devilfish ideas (even if they were patented, they would've expired by now since Robin's been doing this since 1993), so the business deal was really over the Devilfish brand name and endorsement.