Weekend Discussion: How Concerned Are You If Your CPU Is Completely Open?

[torsionbar28]

As a data point my Blackbird w/ v2 4-core CPU idles at ~30W. Newer kernels + the v2 chip really do reduce that idle power use.

That's impressive. I'm seriously considering ordering the same, Blackbird w/ v2 4-core. Drop my spare Rx460 into it, and maybe a SAS card. What distro are you running? And have you found any common software that runs poorly or not at all? I know VirtualBox is a no-go, but I can move that somewhere else. Pretty much all the standard desktop FOSS stuff works well on there? LibreOffice, Firefox, Thunderbird, Java? How about Handbrake and Ffmpeg? Blender? Its real tempting at the current price point, but there's so few reviews out there. Linux on POWER is established in the server space, but it's hard to tell what works and what doesn't from a desktop apps perspective. I want something that works, not something that almost sort of works.

[madscientist159]

That's impressive. I'm seriously considering ordering the same, Blackbird w/ v2 4-core. Drop my spare Rx460 into it, and maybe a SAS card. What distro are you running? And have you found any common software that runs poorly or not at all? I know VirtualBox is a no-go, but I can move that somewhere else. Pretty much all the standard desktop FOSS stuff works well on there? LibreOffice, Firefox, Thunderbird, Java? How about Handbrake and Ffmpeg? Blender? Its real tempting at the current price point, but there's so few reviews out there. Linux on POWER is established in the server space, but it's hard to tell what works and what doesn't from a desktop apps perspective. I want something that works, not something that almost sort of works.

This answer any questions? Screenshot grabbed (and this post typed) from one of the larger workstations here in the office, running Debian Buster with a Navi card... Packages were installed via standard apt-get, nothing fancy. Chromium does require an external repository, but Firefox does not -- Google has yet to play ball with the community on merging support upstream, so it's maintained out of tree in Ungoogled form for now. Probably no great loss to our main audience, since they generally prefer the Ungoogled form anyway...

[Terrablit]

It has in fact the power to end the ISA war... because anyone who implement is would be standard conform to run your WASI app... and in my point of view in high performace.

In particular, please stop saying this masturbatory fantasy. It's creepy, and it has no basis in reality or science. Like, it's the kind of thing you encounter in a dark underground cave as a hobbit on a quest to throw a ring in a volcano. Performance of an application will always be affected by the CPU it's running on. Even if WASM+WASI eventually gets infinitely close to to "native" performance, that's still native CPU performance. Meaning that native performance on Intel vs AMD vs POWER vs ARM vs RISC-V will be different for different workloads.

No language or runtime will make a pentium 4 offer performance comparable to a Ryzen 9. Similarly, the last POWER benchmarks performed extremely well in multi-threaded workloads, but lost out on single-threaded benchmarks. And ARM servers can't compete on single-threaded benchmarks, but are cost-effective and power efficient. Not only do CPUs have a limited number of instructions per second that they can execute, but some instructions are more beneficial to a workload than others. Despite that, if you've got the (infinite) resources to design for it, any of these platforms would be a good investment. There's a strong argument that if your server app depends heavily on single-core performance, it's not properly designed to scale. But if you've got a sloppy application in your stack, x86-64 is the way to go.

Having a cross-platform compilation target in 2020 won't change this any more than the JVM or CLR did over the last 24 years. Not to mention that we already have LLVM and GCC that can compile multiple languages to actual native machine code for multiple ISAs and there's still ISA competition. Unless someone comes out with a *new* CPU that's 2x the performance of others and maintains or grows that lead, there's always going to be competition.

ok then tell me why so many experts are so happy about WASM+WASI ?
just to quote one:

" Solomon Hykes @solomonstre If WASM+WASI existed in 2008, we wouldn't have needed to created Docker. That's how important it is. Webassembly on the server is the future of computing. A standardized system interface was the missing link. Let's hope WASI is up to the task! https://t.co/wnXQg4kwa4 "

sounds like it is more than just a faster javascript...

Half of the "experts" quoted in that article are famous because of javascript. Npm and node experts, bruv. Npm in particular is a massive shitshow to the point that I'd immediately be skeptical of things I actually liked if npm people also liked it. I could be eating cookies at the office and be told that it was baked by npm. I'd just set the half-eaten cookie down and walk away.

And I didn't say it's a faster Javascript. It's just in the land of Javascript, WASM is super-fast. In that field, it's a game-changer. Outside of there? Not so much.

The Mozilla quotes are about extending the reach of WASM. Which is good because maybe it'll save us all from javascript packages on npm. They're pretty good about being realistic when talking about it.

Docker advantages are partly about portability, which WASM does offer, immutable environment, which WASM doesn't offer on its own, and security, which is still up in the air. We'll see what happens when the hackers get to it. But not needing to create a project because you have technology that would have stopped you from starting doesn't mean that it replaces the other project. So his quote is just hyperbolic praise.

People talking about "near native" and "close-to-native" performance are either (1) talking from the perspective of javascript or (2) pitching the same optimism we've seen before with the JVM, the CLR and a hundred other proprietary runtimes. It was as much of a pipe dream then as it is now. As an example, you quoted this:

""miner uses WebAssembly and runs with about 65% of the performance of a native Miner.""
source: https://www.forcepoint.com/blog/x-la...nd-webassembly

Wikipedia:"While WebAssembly was initially designed to enable near-native code execution speed in the web browser, it has been considered valuable outside of such, in more generalized contexts.[57][58]"

https://webassembly.org/docs/non-web/

https://github.com/WebAssembly/desig...ster/NonWeb.md

i think with future optimizations we can expect more than 65% performance compared to native assembler ISA...

Thanks for saving me the time on finding a WASM benchmark. 65% of native performance isn't near-native performance. I could walk 65% of the way to China without actually being remotely close to the border for days. There's still 1/3 of the distance left. We only talk about things being near when the remaining distance is relatively insignificant.

There are articles going back to 2007 with JVM and CLR getting better numbers on different workloads. Sometimes they actually match, but you'll also occasionally see them be 2-3x slower. Benchmarking is a game that's easy to stack with synthetic tests written by people who are usually not experts in all the languages they're using. Not to mention that many times there's a library or VM variant that runs significantly faster that's not being used in the test. Finding new benchmarks is hard. I remember a benchmark git repo but I can't find it at the moment, so the Benchmarks Game is the most recent source I've found through googling.

https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/csharpcore-gpp.html

That shows much better performance on average from C# than 65%. Java comparisons are there, too, but I think the Java stats are lower than they should be, since I don't think they're using the HotSpot VM. And I think the G++ compiler used in the test could use some updating, since it seems to be based on Ubuntu 9. There's bound to be some newer optimizations since then, though I don't think they'd affect the benchmarks that much.

Oh no, whatever shall we do when the "high-level languages" are getting better percentages than WASM? Once again, benchmarks are synthetic so it doesn't matter that much. Also, C++ is arguably a high-level language, too, despite compiling natively. High-level vs Low-level is a distinction that's less and less important as technology advances.

Most of us have learned the lesson that "near-native performance" is about as trustworthy a phrase as "unlimited internet", "Up to 100Mbs" or "part of a balanced diet". Don't get me wrong, WASM and WASI are good. But they're not going to solve the problems you think they're going to solve. Treat them like another tool in your belt. Not like essential oils that "cure everything" if you put a drop in your eye.

also why it is not faster? wikipedia also answered it. it is because intel ISA security bugs ...

""In June 2018, a security researcher presented the possibility of using WebAssembly to circumvent browser mitigations for Spectre and Meltdown security vulnerabilities once support for threads with shared memory is added. Due to this concern, WebAssembly developers put the feature on hold.[48][49][50] ""

IF the cpus would have no security bugs it could be much faster. with the end of the shity intel ISA this would be come a possibility.

Speculative execution mitigations are hitting everybody and every language on nearly every high-performance ISA. Intel got hit hard, yes, but they're not the only vendor with a black eye from this. Not every CPU has every vulnerability, but any of them that does speculative execution has at least one. These mitigations are being baked into the OS. Also, it's relevant that I pointed out ages ago that security will be a huge obstacle to "near-native performance" for anything that has to run in a browser. Because browsers regularly encounter malicious code. This isn't going away anytime soon regardless of ISA, and WASM won't fix this. It's in the same boat as everyone else, but it's a much more valuable attack target.

Also relevant is these mitigations are also being implemented in native code. For example, database engines are affected by this. This very site has an article about it (https://www.phoronix.com/scan.php?pa...ltdown-2&num=9). So both native and WASM performance are going down because of this, and WASM still can't top 65% in comparison. Good thing you think 65% is "near-native". We treat "native performance" as the maximum performance limit (i.e. 100%). In the same way, I guess a 65% grade is a "near-perfect" grade.

Caveat: I'm sure you can find a benchmark that gives you a higher number than 65%. Benchmarks vary. The point is that there are clearly scenarios that aren't offering "near-native" performance, so we should stop using that to describe the current state of affairs. WASM isn't really offering better performance than its competition once you take it out of the browser and onto the desktop/server with WASI. Everyone has near-native performance as a goal, but it's rarely the reality unless you're doing native compilation.

You can't win this, but at least I'm enjoying watching you try.

Probably not. They don't seem to understand the concepts well enough to recognize what they don't know. But arguing this point isn't about convincing them, but about providing a more factual narrative for anyone else who reads this. It's easy for lurkers to mistake passionate people as being right and pick up cancerous ideas and FUD in a vacuum. Hopefully this will encourage them to read up on their own, instead.

I can also have a bit of fun with ridiculous metaphors while I'm at it. I'm honestly not sure I would have bothered if he hadn't started with conspiracies and laying into other people. People who rage against the machine in FOSS and hoard conspiracy theories tend to have underlying issues and massive confirmation bias. Direct engagement isn't rewarding in any sense.

It occurred to me that qarium is probably confusing low-level with low-overhead. In fact, even high-level abstractions can be efficient, if they're well-aligned with what you're trying to do. And, of course, low-level interfaces can be used inefficiently, if by a lazy, or unskilled developer.

As an aside, because developer laziness tends to increase with experience, we tend to shy away from low-level, unless we know we really need to go there.

Exactly. There's some obvious confusion about low-level. WASM clearly doesn't have hardware acceleration for all its code. Most code doesn't need dedicated accelerators in the first place. But it's got a small scope and a simple design intended to get in the way as little as possible. Also, as with node, they're developing APIs in native code that can be called from the runtime. But JVM and CLR do that, too.

WASM+WASI is nice, but the rhetoric is similar to what we heard about every other cross-platform initiative. It's possible they'll meet the hype eventually, but it's not there, yet. Despite that, if you're writing apps in node, being an early adopter is promising. And I love the potential to not need Javascript for frontend work.

There's a lot to be said about taking a higher-level language when you can. Productivity is often more important than performance until the project develops to the point where the scales shift. Having the computer do work for you is nice.

[Terrablit]

This answer any questions? Screenshot grabbed (and this post typed) from one of the larger workstations here in the office, running Debian Buster with a Navi card... Packages were installed via standard apt-get, nothing fancy. Chromium does require an external repository, but Firefox does not -- Google has yet to play ball with the community on merging support upstream, so it's maintained out of tree in Ungoogled form for now. Probably no great loss to our main audience, since they generally prefer the Ungoogled form anyway...

Thanks by the way for talking about POWER, and for all the work Raptor does with POWER in general. I love reading about the state of POWER on the desktop. Unfortunately, the price point puts it further down on the list when I get disposable income. But I'm still going to keep watching it, and it seems to be getting more affordable every time.

[qarium]

It's possible they'll meet the hype eventually,

for me it is a clear case of the hypothetical performance of WASI WebAssembler the problem is NOT "WASI WebAssembler" the problem is broken ISA and security bugs in the isa.

IF for example we fix the ISA in a Open-source and patentfree CPU and FLOSS "ISA" without security bugs like "Spectre and Meltdown" "WASI WebAssembler" could be much much faster.

you claim it is the problem of "WASI WebAssembler" but it is clearly NOT. the problem is broken ISA designs like INTEL-ISA

if we fix the Intel-ISA-monopoly by break the monopole and come up with secure and opensource and patent free ISA cpu designs then we can make WASI WebAssembler much faster.

[coder]

other people say the same: https://www.heise.de/forum/heise-Dev...34226468/show/

google translate: " The design of WebAssembly has a completely different direction. Java bytecode was originally designed for an interpreter. The ByteCode is also very high level. WebAssembly is designed to be validated quickly and to be converted directly into machine code. It also has no firm ties to a language.
You could say you learned from your mistakes."

he point out that JAVA is high-level he even call the java bytecode: VERY HIGH LEVEL....

he also points out that WASI WebAssemble is "low level" : "WebAssembly is designed to be validated quickly and to be converted directly into machine code."

Uh, so you're seriously quoting some random poster on another forum? How do we know that's not even you?

[coder]

for me it is a clear case of the hypothetical performance of WASI WebAssembler the problem is NOT "WASI WebAssembler" the problem is broken ISA and security bugs in the isa.

I just want to point out that C was originally designed as a portable alternative to assembly language. From the wikipedia page:

By design, C provides constructs that map efficiently to typical machine instructions and has found lasting use in applications previously coded in assembly language.

Maybe, instead of using web assembly for non-browser apps, people could write and distribute their software in C. Then, compilers could translate it into actual native machine code.

With some kind of low-level pseudo-assembly language, what I'd be concerned about is information loss due to premature conversion of the program to a low-level representation. In that case, you want to keep a higher-level description of the program, for as long as possible. Otherwise, the JIT compiler might ironically have to do a lot more work to reconstruct details of the program from a low-level representation, without which it cannot optimally compile the program to fully utilize the native hardware.

Far out, huh? Those cats in the 1970's sure knew what they were doing!

[lkcl]

With some kind of low-level pseudo-assembly language, what I'd be concerned about is information loss due to premature conversion of the program to a low-level representation.

we've run into this in the 3D driver development on Libre-SOC. LLVM-IR was the basis for SPIRV initially and it got changed significantly to support predication, vec2-4 datatypes, and vectorisation and more.

all other frontends (clang etc) *assume* scalar loopss because that's what you get with standard programming languages and consequently there is a heavy focus on autovectorisation (turning scalar into vector).

unfortunately if you start from the wrong port / point in various uses / copies of LLVM that are out there you end up with one that *loses* the explicit vectorisation but otherwise maintains "topological correctness" and have to run the autovectoriser pass to get the parallelism back.

unfortunately not only is critical information lost it's also horribly inefficient and causes real time delays in shader compilation.

i am simplifying and leaving some stuff out, however wanted to emphasise that yes this can happen.

Far out, huh? Those cats in the 1970's sure knew what they were doing!

[qarium]

Uh, so you're seriously quoting some random poster on another forum? How do we know that's not even you?

what if the account "coder" on phoronix.com is just fake account of qaridarium ?

[torsionbar28]

This answer any questions?

Beautiful, thank you sir.