almostgotcaught

> For a solo dev, I'm not yet sure this is actually viable, but I will give it more consideration.

look i'm not trying to shit on your project - i promise - i know calling you out like this publically almost requires a political kind of response (i probably shouldn't have done it). i agree with you that as a solo dev you can't (shouldn't) solve this problem - you have enough on your plate making jank great for your core users (who probably don't really care about cpp).

> As I said before, basically any query builder or codegen takes some form of string generation.

i mean this is a tautology on the level of "everything can be represented as strings". yes that's true but types (as you mention are important) and all i'm arguing is that it's much more robust to start with types and end with types instead of starting with strings and ending with types.

anyway you don't need to keep addressing my complaints - you have enough on your plate.

> which is 3 months old and has 0 stars (and so I assume 0 users and 0 years of battle testing)

ah my bad i meant to link to this one https://github.com/scrossuk/llvm-abi

which inspired the gsoc.

> is there really a _better_ option which exists today?

today the "best in class" approach is swift's which fully (well tries to) model cpp AST and do what i suggested (emitting code directly):

https://github.com/swiftlang/swift/blob/c09135b8f30c0cec8f5f...

shedskin isn't actively developed ... or at least it wasn't for like 10 years https://github.com/shedskin/shedskin/graphs/contributors

> LLVM into their runtime

they're not embedding LLVM - they're embedding clang. if you look at my comment below, you'll see LLVM is not currently sufficient.

> [C++] is a royal pain in the ass to target for a dynamic FFI because of that

name mangling is by the easiest part of cpp FFI - the hard part is the rest of the ABI. anyone curious can start here

https://github.com/rust-lang/rust-bindgen/issues/778

i mean it's as prone to error as any other thing that relies on string munging. it's probably not that much slower than the alternative i proposed - because the trampolines/wrappers are jitted and then reused - but it's just not robust enough that i would ever imagine building a prod system on top of it (eg using cppyy in prod) let alone baking it into my language/runtime.

i commented on reddit (and got promptly downvoted) but since i think jank's author is around here (and hopefully is receptive to constructive criticism): the CppInterOp approach to cpp interop is completely janky (no pun intended). the approach literally string munges cpp and then parses/interprets it to emit ABI compliant calls. there's no reason to do this except that libclang currently doesn't support any other way. that's not jank's fault but it could be "fixed" in libclang. at a minimum you could use https://github.com/llvm/llvm-project/blob/main/clang/lib/Cod... to emit the code based on clang ast. at a maximum would be to use something like

https://github.com/Mr-Anyone/abi

or this if/when it comes to fruition

https://discourse.llvm.org/t/llvm-introduce-an-abi-lowering-...

to generate ABI compliant calls/etc for cpp libs.

note, i say all this with maximum love in my heart for a language that would have first class cpp interop - i would immediately become jank's biggest proponent/user if its cpp interop were robust.

EDIT: for people wanting/needing receipts, you can skim through https://github.com/compiler-research/CppInterOp/blob/main/li...

yes there is: https://wiki.python.org/moin/UsingSlots

people really don't know enough about this to be talking about it with such confidence...

> It turns out that if you have language semantics that make optimizations hard, making a fast optimizing compiler is hard. Who woulda thunk?

Is this in the article? I don't see Python's semantics mentioned anywhere as a symptom (but I only skimmed).

> shows how poorly a lot of people understand what goes into making a language fast.

...I'm sorry but are you sure you're not one of these people? Some facts:

1. JS is just as dynamic and spaghetti as Python and I hope we're all aware that it has some of the best jits out there;

2. Conversely, C++ has many "optimizing compiler[s]" and they're not all magically great by virtue of compiling a statically typed, rigid language like C++.

> Intel's compilers produce more performant / efficient code than GCC or Clang

Intel's compiler are clang forks.

> are you sure it will do anything at all? I am not. The current setup, while objectively sucks for engineers is still quite capable and it works

go back in time to before gcc - i'm 100% sure people were saying the exact same thing about borland (or whatever).

> We are so stupidly limited by our EDA tooling and infrastructure.

The problem that no one will ever solve is there's no gcc equivalent to NXT. Everything is downstream of that problem.

Did you know that there are universities outside of Europe? And that in those universities, "3 publications plus intro and conclusion for a PhD" is also called (usually) PhD by publication (sometimes it is called a kitchen-sink PhD). And my point was that that rule of thumb does not apply to theory students.

Note the italics please.

So I'm sorry you're right I'm not in expert in Europe's monopoly on the phrase "PhD by publication" but who would want to be an expert in trivial bs like that (answer: apparently you and the other guy!)

You're wrong it's been debunked that the borrow checker is any appreciable part of the compile time - Steve Klabnik actually verified it on here somewhere.

Edit: found it

https://news.ycombinator.com/item?id=44391240

It's amazing how many people on hn are experts on things they do not have the qualifications to be expert on.

> It's literally axiomatic.

You've made up some axiomatic definition of "by publication" that does not bear any resemblance to the actual definition. Consider that it's possible to

1. Submit a preprint to arxiv and have it count

2. Submit a preprint to a journal and defend before it accepted (or rejected)

3. Not submit anything anywhere and have the PhD itself count (almost all PhDs get an ORCID)

> Nobody gets a PhD by publication with 0 publications.

Do you have a PhD from a theory department? I do. You're wrong.

That's a rule of thumb for applied sciences. Plenty of theory PhDs graduate with 1 or 0 papers.

i'll never fathom why people on hn treat a post as an auto-invite for unsolicited feedback.

you're supposed to get that the cynical lens you're applying here doesn't fit - if you aren't intrinsically motivated to read this stuff then it's not for you. which is fine btw because (functional) analysis isn't a required class.

> "The material is not motivated." Not motivated? Judas just stick a dagger in my heart. This material needs no motivation. Just do it. Faith will come. He's teaching you analysis. Not selling you a used car. By the time you are ready to read this book you should not need motivation from the author as to why you need to know analysis. You should just feel a burning in you chest that can only be quenched by arguments involving an arbitrary sequence {x_n} that converges to x in X.

https://www.amazon.com/review/R23MC2PCAJYHCB

You can accomplish the same exact thing with

https://en.cppreference.com/w/cpp/experimental/scope_exit.ht...

i don't get it - if do

  int foo(int a) {
    assert(a > 5);
    int b = a * 10;
    assert(b > 50);
    return b;
  }

do you think those asserts don't "run automatically"?

> Invariants are functions that run at the start and end of every public member function

these are just runtime assertions

EDIT: how am i getting downvoted for copy-pasting literally what the article verifies?

> uses information available in LLVM (e.g. scheduling models) to statically measure the performance of machine code in a specific CPU

do people not realize that the scheduling models in LLVM are approximate? like really approximate sometimes. in fact, half the job of working on instruction scheduling in LLVM is cajoling the scheduler into doing the right thing given the approximate models.

> To emulate DL workloads without actual GPUs, we replace GPU- related steps (steps #3–5, and Step 2 if GPU-based) with simple sleep(T) calls, where T represents the projected time for each step.

This is a model (of GPU arch/system/runtime/etc) being used to feed downstream analysis. Pretty silly because if you're going to model these things (which are extremely difficult to model!) you should at least have real GPUs around to calibrate/recalibrate the model.

it's mostly upstream now, no need to dig around in their repos

https://github.com/llvm/llvm-project/tree/main/clang/tools/c...

i have no idea what your point is - same compiler, different frontend, yes that's literally what i said.

> its either CUDA or HIP, which differ widely in parts of their compilation stack.

This is an ironic comment - OpenCL uses the same compiler as CUDA on NVIDIA and HIP on AMD.

how many groups do people usually use to get a fast build (alternatively what is the group size)?

How many LOC is unreal? I'm trying to estimate whether making LLVM compatible with UNITY_BUILD would be worth the effort.

EDIT: i signed up to get access to unreal so take a look at how they do unity builds and turns out they have their own build tool (not CMake) that orchestrates the build. so does anyone know (can someone comment) whether unity builds for them (unreal) means literally one file for literally all project sources files or if it's "higher-granularity" like UNITY_BUILD in CMake (i.e., single file per object).

The quantity of people on this site now that think they understand modern GPUs because back in the day they wrote some opengl...

1. Both AMD and NVIDIA have "tensorcore" ISA instructions (ie real silicon/data-path, not emulation) which have zero use case in graphics

2. Ain't no one playing video games on MI300/H100 etc and the ISA/architecture reflects that

> but for graphics they are very solid.

Hmmm I wonder if AMD's overfit-to-graphics architectural design choices are a source of friction as they now transition to serving the ML compute market... Hmmm I wonder if they're actively undoing some of these choices...