sylware

The javascript web is. Restore the interop with noscript/basic HTML and it will lean towards sanity, something lost a few years ago.

There will be RISC-V implementions specific to many use cases of CPUs.

I have to admit we were more in the "desktop" use case, then the 7GHz (I don't know how they will manage to keep the backend reasonably fed without severe speculation though).

Well, everything is open source, I have a partial and very limited (but currently enough for my needs) linker for x86_64 and RISC-V 64bits (but written in plain and simple C which compiles with tinycc and cproc/qbe!).

I even have an ELF capsule for executables (for x86_64, written in assembly).

So it is out there, but not "tidy" (aka a wip messy tarball), as I said, I am not sorta sure about how to handle the in-process loader, which is beyond simple, but I still believe I can make it even simpler (yeah, not more gigantic external "interpreter"/"loader).

Once I am satisfied, I'll ship that to a nicely tidied GIT repo (but with support of noscript/basic HTML browsers, unlike ... you know which ones...).

This is the wrong end of the issue. ELF for executables and dynamic libs is obsolete on modern hardware (same for microsoft PE+).

I am now using for most of my projects a exe/dynamic lib format of my own. This file format is so miminal a simple RFC will suffice. BUT, I will need to build dynamic libs which are system interfaces (for instance userland drivers like mesa) with this file format: problem, c++ and its runtime (and probably other similar languages with their runtimes)... as usual...

Well, I am still removing stuff from my file format, because I think this is not yet "minimal and enough" on modern hardware architecture (I think I have still too much complexity in the tracker of loaded dynamic libs).

That one of the reasons which makes noscript/basic HTML a good thing (there are other additional reasons, one of the main is interop with small web engines, aka not "whatwg cartel").

Slap a 1D or simple 2D document (simple table), give some love to those ids/names, should do wonders.

The real core of the issue is actually the complexity/size and core design of media container/codec file formats.

Last time I read something about Zen6 it was 6GHz.

So I guess the IBM stuff is "server slow" then.

I wish RISC-V microarchitectures would get access to 2nm silicon processes, because RISC-V at 7GHz... yummy.

So why the 2nm x86 chips are clocked so low?

Why couldn't they be 6GHz? x86_64 ISA did it again?

That said IBM should add RISC-V support.

If Apple does design a RISC-V frontend to their MX microarchitecture... ARM better keep those ISA license fees close to zero.

lean from a technical point of view: size and complexity. That would include the SDK, namely the complexity of the syntax of used computer language (for instance excluding de facto c++ and similar), the build system, the amount of dependencies, etc.

Yep, you compare chips on the same level of silicon process.

I was curious to see how far RISC-V still have to go from a microarchitecture stand point, but even in the same silicon process level, there are other things to take into account: the RISC-V compiler support, and something which is really new: since RISC-V is a non-IP-lock worldwide standard, assembly writting is much more a reasonable thing.

Wonder how it will fare when infering frontier models or 10T+ parameters.

For coding, in order to get "quality" results, you will need those frontier models with their whole weights.

Missing the silicon process.

That's why _LEAN_ open source is really required, and that includes the SDK.

Maybe a Zen microarchitecture with a RISC-V/RVA front-end?

While thinking about it, if NVIDIA or SAMSUNG go performant RISC-V CPU micro-architecture, will "probably" change the world.

Nah.. people will start to check for 'watermarks' first...

Indeed, if NVIDIA or SAMSUNG go super performant RISC-V implementations, things are very probably going to change.

In France, we have a bed story for children related to exactly that: "Pierre et le loup" (aka your "crying wolf").

It may be a EU wide tale.

Have a look at cproc/qbe, 70% of gcc -O3 speed (at the time I did CPU intensive benchmarks), for hardly a few % of gcc code. And it is not even using that grotesquely and absurdely complex c++ syntax.

Is fastmail blocking self-hosted SMTP servers without DNS like gmail.com? (email addresses with IP literals are stronger than SPF).

Is fastmail gated with 'whatwg cartel' web engines like gmail.com?

Then RISC-V would need something like they did for open source software (in countries with barbaric IP), some sort of pool of defensive IP.

Because, if you look at the current trajectory of RISC-V micro-architectures: they will be competitive, so current hardware big tech will try hard to shut them down. If they are already at Zen3 performance... I run Zen2 and it's already beyond than enough (I miss AVX512 extensions though, hope we'll get often RVA cache line vector instructions on RISC-V).

Look at qualcomm already buying what seems to be a very good RISC-V microarchitecture, wonder what they will do to it (usually, they let it die slowly forcing their good engineers to work on something else).

The right way(TM) would be for ARM to "drop its ISA" and become a microarchitecture designer able to decode and run RISC-V ISA.

Intel and AMD should too. The world would be basically competing micro-archs all with high compatibility at machine code level.

And it seems nobody has been addressing the elephant in the room: x86 is an horrible ISA for a modern CPU, much more worse than RISC-V/ARM. It is only because AMD/Intel throw tons of money with tons of brains to make that horrible ISA performant AND because they are hogging the production capacity of the best silicon process.

There is zero wonders here.

Allright, you did describe a monstruous IP mine-field. No way anybody could reasonably use anything else than RISC-V.

So RISC-V is 'dragged down' because it cannot access the best silicon process (hardware big tech is hogging production capacity... how convenient...)

Then if I understood well what you said: the main bottleneck for many of those RISC-V microarchitectures is the access to the best silicon process. (ofc, they will have to optimize them for this node process)

All on latest silicon process?

I guess this would be orders of magnitude more horrible with x86_64?

Are they on the latest silicon process?

Because, without neglecting the micro-architecture, we all know how critical the silicon process is for high-end performance.

This guy is weird: there is no perfect ISA, only compromises and tradeoffs. He is looking for _his_ perfect. Won't happen, unless lucky, namely your perfect aligns with RISC-V tradeoffs. There are also sweet spots, and I am writting RISC-V assembly almost every day and that "hits" them often. I currently use at 99.99% the core ISA (I have a few muls and divs here and there). I don't even use the bit manipulation extension...

There are millions of RISC-V chips out there. Performant microarchitectures are getting there, but the access to the latest silicon process is gated by the other ones, hogging production capacity (and they probably don't want RISC-V to "get there"...).

And most of all, hardware manufacturer/designers won't have a lawyer ringing at their door: this is so much critical, this will make them tolerate a lot of RISC-V tradeoff choices they dislike.

And ofc, big mistakes WILL BE MADE AND WILL HURT BAD. Expecting anything else is thinking like a teenager.

It seems the current biggest mistake is the compressed instruction extension. It seems the complexity it adds for high performance is not worth it (arm removes the thumb instructions for reasons). I have suspicions on some microarchitectures designed around the compressed instructions (16bits) having a negative performance impact on core ISA 32bits instructions (and many compiler optimizations are friendly to the way compressed instructions are, namely the destination register is one of the source register, that due to the legacy x86_64). BTW, Intel APX something, is basically RISC-V for x86_64.......

Another aspect people tend to forget while dealing with RISC-V, many of those design choices were made for the simplest way to implement performant CPU microarchitectures. Some say thats why on 'out-of-order' CPUs, you don't want a status flag register (there is none in RISC-V).

You would need a massive amount of claude output beyond anything humanly reasonably to train a model. Namely, consuming a lot of inference resources. If you don't do that at those scale, the training will probably be quite inefficient anyways.

Then a whole industry will rise at tracking and removing those watermarks.