Wait what? We were using the old flang project just fine. I thought they just moved it in tree and keept developing it.
2,917 karma · joined April 21, 2019
You don't need to implement neither hardware support nor OS support, just combine the two things that are already implemented, and fix a couple of incompatibilities, but not many (some parts of OS support will be x86 only and these would need fixing, but fixing these should be trivial since you can c&p from the arm+iOS code).
Why would it take months to add support for this to GCC? GCC's architecture would need to be really flawed for this to be true, i.e. , requiring you to re-implement a big chunk of hardware support for each OS, or full OS support for each new hardware. Given how many architectures and OSes GCC supports I just can't imagine this being true.
Unless by this work taking months, you mean "not doing anything the first 99% of the days, and doing all the work in the last couple of days". In that case, sure, this can take as long as you want.
If they don't do that, then you can just use any "generic" C BLAS/LAPACK implementation, performance will be poor, but that's pretty much the only option if your hardware vendor doesn't support BLAS.
I guess people can write their own BLAS as well, but if you want to re-implement BLAS in 2020, then Fortran is probably not the best language to do that.
It is quite hard to write portable Fortran code, but code that at least compiles with PGI should compile with that as well.
Most important: this optimization enables pipelined execution.
When people talk about a CPU executing an integer add instruction in ~1 cycle, what they actually mean is that the add has this latency when the CPU pipelines are full.
If you have an 11 stage pipeline... the add can often have a latency of ~11 cycles... if you write the _right_ code for it.
Just find one that you'd like to work on, write that you are going to work on it, and start doing the work, and asking lots of questions.
It is much better at this than C++.
For example, change a trait in your Rust library, and recompile the tests, and compare that with changing a type in, say, range-v3 (or any other C++ header-only library).
In C++, recompiles take pretty much the same time as clean builds (for range-v3, exactly the same time). In Rust, they are infinitely faster (100000x faster, depending on the project, but essentially almost instant, in contrast with initial compiles).
So for development at least I'll pick Rust over C++ every day. I only do an initial compile once, but I edit and recompile a lot, and that's the bottleneck that I really care about.
(Same with C btw, add a new API to a commonly use C header and re-compile, and you end up re-compiling the world, while from Rust, you just re-compile the part of the crate where the new API was added, and since no downstream crates use it, that's pretty much it - instant change).
Citation needed ?
I know at least 20 people being paid to work on the Rust compiler, which crank's your 10x number from 25 to 200. And this is only the people I can come up with from the top of my head.
OCaml is great for the application level stuff, and also performs quite well in general. But for building fundamental parts of the stack in which perf is important (like the multi-threading runtime, the garbage collector, etc.) you need to drop down to C++, C, or Rust.
OCaml is definitely much nicer to use than C and C++. But I don't find it that much nicer to use than Rust TBH.
Its quite easy to set up as well, basically a workstation that you can just connect to with remote desktop, but migrate the hardware it runs on.
docker and nvidia-docker work fine for me
One interesting thing is that COVID-19 lowers the mortality rate in the mid-to-long term. It disproportionately targets the weakest, so in the next couple of months and years, less people than the expected average will die, because the weakest are already dead, and that will lower the mortality rate per capita for one generation at least. At some point, it will hopefully raise again, and that too will be due to COVID-19, because the reason for that will be that we wouldn't have a recent-enough COVID-19-like event.
---
Point being, one should be careful when comparing mortality rates and absolute death counts. One needs to factor in both to get the full picture, and for rate, the period over which the rate is computed is very relevant.
The only solid metric for COVID-19 deaths is excess mortality, that is, the actual number of deaths - the statistically expected number of deaths (e.g. extrapolating from the last 2-5 years).
This metric is independent of testing capacity and malicious actors like politicians just outright lying to the public to try to save face. You can "hide" dead people, but doing so is much harder than hiding COVID-19 related deaths.
You can't conclude from this metric what the source of all these extra deaths are, but if they are not caused by COVID-19, every alternative explanation I can think of is even worse than a global pandemic.
https://ourworldindata.org/excess-mortality-covid
https://www.economist.com/graphic-detail/2020/04/16/tracking...
https://www.ft.com/content/a26fbf7e-48f8-11ea-aeb3-955839e06...
In general, you are correct. LLVM-IR is architecture dependent. Things like the size of a pointer, the size of an `int`, parts of the calling convention, or "architecture-specific defines in C code" have already been "hardcoded"/expanded into the generated IR.
In practice, you can easily re-compile x64 IR to arm64, as long as the IR does not use, e.g., "arch-specific" LLVM intrinsics (like explicitly using, e.g., NEON intrinsics). Apple does not let you ship this kind of bitcode to the AppStore, so if you want your software to use NEON on iOS, you need to call the opaque Apple math libraries, which they can just provide for a different architecture.
The other things you need to worry about is, e.g., calls to system libraries (e.g. you can't call a Windows API, generate IR for it, and then try to re-compile that IR for Linux, because that API will fail to link). In practice, if you provide the symbol, everything will work, and the system APIs for MacOSX, iPadOS, and iOS are quite similar.
The x86-macos IR won't be recompilable to Linux or windows, but can be made recompilable to arm-macos.
Note also that this is not the first time Apple does this with the AppStore. They silently migrated all apps from 32-bit ARM to 64-bit ARM, recompiling the software for you. This hints that they have additional capabilities to changing some architecture details in the AppStore's IR, like pointer-sizes (these Apps are not running in 32-bit compatibility mode in 64-bit CPUs, but are running as native 64-bit apps).
>Additionally, Mac AppStore apps are shipped without Bitcode.
The Apps themselves are shipped to users as binary blobs, but developers ship bitcode to the AppStore, which Apple has been recompiling for each new arm processor in their iphones (so on an iPhone 11 you get a different binary blob than on an iphone 6, but the developer didn't ship two blobs, nor they recompiled their App).
AMD has many GPGPUs, but while they have kind of ok-ish raw numbers, their software stack makes quite poor use of them.
Users care about perf/$, and nvidia is king there. For deep-learning and other apps, hardware without software is useless.
I've also read that the A100 can deliver 4x the performance on some DL workloads.
So when Apple releases a new chip, it can just re-compile the LLVM-IR to it, to make use of newer features and compiler optimizations for that chip.
Basically, the only applications that have to do anything to transition to Arm on Apple are those that are not using the AppStore... which from the platform's perspective, is kind of their own fault.
To sync, I use a git repository (you can set a watchpoint on macos and linux to any directory to invoke a command on changes, so I just invoke git and commit).
Just act completely random.
Don't wake up, and go to your job, under the assumption that you will get paid.
Don't avoid jumping down a 15 stories building under the assumption that you will die.
Don't breathe. Your model is biased towards breathing.
> I have a multi core machine running at speeds well above my comprehension and you are saying they can't render simple 2d primitives at speed? That just blows my mind. What are they spending the time on?
Moving memory from RAM to the CPU, doing stuff in the CPU, moving the results back to RAM, moving those results from RAM to the GPU, etc.
The CPU is fast, but moving memory around is not, so the CPU and the GPU just end up doing nothing most of the time, waiting for memory most of the time.
---
Raph's blog (linked at the top), has a bunch of articles about rendering latency. But just google about typing latency, there are a couple of projects and tools that measure the time between a physical keystroke is pressed, and the letter being rendered on the screen (end-to-end). Beyond the memory copies, what usually happens is also: an interrupt is triggered on the CPU, the kernel might take some time to context switch to catch it, context switching requires saving all registers, and restoring them, and registers have exploded in size over time (e.g. with AVX-512 you need to save quite a bit of memory), then the kernel notifies the application, which needs to do something with the key press, like scheduling a render into a frame buffer, etc.
So there are just quite a bit of bounces from here to there in the system, most of which deal with memory latencies, and memory latencies is the part of the system that hasn't been getting much faster over the last 30 years.
I've dropped the iphone dozens of times. I should stop doing that. I guess that if I had been more careful, i wouldn't have had to change anything, except for the battery (the old battery was "fine", ~65-70% capacity, but given that changing it takes 15 min and 20$, and makes the phone feel like brand new, it is a change that I happily do). Can you comment on the battery life of your 2014 HTC phone after 6 years of use? What kind of battery does it have ?
No? Models are useful for making predictions.
If somebody like the POTUS tells you that nuking thunderstorms would be great against climate change, you don't have to just take their word for it. You can input that into your climate change model, and it will tell you how much of an impact this will have, and whether the impact is good or bad.
The difference between a better model and a worse model is that the better model will agree better with reality.
A shitty model, like the one POTUS is using, might tell you that nuking all thunderstorms would be great. Then we go ahead and do it, and we all die.
A better model, like the mental model that every 14 year old child that starts studying physics and radiation has, might tell you that nuking thunderstorms is a pretty bad idea that would kill us all due to dozens of reasons.
Given that we cannot make accurate predictions today of what the weather tomorrow will look like. If you want to predict the 50 year impact of more subtle changes like, e.g., covering the Sahara with black mats, you need a pretty good model to get an output that isn't multiple orders of magnitude off.
So..... what do we expect from better climate change models? Avoiding the apocalypse to begin with. Worth every penny.
I wish that after druid becomes production ready you'll pick it up again.
The coolest thing about Xi is that some have attempted to make it a vim replacement, others an emacs replacement, etc. I wish it becomes a framework that can be used to build better text editors in general.
Define Hella fast.
If you want 16ms text rendering (~60 Hz) you pretty much need a GPU today. If you want 8ms (120Hz) text rendering, there is just no CPU that can handle it today with an OS running next to your text editor doing other stuff.
The whole point of Xi was being able to edit huge files (Tb size) on 8k displays at over 120 Hz, and being able to resize the screen and scroll, resize text, with great fonts, without any delay or sluggishness.
Xi delivered in some of those things, and druid delivers on some of the others.
But essentially, there is no system today where you press a key and that key appears on your screen in less than 8ms. Xi achieves ~16ms on the right platforms - not the fastest but much faster than most text editors.
The idea behind Xi was to preserve that as the editor got more features, like syntax highlightning, and it did.