▶ No.893076
>>893074
Pretty much this.
/thread
▶ No.893078>>893080 >>893195 >>893207
x264 is expected (Altivec doesn't get as much as love as SSE/AVX) but 7zip and timed compilations are pretty bad. Almost looks like a compiler and/or kernel problem.
▶ No.893080
>>893078
some commenters said as much
▶ No.893082>>893087 >>893099 >>893113 >>893119 >>893133 >>893164 >>893180 >>893371 >>896793
>overpriced piece of shit
>performs like crap
>it's all the compiler's fault, buy our $5000 Faceberg machine using an architecture for which no programs exist!
▶ No.893087
>>893082
>overpriced piece of shit
honestly not that bad when you consider the security advantage.
>performs like crap
>$5000 Faceberg machine
it's far more than that. Even though it was below average when compared to the high-end Intel/AMD server stuff, it's still a million miles away from "Faceberg machine"
On top of that, nobody who buys this thing is going to be on Facebook.
>using an architecture for which no programs exist!
How about the entire Debian repo?
How about the entire Fedora repo?
How about the entire OpenSUSE repo?
▶ No.893099
>>893082
How's the whether in Jerusalem?
▶ No.893103>>893116 >>893129
>2 x Intel Xeon Gold 6138
>40 cores 80 thread
>AMD EPYC 7551
>32 cores / 64 threads
>AMD EPYC 7601
>32 cores / 64 threads
>Talos II
>16 cores / 64 threads
Not too shabby
▶ No.893113>>893207 >>893371
>>893082
>Intel Intel Xeon Gold 6138
>Price: $2,748.37
>Quantity 1
>AMD PS7601BDAFWOF EPYC x86 CPU Processor Model 7601
>$4,499.99
Yeah no fuck off
▶ No.893116
>>893070 (OP)
the software is of course better optimised for x86. x86 has been a thing for years and developers have been working with it for years.
>>893103
> This isnt even my final form
https://www.raptorcs.com/content/base/products.html
There is also a 22 core cpu that will be available in the future
▶ No.893119
>>893082
>overpriced piece of shit
It's actually quite cheap for a workstation
>performs like crap
It really doesnt this isnt even the highest end cpu they will release
https://www.raptorcs.com/content/base/products.html
>it's all the compiler's fault, buy our $5000 Faceberg machine
Yes optimisation is a thing that exists and it does make the performance quite better
>using an architecture for which no programs exist!
You are not going to run windows on it you are going to run linux and most linux software is available on many architectures.
▶ No.893124>>893129
let me know when they make freedom affordable for the 99%
▶ No.893129>>893134
>>893124
Workstations are not affordable by default
Also fuck off faggot if you knew anything about not spending all your money on dragon dildos you'd afford one easily
>>893103
Also
> 7zip 16.02
Fucking February of 2016.
Of course it's unoptimised they are probably running debian stable for stability's sake.(although i dont know what software versions the debian stable repo has, debian users please correct me.)
▶ No.893133
>>893082
>buy a blobless, security-hardened botnet-resistant system
>use it for facebotnet
yeah, no
▶ No.893134>>893327
>>893129
I'm currently using Debian 9 with 7zip 16.02
▶ No.893140>>893153 >>893161 >>893177 >>893207
>>893070 (OP)
The x86 parts are way more expensive and better spec'd. Why are you spreading FUD? Seems like you have some kind of agenda....
▶ No.893153
>>893140
massive OPsexuality, like other mental disabilities, is not an agenda
▶ No.893161>>893167
>>893140
>FUD
seems like you have an agenda. rust must run like shit on power
▶ No.893164
>>893070 (OP)
>compering performances
>on different architectures
>with software that doesn't have 30 years of optimization for POWER
WEW
Compare what's comparable.
>>893074
This
>>893082
Intel/Amd please GTFO!
▶ No.893167
>>893161
>rust must run like shit on power
it's like runny shit everywhere
▶ No.893177
>>893140
How butt blasted do you have to be to confuse the messenger with the message? Did your brain melt when you saw the results?
▶ No.893185>>893192
>>893070 (OP)
A little bit:.
4 core 90W TDP
8 core 160W TDP
▶ No.893187>>893211
I hope theres a patch for gcc floating in the deep depths of IBM that could allow its power to be properly utilized.
▶ No.893190>>893207
>>893070 (OP)
>16-core POWER9 system getting outperformed by much more expensive 32 and 40 core x86 systems
>Oy vey, POWER BTFO! Buy more Management Engines, goyim!
nice try
▶ No.893192
>>893185
It would be nice if they released the clock speeds for each CPU option.
▶ No.893195>>893203 >>893207
>>893078
>Altivec doesn't get as much as love as SSE/AVX
This, and the AltiVec unit on POWER9 is likely underpowered anyway, since this is a processor made explicitly for datacenters, not HPC.
>timed compilations are pretty bad
likely due to the spinning rust HDD
▶ No.893203
>>893195
If the benchmarks aren't made in tmpfs, this guy is a massive retard.
▶ No.893207>>893239 >>893679
>>893113
>>893078
>>893140
>>893190
This, it's nearly as dumb as that thread >>890426 where OP points to one outlier test out of an entire benchmark suite to suggest POWER is swamped by a cheaper ARM server system, when the overall benchmark results say quite the opposite.
OP, trolling is the national sport of imageboards, but you have to try harder, 4/10.
>>893195
>the AltiVec unit on POWER9 is likely underpowered anyway, since this is a processor made explicitly for datacenters, not HPC.
Maybe things have changed since the PPC G4/5 days, but wasn't Altivec always MASSIVELY overengineered compared to every other ISA's vector coprocessors, eating up something like 1/3rd of the floorplan die space?
▶ No.893211>>893227 >>893274 >>893710 >>896797
>>893187
GCC is shit, and that's even truer in the case of fringe ISAs like POWER. IBM maintains its own proprietary compiler, XL, that is MUCH better.
▶ No.893227>>893233 >>893235 >>893498
>>893211
Does anyone know of any GPLv3 compatible compilers with potential for being good that's NOT written in C++?
▶ No.893233>>893235
>>893227
It doesn't have to be complete, only have a sane design.
(sage for self-reply)
▶ No.893235>>893253
>>893227
>>893233
Do you realize that what you're asking for is meaningless.
▶ No.893239>>893256
>>893207
>where OP points to one outlier
I pointed to it because ARM is shit. You fags are so sensitive to a fucking CPU architecture. You need to grow a pair of balls and get over it. The fact that the AMD and Intel CPUs cost about as much as this machine would suggest it did okay, but some of you can't even handle that and are crying because of a fucking benchmark. Don't attach yourself to hardware and you can see how silly some of you sound.
▶ No.893253>>893255 >>893261 >>893687
>>893235
I want a C compiler that:
* is licensed under the GPLv3 or later with the runtime exception, or under a GPLv3 compatible license, such as GPLv2+, MIT, Apache License v2, 3 clause BSD[1] …
* is written in a language that doesn't obscure what's really happening, such as C++, Perl, Rust …
* is much easier to grasp than both GCC and Clang
* produces good code
* transpiles other high-level languages into C
* compiles C to machine code in many stages, to make the architecure of the compiler easier to understand
* has documentation under the same license as the software (or if it uses the GNU FDL, it must not use any of the options)
* is not mainly developed and sustained by a corporation with monetary interests in tivoization and walled gardens (looking at LLVM and Apple)
[1] https://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses
▶ No.893255
>>893253
<I want a C compiler that:
meant
<I want a compiler that:
▶ No.893256>>893260
>>893239
Your thread was clickbait, attempting to stir shit by taking an article that said "POWER is the fastest RISC, ARM's server efforts are respectable" into "POWER outperformed by cheapo ARM server".
>The fact that the AMD and Intel CPUs cost about as much as this machine
No, they cost MORE than this machine.
A fair comparison would be either similarly priced rigs (for current value), or similarly configured rigs (for future value once economies of scale settle), both using decent compilers like XL for POWER and ICC for Intel.
▶ No.893260>>893263
>>893256
>"POWER outperformed by cheapo ARM server".
That ARM server board was $3k dumbshit. It should have lost in every benchmark too.
▶ No.893261>>893284
>>893253
>* is written in a language that doesn't obscure what's really happening, such as C++, Perl, Rust …
>* is much easier to grasp than both GCC and Clang
>* transpiles other high-level languages into C
>* compiles C to machine code in many stages, to make the architecure of the compiler easier to understand
read a book nigger
▶ No.893263
>>893260
One out of 7 otherwise lopsided tests isn't a loss, it's a fluke obviously caused by poor implementation.
▶ No.893274>>893281 >>893692
>>893211
>use Power, it's all open and secure and not botnet
>lol, use the proprietary compiler which surely won't insert backdoors into everything
Way to defeat the purpose
▶ No.893281
>>893274
Security versus performance has always been a tradeoff, now more than ever with the need for speculative execution to keep IPC growing.
▶ No.893284
>>893261
>C++, Perl and Rust are great languages
>GCC and Clang are easy to understand
>who needs a simple suckless compiler anyway where hiding backdoors is hard
>Unix philosophy is bad because it hurts my company in the shekkels
>"read a book nigger" is a valid counter argument
t. Pajeet
▶ No.893321>>893371 >>893692 >>893694
Talos II Basic Bundle - Dual CPU 8 Core
$3,365
AMD EPYC 7551 CPU ONLY
$3,700
AMD EPYC 7601 CPU ONLY
$4,500
Considering this Mobo + CPU bundle competes with a $3,700 CPU this is actually a great price.
Media encoding falls short, someone will have to tune the compiler like x86 has.
I am not disappointed at all, this is actually way better than I thought, unless you're doing media encoding perf per dollar BTFOs x86.
▶ No.893327>>893468
>>893134
And according to the website yes that is the latest stable.
They should have used unstable to see what would happen with a newer kernel and software.
▶ No.893371
>>893074
Yea basically this, I look forward to moving most of my stuff over to a completely free platform when mine arrives next month since I ordered mine quite late.
>>893082
>overpriced
Its a bargain compared to buying an OpenPower server since the only decent ones come with a bunch of P100/V100 GPUs which jacks the price up astronomically and I don't think Power9 systems are available on the IBM cloud yet.
>>893113
>>893321
Also this, holy fuck these comparison benchmarks are a joke.
▶ No.893382>>893405
Any word on whether the pricing will go down in the future? I'd love to show my support but as a poor college student I can't justify spending over $2k on a desktop...
▶ No.893405>>893418 >>893479 >>893481
>>893382
Why does a college student need that much POWER? Just use one of the ARM boards that comes free in some boxes of cereal.
▶ No.893418>>893437
>>893405
I have a RPi3 but doesn't that have the ARM flavor of ME/TrustZone?
▶ No.893437>>893446 >>893447 >>893690
>>893418
>ARM flavor of ME/TrustZone
There's no such thing the fuck are you talking about?
▶ No.893446>>893447 >>893462
>>893437
I was under the impression that basically any CPU you can buy apart from Loongson or whatever has some form of backdoored coprocessor, thus the hype surrounding POWER9
▶ No.893447
>>893437
>>893446
Just remembered it's called the PSP module on AMD >>892672
▶ No.893462
>>893446
Raspi requires nonfree binaries to boot as well as locked down media decoders.
POWER9 has an open coprocessor that you can program.
▶ No.893468
>>893327
Phoronix only had remote access to the machine. I'd assume once he gets on in house they'll be testing with more up to date software
▶ No.893479
>>893405
>>893405
Why do you care? He said he wants to support them, which I agree with.
▶ No.893481
>>893405
Why did you post that video?
▶ No.893498>>893503
▶ No.893503>>893674 >>893692
>>893498
Why are people calling this expensive? Are we getting Intel running damage control? A 7551 with the cheapest piece of shit motherboard that doesn't have PCIe 4 still costs $1000 dollars more.
Sure they don't have an i3 variant but this appears to be better value than x86 if you're looking in the same ballpark.
I expected to buy a Talos II with the idea that I'd be spending more for freedom, but it looks like I will be spending less.
▶ No.893589
>>893074
I thought one of it's primary features was being open sourced hardware?
▶ No.893596>>893597 >>893692
Intel is hard at work shilling on a Bhutanese-Mongolian oven modding collective i see.
▶ No.893597>>893608 >>893672
>>893596
None of these variations on "japanese animation" have ever been funny
▶ No.893608
▶ No.893625>>893692 >>893706
Any word on OpenCL/ Vulcan compute on these?
▶ No.893674>>893692
>>893503
> $4K
I haven't paid that much since the 80's (adjusted for inflation). No need to, since I'm not running Internet servers or playing modern games. An old Thinkpad, or a sub-$100 ARM board can do everything I need.
▶ No.893679>>893692 >>893742
>>893207
>Maybe things have changed since the PPC G4/5 days, but wasn't Altivec always MASSIVELY overengineered compared to every other ISA's vector coprocessors
PowerPC processors were consumer oriented, this shit is for massive datacenter servers. Not exactly the place where you crunch uniform data streams amenable for vectorization.
>eating up something like 1/3rd of the floorplan die space?
That's modern x86 for you. Why do you think Intel chips clock down when you start using AVX instructions?
▶ No.893687
>>893253
>is much easier to grasp than both GCC and Clang
>produces good code
pick one
>transpiles other high-level languages into C
>produces good code
pick one
▶ No.893690
▶ No.893692>>893704 >>894598
>>893679
>Why do you think Intel chips clock down when you start using AVX instructions?
I did not know this, do you have proof? I might consider compiling out AVX instructions for my gentoo install in such a case.
>>893674
>>893503
Think of it this way, a corporation that buys a talos for things like their datacenters might spend alot compared to cheap off the shelf x86/arm/AMD shitware. But they save in security costs down the road that could affect various aspects of their company. Like the bad name it would give them to get hacked and their data shared with the world, who would buy their product/service if you can't trust them? People are starting to cease using free services for reasons like that, why would they pay to be scammed or have their data stolen? Or like if you are a company that sells a service like a VPN, you would lose buisness even if you keep the cia/nsa bribe money if you got hacked or were reported using shitware like AMD/intel. In the longterm for security purposes you save alot of money just making it securer by default.
>>893596
I don't get what they think to accomplish by shilling a mongolian finger painting forum.
>>893625
Can't use AMD GPU's because of properitary VBIOS. Can't use anything except pre-kepler nvidia GPU's because nouveau support is non-existent. But with nouveau you can just compile the support for your architecture and use the up and coming opencl support in mesa which has had work started recently on it.
>>893321
If media de/encoding is your thing just stick some fermi nouveau GPU's on it and go nuts. Maybe contribute to their opencl support while you are at it.
These >>893274 >>893074
▶ No.893694
>>893321
>Media encoding falls short, someone will have to tune the compiler like x86 has.
Not the compiler, but the encoders. Media codecs generally have a lot of hand-tuned SSE/AVX code. The same has to be done for AltiVec.
▶ No.893704>>893713
>>893692
>properitary VBIOS
Is that why they're getting code mainlined into the most recent versions of Linux? Oh wait
▶ No.893706>>893713
>>893625
Talos II doesn't have NVLink, but I would imagine the CUDA toolkit for ppc64le works on a PCIE card.
▶ No.893710
>>893211
Nope, RISC-V ISA is going to become the industry standard as a basis with apossibility of adding oneś own DRM blob for major corporations which would be a variations, but the basic ISA would still function the same [e.g. the speed]. So any user could flash back to the open source ISA and suffer no bricking the system. The industry itself has proven to be utter shit at it.
▶ No.893713>>893725 >>893818
>>893704
AMD is getting the majority of their kernel space and all of their userspace code opensources to reduce maintenance burdens in the future. But their closed source video bios still needs to be loaded at runtime as a blob that only works on architectures that AMD supports such as x86, and not whatever you want to compile it for.
>>893706
You don't need any closed-source crap with nouveau as you can use entirely opensource solutions as long as the pci/e space is exposed for the nouveau driver. If it has pci/e you can use a nouveau card on it if you compile it for the proccessor that is on the board. This is because noueavu directly communicates with the various co-proccessors on the GPU directly over the pci/e space in their respective assembly languages.
>cuda
Just use the upcoming opencl support in mesa instead. Why are you going back to closed-source with a platform built for security? Sure, open source /=/ security, but you can atleast fix it yourself compared to a blackbox program such as the CUDA toolkits.
▶ No.893725
>>893713
I'm not the one who wanted GPGPU on a meme machine. IBM and Nvidia have already worked together to bring the best performance to this platform. AFAIK OpenCL with run on CPUs as well, so he could use a decade old GPU and get really slow performance if he wants to.
▶ No.893742
>>893679
>That's modern x86 for you.
No, that was a reference to PPC. Seriously, Apple/Motorola dedicated 1/3rd of transistor budget in every new midrange/high-end Mac's CPU to their first ever vector coprocessor, first pic related.
Even ignoring the fact that many such Macs were just being used for stuff like word processing that didn't use FPU, let alone vector, there were no Mac dev tools initially, and as a result no Mac apps with vector optimizations, this was back when practically everybody outside the HPC market ignored vector instructions, because x86 vector coprocessors like MMX/3DNow! were complete jokes (look at that little smudge in the middle of the pic 2) until SSE3 at the very earliest, so even ports had to add AltiVec optimization basically from scratch.
Any rational company who wanted to add a vector unit to prosumer PCs that outdid the vector performance of HPC/workstations ten times its price, for software that doesn't exist on your platform, with a resulting 1/3rd penalty to silicon yields/prices/clock binning, would've perhaps put it on a separate OPTIONAL module, like FPUs were initially, but not Motorola/Apple! That's far from the only cockup, of course. There was also failure to use the "MPX" FSB's 128-bit option to leapfrog Intel/AMD's FSB bottleneck years before DDR/Rambus caught up because Apple refused to make new mobos, lengthening the G4's branch-friendly pipeline with the 7450 to increase clockspeed for marketing reasons, eliminating the quad-CPU options as soon as Daystar was killed right in the middle of pushing dual-CPU to mainstream, antagonizing Motorola by killing their Starmax clones, and countless more...
>Why do you think Intel chips clock down when you start using AVX instructions?
You sound like you're confusing vector coprocessors with iGPUs (pic 3 related). If so, then yes, forcing desktop customers to sacrifice enough die space on a GPU they'll never use, to go from 6 to 10 cores, is absolute madness in an era when MS has included the WARP software renderer since Win 7, removing the only possible excuse (non-gayman office drones) for Intel/AMD's waste of silicon.
▶ No.893818>>893824
>>893713
That is not true, the blob mostly runs independently of the CPU arch.
Talos II works with Polaris and above AMD GPUs
▶ No.893824>>893830 >>893832 >>893836
>>893818
You stupid fuck read http://www.phoronix.com/scan.php?page=news_item&px=AMD-Radeon-Blob-Updates
There are architecture dependent blobs/microcode needed for every AMD GPU since the HD2400 - HD4290/r600 series see https://www.x.org/wiki/RadeonFeature/
▶ No.893830
>>893824
But then you could use the r600 series of AMD/ATI gpu's for any platform then? Since they would be entirely opensource including the blob they now require to communicate on the pci-e bus just like the newest nvidia GPU's require signed firmware to communicate on that space which are also firmware/architecture dependent. But the newest nouveau supported gpu's are newer then the r600 AMD gpus.
▶ No.893832>>893838 >>893857
>>893824
Read your own source, the architecture dependent blobs are for the GPU architecture, not the CPU.
Linux on POWER just loads those blobs like any other arch and uses the open source drivers.
▶ No.893836>>893838
>>893824
>You stupid fuck read http://www.phoronix.com/scan.php?page=news_item&px=AMD-Radeon-Blob-Updates
I don't understand what you are trying to prove, the binary blob doesn't run on the CPU, its code which is loaded onto the GPU at runtime. RaptorCS even lists AMD GPUs as compatible on their wiki.
https://wiki.raptorcs.com/wiki/Talos_II/Hardware_Compatibility_List
▶ No.893838>>893844 >>893846 >>893849
>>893832
>>893836
>yes goy load blobs downloaded over the internet straight onto the GPU for us
>we wouldn't ever stop you from using it on a architecture we don't like
>not a security risk at all, trust (((us))) at AMD
I'll eat my words if they ever opensource the microcode. But we know that will never happen intentionally.
▶ No.893844>>893849 >>893857
>>893838
I agree that the firmware should be opened but what possible vulnerability do you foresee?
The GPU still only interacts with the kernel via an open source driver, it has no control over the RAM, MMU or network card.
What can it actually do?
▶ No.893846>>893860
>>893838
>le internet mystery meat security hole for files you can authenticate against a hash
>caring about something sitting on a flash chip on the other side of the system bus with a zillion opaque asics made by the same people
You realize every single ASIC in nearly every component of any computer you'd care to name is the hardware equivalent of a "binary blob", since you don't can't read the VHDL files they're made from, let alone verify the fab's fidelity to those files, right?
▶ No.893849>>893860 >>894021
>>893838
>shifting the goalposts
>complaining about microcode
Most modern PCIe devices run their own microcode, GPUs, NVMe SSDs, HBAs and RAID controllers, etc. Even some NICs have microcode from what I understand.
>>893844
>it has no control over the RAM
Technically the GPU can read and write to any system memory address it wants via its DMA engines.
>network card
If a GPU is behind a PCIe switch (or on a root complex which supports P2P transactions) along with the NIC then theoretically it could communicate to the outside world by interacting with it directly. However the microcode would have to have an entire copy of that NICs driver, which in practice would have to be every single NIC ever made for it to reliably work, and the GPU would have to work out where the NIC is and what model, etc...
Similar attacks could be done by a userspace application via a filesystem running on top of an NVMe SSD. NVMe SSDs have DMA engines and many common ones run firmware.
IOMMUs protect against this type of attack though.
▶ No.893857>>893863 >>893918 >>894021
>>893844
>but what possible vulnerability do you foresee?
Well, it could house a entire operating system+rootkit like minix that is only loaded while it is on. Kinda like jewtel's ME or AMD's PSP or ARM's (((kikzone))) but more effecient.
>The GPU still only interacts with the kernel via an open source driver
Open source does not mean secure. The possibly independent operating system running entirely on the GPU could start sending errors down the command stream of instructions as to implement persistent rootkit like functionality. For one example your CPU directs the buffer to the screen but in that moment when it does so you could implement your rootkit with faulty GPU code hidden as bugs in the kernel. And considering amd contributes to the kernel in large amounts it would be very easy to do. This is just one example of a few that spring to my mind. Yet more reasons not to use newer AMD GPU's and the newest nvidia GPU's with their blobs. Stick to the old r300 series or the nouveau supported GPU's you insecure faggots.
>>893832
No you moron, show me a single use case of AMD's newest GPU's on another architecture without specialized blobs. The only thing I could find even related is https://archive.fo/RlJWo but that was ignored because it's not possible without (((server contracts))) with AMD like for the ARM branded CPU's like here https://archive.fo/kmAU8 with AMD's ARM architecture CPU's. am i fucking shilling for them now? learn to read you faggot.
▶ No.893860>>893863
>>893846
Yes I am aware of that. But just like GNU's libre OS list, I treat non-writeable blobs that are burned onto the hardware as part of the hardware. Loadable blobs can be manipulated however. But non-loadable's not so much unless it was malicious from the factory. But if you care about it being malicious from the factory you are stepping into true security type areas at which point, why aren't you designing the hardware from the ground up as you point out? Why bother with a talos ii other then it's easier to verify its functionality being entirely opensource or able to be so?
>>893849
>Most modern PCIe devices run their own microcode, GPUs, NVMe SSDs, HBAs and RAID controllers, etc. Even some NICs have microcode from what I understand.
>Similar attacks could be done by a userspace application via a filesystem running on top of an NVMe SSD. NVMe SSDs have DMA engines and many common ones run firmware.
And this is why people buy devices like the talos II, because you don't have to deal with any of this shit. Get all of it FOSS and begone blobs. There's even opensource SSD's now for your opensource/security autism.
>If a GPU is behind a PCIe switch (or on a root complex which supports P2P transactions) along with the NIC then theoretically it could communicate to the outside world by interacting with it directly
Or it could just call linux kernel functions in memory. Get creative.
▶ No.893863>>893865
>>893857
>muh management engines in muh gpu
CPUs hold special privileges compared to every other component (except maybe your NICs, I guess). None of what you speculated is any likelier than malicious SIPs being hidden inside your retro hardware.
>>893860
>Loadable blobs can be manipulated
How? If you verify checksums before flashing ROMs with each upgrade, that's impossible unless your entire system has already been compromised to the extent counterfeit ROMs could be flashed without your knowledge.
▶ No.893865>>893870
>>893863
<If you verify checksums
>what is hash collisions
>what is trusting AMD that the hash you recieved and your friend recieved are not both compromised
We can keep going, this is fun. Especially since this entire thread is supposed to be dedicated to the TALOS II's benchmarking, a machine built and marketed for security.
▶ No.893870>>893877
>>893865
If you're so paranoid you don't trust that the ROM file you're downloading is genuine, what about the OS, kernel, all the "open" firmware ROMs, and every single piece of software, from your package manager's repo?
If you don't trust checksums, your only possible alternative would be to personally visit AMD/nVidia/whoever, pick up a freshly burned BD-r fresh from their vault, and carry it back to your PC in one of those locked briefcases handcuffed to you.
Jesus fucking christ, there are ZERO practical reasons to care whether or not ROM files are "blobs", unless the entire device's VHDL files are also available, and even then, open-source anything is meaningless from a security perspective unless someone has used that source access to ACTUALLY CONDUCT A FULL FORMAL AUDIT. The only reason we care about ME/PSP/TZ/etc isn't because of inane conspiritardation revolving around their being they're "closed", but because the manufacturers proudly tout their publicly intended featuresets as doing things we don't want.
▶ No.893877
>>893870
<If you're so paranoid you don't trust that the ROM file you're downloading is genuine, what about the OS, kernel, all the "open" firmware ROMs, and every single piece of software, from your package manager's repo?
>what is compiling from source from CD's
I'm not that paranoid tbh. But you brought up real security with the VHDL's so it was worth a mention.
<If you don't trust checksums, your only possible alternative would be to personally visit AMD/nVidia/whoever
Stop there, AMD and nvidia have proven they are not trustworthy in the past with things like the very buggy (((PSP))) for AMD and nvidia being incredibly patent trolly and locking their hardware down in future generations. So use open source everything and don't give them a inch of trust.
>The only reason we care about ME/PSP/TZ/etc isn't because of inane conspiritardation revolving around their being they're "closed", but because the manufacturers proudly tout their publicly intended featuresets as doing things we don't want.
You mean like how GPU manufacturers sell the same chip but with different features or levels of RAM or such things enabled/disabled? Sounds familiar.
▶ No.893888>>893893
>from CD's
Where did you get that CD?
>Stop there, AMD and nvidia have proven blah blah blah blah
Why would you trust somebody to make "blobbed" hardware that could be packed with untold numbers of malign SIPs, but not to make firmware, firmware that ships flashed on every newer part from the factory, replacing the earlier version of that very same firmware that's already sitting in the ROMs of your mint unboxed GPU?
Unless every ASIC on that board has been x-rayed and audited, it is not one bit more trustworthy than the ROM images its manufacturer puts on your repo, "open" or not.
▶ No.893889>>893894
>notice i forgot to paste link for reply in text editor, about to delete and repost fixed version
>got hitler trips
▶ No.893893>>893896
>>893888 checked
>Why would you trust somebody to make "blobbed" hardware that could be packed with untold numbers of malign SIPs, but not to make firmware, firmware that ships flashed on every newer part from the factory, replacing the earlier version of that very same firmware that's already sitting in the ROMs of your mint unboxed GPU?
Never said I trusted them one bit. Atleast it is easier to begin half-assedly verifying their claims, both FOSS software and the supposed usage of the hardware, with a few computers of similar hardware compared against each other with fully FOSS code and an osciliscope. All of which is not mathematically verified but hence the half-assed part and not perfect security.
>Unless every ASIC on that board has been x-rayed
Wew the autism.
>and audited, it is not one bit more trustworthy than the ROM images its manufacturer puts on your repo, "open" or not.
But yet indeed, i'm not going for perfect security here, nor am I using pre-compiled packages. Now install gentoo faggot. inb4 goes into the insecurity of downloading packages off the internet, source code or not.
▶ No.893894>>893896 >>894031
>>893889
The pro-AMD blob shilling here is real.
▶ No.893896>>893900
>>893893
>with a few computers of similar hardware
Including computers with the same firmware blobs?
>fully FOSS code
Except all the undocumented closed-source mystery meat on the silicon
>Wew the autism
Obviously not every individual copy, but at least random factory line pulls to ensure compliance with the VHDL. It's sometimes done with military hardware and the like.
>>893894
>conflating kernelspace and rom space
>not using jewrunes
Gay
▶ No.893918>>894645
>>893857
I never cared for 3D GPUs to begin with. Before I started using laptops (which was about 10 years ago), I only had simple SVGA cards, none of that 3D crap. Now the mobos have those GPUs built-in, so I just don't load the drivers.
▶ No.893934
▶ No.893943
>>893070 (OP)
Hey its better than using a fucking Core 2 Duo thinkpad ffs.
▶ No.894021>>894045 >>894144
>>893857
You don't know what you're talking about, the minix rootkit works because it's in the BIOS and CPU.
>>893849
>Technically the GPU can read and write to any system memory address it wants via its DMA engines.
No it doesn't, modern devices, including the POWER9 use IOMMU groups, the CPU and GPU share different IOMMU groups, the GPU cannot access the rest of the system via DMA.
> a GPU is behind a PCIe switch (or on a root complex which supports P2P transactions) along with the NIC then theoretically it could communicate to the outside world by interacting with it directly.
Not on this board, the NIC is in a separate IOMMU.
▶ No.894031>>894045 >>894144 >>894164 >>894705
>>893894
>The pro-AMD blob shilling here is real.
The talos-crew shilling here is real.
>muh "not selling" Workstation
Over $3000 dollars, dude.
▶ No.894045>>894144
>>894021
>he thinks the IOMMU is secure
Maybe on the talos since you could audit that code and make it secure. But surely not on anything else where you don't have access to the code to verify it. Maybe that's why the se4L guy only tested his kernel on something with the IOMMU off?
>>894031
I ain't shilling for talos as it is overpriced for consumers like myself. But fuck AMD and their blobs and then saying they are fully open source when they are in fact not. Atleast nvidia is honest about how evil they are.
▶ No.894144>>894145 >>894669
>>894021
>No it doesn't, modern devices, including the POWER9 use IOMMU groups
I understand this, that is why I stated at the end of my post that IOMMUs stop this kind of attack. However in practice not everyone uses the IOMMU for various reasons so its still a possible attack vector.
>Not on this board, the NIC is in a separate IOMMU.
I wasn't stating this attack was specific to the Talos system, just in general (hence why I mentioned the PCIe switch even though the Talos system doesn't have one). However if the Power9 Root Complex supports P2P transactions (the only CPUs which I know that do are the AMD Epyc CPUs) then it is a possible attack vector provided the IOMMU is disabled.
>>894045
>Maybe that's why the se4L guy only tested his kernel on something with the IOMMU off?
Kind of, the IOMMU in itself because it throws some of their assumptions about how the hardware operates out the window and therefore invalidates quite a bit of their formal proofs.
>>894031
>Over $3000 dollars, dude.
As I said above, its still cheaper than a fucking Power9 server.
▶ No.894145
>>894144
>As I said above, its still cheaper than a fucking Power9 server.
Or most of the 80x86 garbage it's benching on par with
▶ No.894164
>>894031
>Over $3000 dollars, dude.
>oy vey muh shekels
Please don't buy it. Jews like you won't be able to use it.
▶ No.894598>>894669
>>893692
>who would buy their product/service if you can't trust them?
normalfags
▶ No.894645>>894767
>>893918
You do realize that GPUs are useful for much more than 3D graphics, right?
▶ No.894669>>894671
>>894598
The Talos II is not a product targeted towards normalfags anyways. So REEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE GTFO NORMALFAGS
>>894144
>IOMMU throws hardware assumptions out the window of CPU
How is this possible? The IOMMU is just that, memory mangement with a possible SOC on itself. What the fuck is it doing to the electrons on the CPU as it passess it to DRAM that causes such insanity as to make it impossible/very difficult to calculate all the possibilities for verification mathematically?
▶ No.894671
>>894669
>The Talos II is not a product targeted towards normalfags anyways.
Reread the post the post you replied to replied to.
fractal shitposting
▶ No.894705>>894767
>>894031
> $3000 dollars
yet it's still not overpriced, because anything less is insecure garbage.
$300 used to get you a decent netbook 10 years ago, now you're dropping $1k minimum for a steaming pile of botnet shit.
▶ No.894767>>894777 >>895540 >>895674 >>897000
>>894645
What else am I going to do with it? I don't mine bitcoins, I don't care about HD movies, I don't play modern games at all (even 2D), and all my emulators work fine with software rendering and simple 2x or 3x scaling.
I also don't like Firefox/Chrome type browsers or the sites that require those. On occasion, I have to use them, but it's pretty much a nasty ordeal where I have to hold my nose and just get it over with, not something I want to seek out regularly. I would rather go clean the bathroom or something tbh.
>>894705
$300 still gets you an entry-level laptop, that'll do most tasks. But frankly, I'm done with laptops and x86. A sub-$100 ARM board does all I need, with much less botnet. I just can't justify paying thousands more to further reduce botnet by only a small fraction. Once again, maybe when RISC-V gets common and affordable...
▶ No.894777>>894799 >>895674
>>894767
>What else am I going to do with it?
You could run your entire OS on it instead of the intel proccessor. A GPU is just a dedicated addon CPU with additional RAM and possible undocumented IC's after all. Made in a RISC format so that it's easier to specialize the functions, but nonetheless could be used as a CPU if a GLIBC library was ported to it. Imagine being able to compile linux for two architecutes and switch your active proccessor on the fly. It would be fucking awesome just for shits and giggles.
▶ No.894799>>895534
>>894777
That's not how it works. GPUs do have a controller processor running its firmware, but the majority of the work happens in specialized hardware and shader processors which they have at least several hundred of (unless it's an integrated design). Those are programmable, sure, but rather limited on what kind of memory I/O and instructions they're capable or running efficiently. Swapping the firmware for your own, is probably not possible as it's likely signed and certainly proprietary and undocumented. Even the free driver people like nouveau don't mess with the firmware.
▶ No.895534>>895674
>>894799
>shader processors which they have at least several hundred of
That's not how it works, unless you are a retarded marketroid. A typical high-endish card has around a hundred shader cores, and each processes dozens of vector lanes in parallel. You don't call each vector lane a "processor", unless you want to call a Core i5 a 32-core processor (since AVX can do 8 FP lanes in parallel). Which would be massively retarded.
▶ No.895540>>895674
>>894767
>all my emulators work fine with software rendering and simple 2x or 3x scaling
You lucky bastard. Unfortunately, I'm addicted to a few Wii games, and no ARM platform is close to being able to emulate that. Will probably have to write a POWER dynarec core for Dolphin myself, as I don't expect any of the core team faggots to do that on their own.
▶ No.895674>>896010
>>894777
>>895534
>RISC
Modern GPGPUs are almost exclusively VLIW rather than RISC or CISC, and their architecture is much closer to "many core" specialty archs like the Connection Machine or Xeon Phi, than what is conventionally thought of as "multicore" for CPUs.
>>895540
>>894767
There's already a port of Dolphin for 64-bit Android & Linux/ARM. It runs okay-ish on top-end phones, which are now (i.e.: Google Pixel 2) roughly on par with a midrange Haswell laptop from around 2011.
▶ No.896010>>896729
>>895674
>Modern GPGPUs are almost exclusively VLIW rather than RISC or CISC
u wot m8? AMD got rid of VLIW cruft many years ago, their modern designs are pretty straightforward vector RISCs. nVidia skipped VLIW altogether, going straight from vector-of-4-vector specialized graphics cores to a straight vector RISC, the reason being that VLIW is shit for compute.
>>895674
>There's already a port of Dolphin for 64-bit Android & Linux/ARM.
Yep, and none for POWER.
>It runs okay-ish on top-end phones
Only for Gamecube games. ARM hardware is still too underpowered to handle Wii emulation.
>which are now (i.e.: Google Pixel 2) roughly on par with a midrange Haswell laptop from around 2011.
Haswell came out in 2013 you moron. And no, no ARM can come close to a midrange Haswell CPU, unless you're talking about severely underpowered single-digit TDP ultramobile parts that can't game for shit. You need to clock that Haswell north of 2.5GHz to get acceptable framerates in some Wii titles (and I'm assuming it's a quad-core). With best ARM cores' IPC, you'd need around 4GHz.
▶ No.896718>>896752
How well optimized are these programs for Power9? The compiler?
▶ No.896729>>896953
>>896010
I'm on a Haswell i5 and my Wii games emulate better than my GameCube games. Which ones are you having difficulty with? I wouldn't bother with Dolphin on ARM unless you have an Nvidia TK/TX1/2. You need OpenGL3 supported hardware for the latest version of Dolphin.
▶ No.896752>>896786 >>896953
>>896718
>How well optimized are these programs for Power9?
Given that far more people own ARM systems than OpenPower they probably aren't that well optimised. The encode and compression tests more so because that sort of code makes heavy use of hardware vector intrinsics and without a proper system to develop and optimise the code on its going to run slow.
Not sure about the compiler, but considering how garbage GCC is in general I wouldn't be surprised if its poorly optimised for PPC64. A good test would be one that uses Clang since Google is one of the main contributors to it and from what I understand they have quite a few Power systems.
▶ No.896786
>>896752
I remember when AMD64 was introduced that there was some lag before compilers and code was optimized as well, same with the G4 PPC.
▶ No.896793>>896953
>>893082
>>it's all the compiler's fault, buy our $5000 Faceberg machine using an architecture for which no programs exist!
There's this magical thing called "source code", which you can compile for any architecture.
▶ No.896797
▶ No.896953>>897054 >>897160
>>896729
>I'm on a Haswell i5
That tells us exactly nothing. i5s go from ultramobile shitshows to fire-breathing 4GHz quad-core desktop monsters. Sure, models with >35W TDP can handle many Wii gaymes.
>You need OpenGL3 supported hardware for the latest version of Dolphin
I believe Dolphin also has a GLES3 backend.
>>896752
>considering how garbage GCC is in general
On x86 it's one of the best compilers in existence. Quality of code it generates for other architectures varies wildly though.
>>896793
...if you have a good compiler for that architecture. Hopefully with Talos out, GCC folks will finally pick the slack.
▶ No.897000>>897094
>>894767
>What else am I going to do with it?
A growing number of desktop apps can take advantage of GPU compute. Off the top of my head: GIMP can accelerate many image transformations this way. OpenOffice Calc can offload calculation of large spreadsheets.
Of course if you're happy living in the 90s, you don't need any of this.
▶ No.897054>>897059
>>896953
>i5s go from ultramobile shitshows to fire-breathing 4GHz quad-core desktop monsters
You're thinking of the i7's. The Haswell i5's never hit 4GHz. Not even in turbo mode.
▶ No.897059
>>897054
>3.9GHz
close enough
▶ No.897094>>897106
>>897000
More like 00's maybe? Even bitcoin mining was pretty niche back then.
▶ No.897106>>897114 >>897139
>>897094
>00's
>bitcoin mining
No. Yes, I know the original paper came out in 2009.
▶ No.897118>>897139
▶ No.897139>>897737
>>897106
>>897118
tripfags get the rope
▶ No.897160>>897179
>>896953
>On x86 it's one of the best compilers in existence.
Either you are a GCC shill or you have never bothered using things like -Wall and -Wextra.
▶ No.897179>>897734
>>897160
I was talking strictly about the quality of generated code, not of diagnostics aimed at the programmer.
▶ No.897734>>899271
>>897179
Diagnostic features are far more important than the generated machine code being slightly better.
In GCC -Wall doesn't actually enable all possible language warnings (at least in C and C++) because GCC doesn't actually bother to implement them. Clang does but to still be backwards compatible with GCC its -Wall is the same and instead they include the -Weverything flag to actually enable everything. Many developers don't understand the benefits of strictly complying with the language, especially with large code bases, if I find myself ever needing the few % speed increase I could get by switching to GCC I instead use a profiler and hand optimise my code. The only time I ever use GCC is when I am writing kernel code.
▶ No.897737>>899273
▶ No.898902
>>893070 (OP)
IBM and Intel BTFO
▶ No.899271
>>897734
>Diagnostic features are far more important than the generated machine code being slightly better.
Which is irrelevant to the fact that they are not the subject of this discussion.
What's stopping you from using, say Clang for its diagnostics in debug builds and making the final build with GCC for best performance, anyway? If you're autistic about standards compliance, your code should compile correctly with whatever compiler you choose.
▶ No.899273