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

[MaxToTheMax]

hol' up, these are overclockable? Is there anything like a cTDP you could revise upward and get an automatic overclock while still having it idle normally?

[madscientist159]

Yep, definitely overclockable! That's one of the perks of a fully open firmware stack -- complete control of the clock controllers comes along for the ride.

Check out https://wiki.raptorcs.com/wiki/POWER9/Overclocking for more info. Idle clocks and power aren't really affected by this overclocking method, just the turbo clocks...

[MaxToTheMax]

So then that segways into my other concern about needing to use dinky server-oriented CPU coolers. Are there AIO options? Would an Asetek cooler provide full coverage of the heat spreader if I could find or make an adapter bracket? Asetek coolers have a circular cold plate which I believe has a diameter of 50 mm (based on fakey pixel measurements of two different pictures, I got a diameter of 51.3 mm, so it's probably 50.) EDIT: the actual microfin area was measured as a 30x24mm rectangle by Steve from GamersNexus. If the die is smaller than that and reasonably centered it should be OK to use these coolers.

(BTW, an Asetek adapter bracket would probably be a good seller. They are very widely available with lots of different rebrands and radiator sizes.)

[qarium]

I'll Ignore the tin foil hat conspiracy nonsense, beyond pointing out that Java came from Sun and both the OpenJDK and .NET Core are actually pretty safe to use. Besides, the real fun comes next.

Wat.

Where on earth did you get the idea that intermediate byte code in a VM can ever offer native speeds? Have you even used either of these? Your arbitrary distinction between high- and low-level bytecode is just bad and wrong, man. To give you a simile, it's like you wrote a vampire romance fanfiction but decided to make them glitter and brood over unattractive teens instead of suck blood. The constraints of the web don't allow "low-level" bytecode. And, while WASM is usable outside the web, it was still designed to be used on the web. Which means it's got built-in security constraints. In short, it's not "lower-level" than JVM or CLR. It's simpler. And things like this don't stay simple for long.

You vastly underestimate the scope of writing a VM for portable code designed for security sandboxing and interaction with Javascript. Some operations and benchmarks will get close to native speeds because there's very little to sandbox or rewrite. The same thing happened with the JVM and CLR. But others will clearly show the difference that always exists between native code and any type of intermediate representation (IR). In many cases the performance sacrifice is worth it. But it's never worth pretending it doesn't exist. So please don't bullshit. It's our responsibility as adults to make sure that uninformed people don't see this nonsense and think it's true.

EDIT: Hell, In my excitement I even forgot to point out that the Vulkan vs DirectX11 comparison is wrong. Vulkan is most equal to DirectX12 and not the previous generation, and DirectX12 offers pretty much the same amount of fine-grained control as Vulkan. It's just got baggage for interop with previous APIs and is locked to Windows. It also has non-graphics stuff in the API. It seems you get this stuff wrong a lot. Please never talk about whether an API is high- or low-level ever again.

in the GPU world it was like this: Glide(3DFX) low level api-3DFX-only-->high level api's like OpenGL/DirectX9/11 and then it was cross-companie low level API Vulkan (yes extra for you DX12 is also low level you are good boy you get the DX12 fish...).

ok on the CPU side for most of the time you have the Intel monopile i386 assembler or AMD64 assembler and both bytecode examples you make: OpenJDK and .NET are NOT designed to be low level. they are high-level APIs like openGL/DirectX11 but webassembly has the target to be as low level API as possible. means the design goal is not to be a SUN java or Microsoft -net or whatever instead the design goal is to be "Vulkan"

what is the different of low level or high level in the webassembly meaning in my point of view: a high level one implements functions what is not 100% accelerated by hardware this was the way the java and .net people did it. but a low level one instead only implement functions what is 100% accelerated by hardware.

because of this the end-result is near nativ assembler speed. why java and .net never could do the same than webassembly both SUN and MIcrosoft tried to make money out of this because of this it never was a solution to end the CPU-ISA war. Webassembly instead is made to end the CPU-ISA war. and Intel is inside of the webassembly boat.

means the CPU-ISA-WAR already endet because AMD won over Intel... intel has no chance to use their closed ISA to win over AMD... because of this the ISA war endet.

[Terrablit]

what is the different of low level or high level in the webassembly meaning in my point of view: a high level one implements functions what is not 100% accelerated by hardware this was the way the java and .net people did it. but a low level one instead only implement functions what is 100% accelerated by hardware.

I guess you can use the wrong definition as a justification for saying the wrong thing. But that doesn't make you right, it just makes you obtuse. Deliberately redefining a term to get away with saying things wrong just makes communication more difficult. You don't win a merit badge for misusing vocabulary. You just waste experienced people's time by requiring them to navigate whatever mental bullshit you came up with, and you confuse the inexperienced. Literally you're a thief of time and joy by having incorrect personal definitions for things that have common definitions and forcing them upon others. That's valuable brainpower I could have used for literally anything else. Even watching The Price is Right would have been more fruitful than the time I wasted reading what low level is "in [your] point of view".

Low-level isn't about "hardware acceleration". Low-level languages existed prior to consumer acceleration hardware. And high-level languages implement hardware acceleration primitives. The "level" of a language or runtime is about the code representation having minimal abstractions over the chipset capabilities. Security and sandboxing make it impossible to be "low-level bytecode". Cross-platform capabilities make it difficult to be "low-level bytecode". And the distinction between low- and high-level is even more indistinct by things like microcode. Like how AMD recently implemented PDEP and PEXT CPU instructions in microcode, but they run so slowly that you're better off not using them. Evolving language standards also inevitably push nearly every language and runtime further away from the base hardware towards high-level territory. The distinction gets blurrier every day, but it's still clear enough to know that embedded browser runtimes aren't going to be implemented at a lower level than a desktop/server runtime because of the massive security risk that would entail. Downloading a desktop application to run has much less risk than visiting a webpage and letting them run anything they want.

WASM is not low level. And it's not going to offer a significant, consistent performance improvement over existing runtimes. WASM isn't going to magically leapfrog 24 years of VM and runtime development with the additional constraint of frequently dealing with deliberately hostile code. It is, however, better than Javascript. Just accept that and move on.

[qarium]

Yep, definitely overclockable

can you tell me if POWER9 already supports WASI – WebAssembly System Interface ?

any benchmarks yet ?

[qarium]

I guess you can use the wrong definition as a justification for saying the wrong thing. But that doesn't make you right, it just makes you obtuse. Deliberately redefining a term to get away with saying things wrong just makes communication more difficult. You don't win a merit badge for misusing vocabulary. You just waste experienced people's time by requiring them to navigate whatever mental bullshit you came up with, and you confuse the inexperienced. Literally you're a thief of time and joy by having incorrect personal definitions for things that have common definitions and forcing them upon others. That's valuable brainpower I could have used for literally anything else. Even watching The Price is Right would have been more fruitful than the time I wasted reading what low level is "in [your] point of view".

Low-level isn't about "hardware acceleration". Low-level languages existed prior to consumer acceleration hardware. And high-level languages implement hardware acceleration primitives. The "level" of a language or runtime is about the code representation having minimal abstractions over the chipset capabilities. Security and sandboxing make it impossible to be "low-level bytecode". Cross-platform capabilities make it difficult to be "low-level bytecode". And the distinction between low- and high-level is even more indistinct by things like microcode. Like how AMD recently implemented PDEP and PEXT CPU instructions in microcode, but they run so slowly that you're better off not using them. Evolving language standards also inevitably push nearly every language and runtime further away from the base hardware towards high-level territory. The distinction gets blurrier every day, but it's still clear enough to know that embedded browser runtimes aren't going to be implemented at a lower level than a desktop/server runtime because of the massive security risk that would entail. Downloading a desktop application to run has much less risk than visiting a webpage and letting them run anything they want.

WASM is not low level. And it's not going to offer a significant, consistent performance improvement over existing runtimes. WASM isn't going to magically leapfrog 24 years of VM and runtime development with the additional constraint of frequently dealing with deliberately hostile code. It is, however, better than Javascript. Just accept that and move on.

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...

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.

[coder]

So please don't bullshit. It's our responsibility as adults to make sure that uninformed people don't see this nonsense and think it's true.

Heh, this made me smile.

I guess you can use the wrong definition as a justification for saying the wrong thing. But that doesn't make you right, it just makes you obtuse. Deliberately redefining a term to get away with saying things wrong just makes communication more difficult. You don't win a merit badge for misusing vocabulary. You just waste experienced people's time by requiring them to navigate whatever mental bullshit you came up with, and you confuse the inexperienced. Literally you're a thief of time and joy by having incorrect personal definitions for things that have common definitions and forcing them upon others. That's valuable brainpower I could have used for literally anything else. Even watching The Price is Right would have been more fruitful than the time I wasted reading what low level is "in [your] point of view".

Classic.

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

Low-level isn't about "hardware acceleration".

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.

[qarium]

You don't win a merit badge for misusing vocabulary.

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."

[qarium]

WASM is not low level. And it's not going to offer a significant, consistent performance improvement over existing runtimes.

""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...

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.