Joky

> I'm still waiting on a Python project that compiles to pure C

In case you haven't tried it yet, Pythran is an interesting one to play with: https://pythran.readthedocs.io

Also, not compiling to C but to native code still would be Mojo: https://www.modular.com/max/mojo

You can configure "squash&merge" to use the PR title and description for the commit message now, which makes it reviewable!

> You could make the argument that this well-understood process could be broken out into its own class/package/module and tested with its own public interface, but if there really is only one consumer then that's kind of a strange trade-off to make in many cases.

That's how I develop in general: a "component" does not exist because it has multiple-clients, but because it is a conceptual piece of logic that makes sense to document and test in isolation. It allows to define what is the public API of this component and what isn't. This is how software scales and stays maintainable over time IMO.

There is something to be said about individual productivity (whatever that means in a very innovative/creative environment) vs team/company output, just today I saw this in my feed: https://flocrivello.com/changing-my-mind-on-remote-about-bei... And that's coming from someone who actually tried to build a business out of remote work (TeamFlow was the product).

I can be much more productive at home when it is about my individual contribution (me coding to deliver something unambiguous), but xxx individuals doing this does not necessarily align into a great product: that does not scale.

They claim they are writing the actual kernel code (as in the implementation of a matmul) with it, and it was presented as a "system programming language": this goes far beyond "high-level tasks" it seems.

It depends what you mean by "new subsystem" and "transitioning to": what seems like a given is that the notion of "one size fits all" of LLVM IR is behind us and the need to multi-level IR is embraced. LLVM IR is evolving to accommodate this better, within reason (that is: it stay organized around a pretty well defined core instruction set and type system), and MLIR is just the fully extensible framework beyond this. It is to be seen if anyone would have the appetite to port LLVM IR (and the LLVM framework) to be a dialect, I think there are challenges for this.

TensorFlow is also a runtime, yet we model its dataflow graph (the input to the runtime) as a dialect, same for ONNX. TensorRT isn't that different actually.

All of Google TPU is powered by the XLA compiler, so any MLPerf benchmark result from Google comes powered by XLA. Anything JAX is also built on top of XLA, so you can take JAX performance as a point of comparison as well if you'd like.

The movement of paddling has a natural rotation of the shaft when you raised the fixed hand for a stroke on the other side, it's quite straightforward to figure out sitting and mimicing the movement.

During this movement if the blade aren't feathered at all you have to compensate with some bending of the wrist. The amount of rotation of the shaft induced depends on how much you raise the hand/elbow, and so is fairly dependent on your style of stroke. This is the main way I think should be approached feathering: how much vertical do you intend to paddle? From there the angle should follow to optimize for the least amount of wrist twisting.

In general paddling very vertical will come with more angle in between the blades. I practice slalom and use to have 70-80 degrees crossing, but I tend to paddle less vertically now (aging? Lack of training?) and I'm down to 60 degrees comfortably now.

But these are options, it's not a big deal to me that compiler offers special options for special use cases. It's not clear to me if you are saying that the *default* for clang and GCC differs, aren't they both using `fno-wrapv` by default?

Can you elaborate on the signed integer overflow and the implicit initialization differences you're referring to?

I don't think compiler implementations are responsible for the standard to refuse to endorse 2-complement (which is the root cause of signed overflow being UB originally if I understand correctly).

You may be interested by https://www.microsoft.com/en-us/research/project/checked-c/

At least for GCC/Clang this isn't what O0 means. Excerpt from the GCC manual:

> Most optimizations are completely disabled at -O0 or if an -O level is not set on the command line, even if individual optimization flags are specified.

And

> Optimize debugging experience. -Og should be the optimization level of choice for the standard edit-compile-debug cycle, offering a reasonable level of optimization while maintaining fast compilation and a good debugging experience. It is a better choice than -O0 for producing debuggable code because some compiler passes that collect debug information are disabled at -O0.

(Og isn't really implemented in clang yet, but the mindset is the same)

> Don't compilers already have ways to mark variables and dereferences in a way to say 'I really want access to this value happen'?

The standard defines it, it's `volatile` I believe. But it does not help with the examples above as far as I understand (removing the log, removing the early return, time-travel...).

> From what i can observe over years apple has almost exactly same perf culture as google and any other similarly sized company in the US

Right, if you look from very far away and put "all large US company" in the same bag.

Otherwise, if you zoom on "Silicon Valley Tech Companies" then Apple and Google's perf process and associated incentives look quite radically different in many aspects.

> The problem in this case is a chicken-and-egg problem: it's hard to get money without an education, and it's hard to get an education without money. > For-profit education cannot solve the problem, because for-profit education is the problem.

Have you seen school that only gets paid after you start working (and based on a percentage of your salary), for example: https://www.holbertonschool.com I like the concept in that these school are somehow "investing" in the student: they only get as successful as the student is.

Python isn't really driving the compute intensive part of ML actually, whether it's JAX, PyTorch, or TensorFlow the code is really mostly native. Convolution are implemented by hand in highly optimized libraries (Intel MKL-DNN, Nvidia cuDNN) and the Python glue is really just a light "dispatcher".

A lot of it is also asynchronous for performance: the Python code just enqueues more work to a queue which some native C++ code processes. For TensorFlow the Python code traces an entire computation graph that is stored a protobuf and then executed by a C++ native stack, potentially remotely/distributed. Serving ML with TensorFlow does not involve any Python code in many scenarios.

Python is still quite useful for scientist to quickly glue everything together, and to describe their dataset, or when they collect result and need to produce graphs or other data analyses.

There is very little requirement on equipment to fly in the US, you don't even need a radio in the majority of the space (only when you approach towered airports and other busy / special areas). So we're far from requiring a camera :)

> They recently opened a chapter in California.

I heard instead recently that they are closing the California chapter that they opened 3/4 years ago.

I would double-check that it builds the exact same thing (there are lot of options when building LLVM, and CMake may auto-detect and enable support for things like Go bindings for example). Choice of compiler and compiler flags can make a difference as well.

The bootstrap isn't too much of an issue, a binary release of the compiler is committed inside the repo itself.

The speed and responsiveness is there, but the price is a tricky management of background daemon and aggressive memory prefetch and caching which may be a bit heavy on memory resources (which is then less available to the compiler processes). This works out well when you run the Bazel daemon locally and distribute the work to a remote build farm, but less when you're building a project like LLVM on your laptop.

Source?

> trains the company's workers

How much of these products are designed and built in these Europeans countries though?

In my experience: I manage to roughly match the EPA rating on the freeway driving at 65mph (it depends on the road, on the temperature, on how much stuff/people are in the car, etc.), but it goes down quickly as you drive faster. This table illustrates it fairly well: https://teslike.com/

You may not know, but:

1) LLVM does not use pull-request and code-review isn't mandatory for the main contributors.

2) until a few months ago LLVM didn't even have any testing system before the code is pushed to the master branch: folks just push code directly after (hopefully) building/testing locally.

The real root cause is that no one cares enough to really invest deeply into this. There is also not a clear community guideline on what is acceptable (can I regress O2 compile time by 1% if I improve "some" benchmarks by 1%? Who defines the benchmarks suite? etc.)

According to https://shieldgeo.com/terminating-an-employee-in-france-a-gu... it would rather be roughly 1 week pay per year of seniority.

However it is hardly comparable as unemployment benefits would kick in (on average 72% of your previous salary after taxes, maximum duration 24 months with decreasing amount). For instance if you worked 3 years and your annual salary was 80k, you could get a benefit of 57k over 12 months.

The closest previous work would rather be Facebook BOLT I believe: https://github.com/facebookincubator/BOLT

Google has very large applications, but also they are using static linking: imagine that you statically link all the possible dependencies in a single binary for each application. 300MB is not considered a large binary at Google actually, I don't know what is public but you may look at Table 2 in this publication for instance: https://www.researchgate.net/publication/314105281_ThinLTO_S...

I repro here some data, there is a bit more in the paper:

Clang 1.9k Files, 217MB (-g0), 3554MB (-g) Chromium 17.8k Files 706MB (-g0), 7544MB (-g) Ad Delivery 13.8k Files 1073MB (-g0), 7469MB (-g)

(this is the number of object file that are participating in the link).