Consolidated Business & Enterprise Computing Rant Thread

Discussion in 'Business & Enterprise Computing' started by elvis, Jul 1, 2008.

  1. itsmydamnation

    itsmydamnation Member

    Joined:
    Apr 30, 2003
    Messages:
    10,650
    Location:
    Canberra
    All modern CPU's are RISC ( fight me I dare you :) ).

    The folks pushing for simpler designs are few and far between and aren't going to win. Any form of predicting/prefetch has a possibility in some way to be abused , so unless you want 486 era compute performance its kind of boiling the ocean.

    Also fundamentally disagree with your position about performance, Scalar integer performance is still king by a long way for CPU's. CPU extensions even AVX-512 are nothing compared to VLIW/SIMT based DSP's/GPU's etc in terms of pushing specialist based performance. Hell even the much famed tensor cores/units are nothing but an optimised int/float format and and optimisation to not write intermediate results back to registers.
     
  2. Cape_Horn

    Cape_Horn Member

    Joined:
    Dec 23, 2001
    Messages:
    2,452
    Location:
    Shooting Baker
    I wonder what type of clockspeed you could get out of a 486 if you shrunk it down to 7nm. (not that x86 is RISC) - while it would not be able to do as much per clock cycle, it also would not need to discard for the predictive work that it got wrong.
    Hmm... If you did go straight RISC, would you be able to push the clock speed even higher I wonder.
     
  3. cvidler

    cvidler Member

    Joined:
    Jun 29, 2001
    Messages:
    14,187
    Location:
    Canberra
    Might want to check your anti-MS attitude,

    https://torrentfreak.com/riaas-youtube-dl-takedown-ticks-of-developers-and-githubs-ceo-201027/
    tl;dr;
     
  4. OP
    OP
    elvis

    elvis Old school old fool

    Joined:
    Jun 27, 2001
    Messages:
    42,818
    Location:
    Brisbane
    Last edited: Oct 29, 2020
  5. cvidler

    cvidler Member

    Joined:
    Jun 29, 2001
    Messages:
    14,187
    Location:
    Canberra
    a 7nm 486 core would probably black hole itself. ;)

    Looking at POWER, they're not really any higher in clock speed (POWER10 peaking at ~4GHz) than x86_64.
    ARM even in server specs are running much lower clock speeds. they seem to go massively parallel instead (8-core phones, 128-core server chips etc.)

    and pretty much any other RISC platform is long dead (SPARC, MIPS, PA-RISC).

    there's RISC-V but it's not really commercial viable (yet?). couldn't find any at high clock speed.
     
  6. itsmydamnation

    itsmydamnation Member

    Joined:
    Apr 30, 2003
    Messages:
    10,650
    Location:
    Canberra
    No, the only thing that slows down clock speed for CISC vs other things is variable instruction length CISC decoding complexity ( x86) and instead of slowing down clock speed they just limit instruction bytes a cycle instead ( ~16 bytes), use large uop caches so you read in 16 bytes decode all the instructions you can find regardless and jam them in the uop cache. You can see the latest atom cores for a novel approach without using a large uop cache to do more then 16 bytes a cycle. But bring this back to some sort of in order RISC CPU ( in order because we have decided anything that is calculated without guaranteeing the result to be correct is bad ) your frontend instruction throughput is going to be anaemic so your performance is going to be as well. its going to be anaemic because you can only have eviction caches and you cant request the instruction or data from memory until you calculate the memory addresses that your only doing in order because you can't be wrong because security.......

    nope i just know what im talking about :)
    RISC , CISC is all the same , what actually matters for an ISA is code density , complexity to decode etc and those aren't bound by CISC/RISC constructs.

    edit: remember memory access speed (NS) hsan't gotten any faster since SDR memory.
     
    Last edited: Oct 29, 2020
  7. OP
    OP
    elvis

    elvis Old school old fool

    Joined:
    Jun 27, 2001
    Messages:
    42,818
    Location:
    Brisbane
    Word is they're at moderate (i.e.: low end desktop CPU) clockspeed in China, but we don't hear about them over here.

    It's taking off in the embedded space, which is great. India also posted a 100% Indian-made RISC-V system that can post a full Linux install. Everything made on Indian soil - CPU, RAM, all components. They're only at 200MHz, but it's just a start point for their desire to have at least one 100% foreign-independent computer.

    So China are well into self sufficiency. India's on the way. How's Australia doing for not needing foreign made tech to even live? Phwarhahahaha yeah nah... ROCKS!

    But I digress. RISC-V will be the next ARM now that Nvidia are going to mangle that. But there's lots of folks looking to push RISC-V into "OS management" roles inside systems where real compute is done on GPU/TPU/IPU, and the generic CPU is, as I said earlier, nothing but a traffic cop.
     
  8. OP
    OP
    elvis

    elvis Old school old fool

    Joined:
    Jun 27, 2001
    Messages:
    42,818
    Location:
    Brisbane
    I feel like these discussions always result in technical masturbation, rather than thinking about the larger issue.

    The issue at hand is we've got security risks on physical hardware now, because it's so bloody complex. The "solution" to date has been shipping new microcode, but now that solution is fucked too.

    Simplification is a noble goal, always. Love or loathe Torvalds, but he maintains the most popular operating system on planet Earth, and one that runs in some seriously important shit. He's vocally opposed the constant push from complexity by Intel and others at the expense of security. So when you say things like this:
    My response is that it's not the number of people calling for it, but rather how relevant their opinion is in this space. Some lowly application developer who wants a faster CPU to make their shitty app run faster can honestly go fuck themselves. Sorry, not sorry.

    Instead of constantly pushing for the general purpose CPU inside a system to get complex beyond maintainable measure, the suggestion is to simplify it and move things that need complexity to other types of processors. Again, in HPC land and even more so in other types of less formalised clustering and wide spread computing, "real work" is done on GPUs, TPUs and IPUs. The main CPU more frequently is reduced to traffic cop, so the requirement for it to be this all-singing, all-dancing thing is reduced.

    Simpler main CPUs allow more secure operating systems in general. Purpose-specific processors of course then inherit the burden of security, but updating libraries for those is far less of a drama than having an ENTIRE OS compromised. Particularly when non-root, user processes are more likely to be running off to the side on these task-specific processors rather than the OS (or worse, hypervisors holding many OSes).

    So again, big picture: Reduce complexity, move compute to purpose-specific things, stop making the traffic cop need to be the science whiz. Technical masturbation over instruction sets be damned. We all need to get out of the weeds.
     
    Last edited: Oct 29, 2020
  9. GumbyNoTalent

    GumbyNoTalent Member

    Joined:
    Jan 8, 2003
    Messages:
    9,279
    Location:
    Briz Vegas
  10. GumbyNoTalent

    GumbyNoTalent Member

    Joined:
    Jan 8, 2003
    Messages:
    9,279
    Location:
    Briz Vegas
  11. OP
    OP
    elvis

    elvis Old school old fool

    Joined:
    Jun 27, 2001
    Messages:
    42,818
    Location:
    Brisbane
    Considering x86 has almost zero footprint in phones/tablets, I think that market already proves that simpler, less power hungry CPUs have high commercial value.

    The "low end laptop" still gets dominated by x86 that's artificially shaved down in an attempt to be less power hungry, but that's largely driven by legacy need (read: "Windows+Office"). There's the age old catch-22 there of many smaller development shops not wanting to port their apps to non-x86 because there's "no demand", but the demand won't grow until the applications are available.

    Aaaaand cloud steps in, makes your device a thin client to "mainframes in spaaaaace", and Robert's your mother's brother.
     
  12. cvidler

    cvidler Member

    Joined:
    Jun 29, 2001
    Messages:
    14,187
    Location:
    Canberra
    as already covered RIAA is the problem, not MS.

    because of the DCMA act, they'd be in breach of the law if they didn't act.
    wouldn't matter if github was owned by MS, or anyone else (in the US). same with youtube for example, if someone claims one of your videos contains copyrighted music, they'll ban it so fast your head will spin. big companies aren't in the game of fighting law suits on behalf of their users.
     
  13. GumbyNoTalent

    GumbyNoTalent Member

    Joined:
    Jan 8, 2003
    Messages:
    9,279
    Location:
    Briz Vegas
    MS was part of the reason we have DCMA, and its impact. MS start lobbing the government in the 80s to force every PC sold had a license, then furthered their claim in 1998 DCMA lobbing hard form the anti-circumvention laws.

    2016 MS opposed any changes to section 201 of DMCA.
    https://www.regulations.gov/content...-0012-0054&attachmentNumber=1&contentType=pdf
    https://en.wikipedia.org/wiki/Digital_Millennium_Copyright_Act#Anti-circumvention_exemptions

    These are exemptions that the use of tools like youtube-dl which could be used to infringe copyright but also used without infringing, therefore as software do not infringe, opposed and quashed amendments.

    I oppose MS the corporate entity, and the lackluster business software and cloud hosting company, however I embrace MS the entertainment company and own every generation Xbox. I do oppose aspects of DCMA but endorse people right to copyright protection and also endorse people right to fair use, but too many have used the DCMA as a tool to monopolize.
     
  14. OP
    OP
    elvis

    elvis Old school old fool

    Joined:
    Jun 27, 2001
    Messages:
    42,818
    Location:
    Brisbane
    I think the irony here is, as pointed out, that MS are a member of the RIAA. So, as mentioned, this is in part their own doing in a weird way.

    But of course that companies are so fucking massive now, that this sort of "infighting" is more and more likely to be publicly viewed when shit like this happens.

    As much as GitHub are owned my Microsoft, GitHub are not Microsoft. Just like I am not my employer, and my opinions on things are entirely separate. In GitHub's defence, they've publicly disagree with Microsoft on plenty of things before (just like many subsidiaries disagree with their owners).

    I'm not really in either camp here. I don't "blame" GitHub-via-Microsoft for this, and I'm also well aware that Microsoft isn't a hive mind, and individuals working for massive companies can have their own independent opinions on things. But at the same time, Microsoft's track record for punitive measures on software licensing has only bolstered the whole thing.

    Either way, big companies can all get fucked, and I'm not going to worship any of them. I have no ownership or pride in their commercial brands. Fuck 'em all.
     
  15. itsmydamnation

    itsmydamnation Member

    Joined:
    Apr 30, 2003
    Messages:
    10,650
    Location:
    Canberra
    So i disagree on both points,
    1. This vulnerability actually isn't a big deal despite the headlines ( read the actual issue ) and it only effect goldmount , so 0 servers.
    2. Linus is very pro cpu complexity that delivers general computing improvements ( memory disambigufication, short cutting load/store on the frontend, stack optimisations etc) , sticking to 4k memory page file sizes (unlike apple ). What Linus didn't like was vector extensions and nothing else , from sandy bridge to skylake version 38 we didnt get much general instruction improvement but got SIMD FP instruction sets.

    I read realworldtech daily and linus is Very vocal and very detailed on his opinions there.

    here are examples of him talking about memory address tricks all in the name of performance:
    https://www.realworldtech.com/forum/?threadid=195808&curpostid=195858
    https://www.realworldtech.com/forum/?threadid=195808&curpostid=195888

    its to hard to search that forum, but over many years he has been quite consistent, he was really impressed with AMD's store to load forwarding when Zen1 came out for example.

    better tell :
    The UK government
    the US DOE
    the US military
    the ANU
    Japanese government
    ( i can just keep naming them, but CBF)
    Who have all in the last 12 months that have purchased 100m > supercomputers with far more general CPU compute then GPU/AI accelerator etc. Why? because despite all the hand waving back to back instruction latency matters , and it matters massively in a RDMA system when you need the pull memory from anywhere you x,000 node clusters. The faster you prefetch and predict ( things GPU's, accelerators dont do) the faster you pull that memory over the fabirc the faster you execute. Theres a reason these supercomputer generally have dedicated cabs for GPU's /AI and its because they have a scaling limit, they can't branch, prefetch, predict and have very small working sizes.

    I suggest you know less then what you think you do about the topic :)
    All problems have serial dependency no matter how parallel the task Amdahl's law etc

    your fundamentally misunderstanding the problem
    The problem hasn't been prefetching, predicting or speculation, it has been auditing and boundary enforcement and its absence.
    But as you can point out many of these can be easily overcome with microcode updates in old hardware at a generally smallish performance cost ( orders of magnitude less then no speculation/prefetch/predict) because they have largely been boundary enforcement issues but all the information is there to make the enforcement.

    Attacks will always get more complex , but the security models will get better, just look at SEV to SEV-ES to SEV-SNP for example in just ~3 years.

    Now in your model how much throughput do you think a traffic cop that cant prefetch, predict or speculate can actually move. it will be 3/10th of fuck all.

    You can have your 486 processors running far far lower clocks then modern CPU's , kind of hard to have pipeline stages in a CPU if there's nothing to do in said pipeline stages unless you want to make your currently single cycle ADD/MUL etc take way longer (YOLO netburst's never released tejas and jayhawlk)
    . I will take the prefetching, predicting and speculating CPU and not go back to 1994.

    If you are true to your position your not going to use any DDR ram either because of its complexity allowing Rowhammer,
    So enjoy your dog slow processing while accessing your dog slow memory.
     
    chip likes this.
  16. OP
    OP
    elvis

    elvis Old school old fool

    Joined:
    Jun 27, 2001
    Messages:
    42,818
    Location:
    Brisbane
    I feel you've taken the position of "excessive complexity lowers security" to a rather ridiculous conclusion here.

    This is not a black and white problem. The "solution" to excessive general purpose CPU complexity doesn't have to be
    We can, and should, consider what the benefit is on every addition of complexity, rather than just constantly pushing for diminishing gains in the name of exponentially increasing complexity.

    I guess my "get out of the weeds" comment was overlooked. Here we are, thick in the weeds.

    I suggest I know three fifths of fuck all about CPU design. But I do know the financial impact of having to mitigate modern security risks in the name of performance.

    Even more ironic when the patches come in and slow CPUs down to years-old performance levels, ala Meltdown. So much for all of that lovely "C" in CISC when the software patches make it run like cold garbage.

    Funny you should say it, but my next gaming rig is going to be a 486 with SDR RAM, all in FPGA. :D
     
    Last edited: Oct 30, 2020
  17. millsy

    millsy Member

    Joined:
    Mar 31, 2007
    Messages:
    13,315
    Location:
    Brisbane
    I'll take the extra cpu cycles so my logging and monitoring tool can calculate with a decent degree of certainty that the 10 year old element of Windows compiled in C has misbehaved in a manner consistent with a compromise, instead of kneecapping cpu performance for the sake of eliminating all side channel attacks that are yet to be used (at least in a publicly disclosed) real life attack.

    But that's just me
     
    Last edited: Oct 29, 2020
    elvis likes this.
  18. OP
    OP
    elvis

    elvis Old school old fool

    Joined:
    Jun 27, 2001
    Messages:
    42,818
    Location:
    Brisbane
    RHEL 8.3 was released today. Headlining the release notes were a bunch of things relating to CPU vulnerability mitigations that negatively affected performance.

    Given the sorts of things that run in RHEL (almost every major stock exchange on the planet, for example), there's some pretty blatant real-world impacts of the dollar cost of all of this.
     
  19. theSeekerr

    theSeekerr Member

    Joined:
    Jan 19, 2010
    Messages:
    3,534
    Location:
    Broadview SA
    I'm not sure I understand how "let's go back to much slower CPUs" solves that problem.
     
  20. OP
    OP
    elvis

    elvis Old school old fool

    Joined:
    Jun 27, 2001
    Messages:
    42,818
    Location:
    Brisbane
    Why do we need these insecure-but-fast CPUs to run our OSes? Why can't the OS itself run on something else, and the userspace workload run off crazy fast but potentially insecure CPUs, but locked in nice cages?

    The suggestion of GPU workloads earlier was poopooed "because RDMA", yet all the work in involved in is seeing a lot of people trying to solve things that used to need RDMA type solutions in ways that avoid it (typically because no cloud vendor offers a workable RDMA solution).

    Yes, Amdahl's law will bite a percentage of these in the arse every time. But I see plenty of stuff that is done "the way it's always been done" only because nobody clever and motivated tried a different approach. (And before anyone gets offended, of course it's not a given that every compute problem can be radically changed overnight, but there's still a hell of a lot of rote stuff done in compute research, often be grossly overworked individuals who don't have the time or resources to attempt different ways of doing old things).

    What I've seen on TPUs in the last 12 months alone has totally change my opinion on everything that was holy and immutable just years earlier.

    And even then, RDMA isn't incompatible with the ideas I'm suggesting here - where the OS itself runs on more secure hardware, and the userspace workload runs on whatever you want. Including x86+RDMA, just away from the crown jewels that is ring0 (or worse, ring -1).
     
    Last edited: Oct 30, 2020
    Rass likes this.

Share This Page

Advertisement: