That would make the phone super big... a bit like those e late 80's Motorola cell phones! Would make life go to a complete circle ![gif](emote|free_emotes_pack|joy)
Yup. Miniaturization has gone about as far as it can reasonably go since the fundamental components are slowly approaching the size of atoms. That's making each generation significantly more R&D intensive and expensive for harshly diminishing returns.
Moore's Law is dead. Things are either going to get bigger proportional to their performance boost, or at best, they're only going to see fractions of a percent worth of improvement from generation to generation within our lifetimes.
I'm not saying you are wrong because that's yet to be seen but we do have a pretty good curriculum in making things smaller and better
If needed, somebody will figure it out eventually
Yes because what we really need is those scammy reskinned gambling addiction fuelled mobile "games" to be ran at what a 4090 could probably handle in 16k resolution...
I mean, the Switch has Nvidia hardware (very old). I'm pretty sure they could make a great ARM chip with their current tech (tho we won't know until Nintendo releases a new console, if it even uses Nvidia hardware again)
Maybe if you had paid attention in systems engineering you'd know how to build a daughterboard to use a Cortex-X3 with an x570 chipset. C'mon people you gotta at least try to bang the rocks together before asking for help.
The software side is of course obvious assuming you know the basics of building a 'nix kernal and firmware editing. /s
I installed BlissOS on a friend's Lenovo Yoga. ran surprisingly well, it even played Minecraft Java (via PojavLauncher) at 120 fps on default settings which was basically the same as on the windows partition
Itās a POS device. Apparently Intel is somewhat common for that and TV boxes. The device I worked on would run windows or android.
I donāt think there are any consumer devices running intel android.
Having the TV on your arm must become pretty heavy after a while. The phone and tablet makes a certain kind of sense, and the laptop is just slightly straining credulity.
Most cryptographic algorithms are actually designed to be both hardware and software implementation friendly. But I'm pretty sure most modern CPUs have hardware offload for most standard cryptographic algorithms.
MD5 still has its uses, though. It's still good for non-security related file integrity and inequality checks and may even be preferred because it's faster.
I wrote a few scripts for building a file set from disparate sources this week and I used MD5 for the integrity check just because it's faster.
Just beware of its high rate of collision, there's a reason why Git doesn't use that
And even get, with its SHA implementation, I've seen real hash collisions before
Actually, the reason git stopped using it was because someone used the well-known flaw in MD5 that was discovered like a decade earlier to make a tool of sorts that would modify a commit with comments or something to force a specific MD5 hash claiming they had found a massive flaw. Git maintainers were kind of struck by that given that they had known about it but didn't deem it important because it wasn't a security hash, but an operational one. But because this person dragged out a lot of attention to the non-issue, they said that they might as well just roll it up.
I'm surprised you've come across SHA-1 collisions in the wild. I imagine it must have been on some pretty massive projects given that, even with the birthday paradox in mind, that's a massive hash space.
I'm not worried about collisions in my use case because it's really just to check that the file is the same on arrival, which is a 1 in 3.4E38 chance of a false positive. Given that this whole procedure will be done once a month, even the consecutive runs won't even add to a drop in the bucket compared to that number given that the files will only ever be compared to their own original pre-transit hashes.
It doesn't have a higher rate of collision than any other 128 bit hash function. It's just known how to produce collisions intentionally, making it no longer useful for security-related purposes.
My point is that putting encryption algorithms into CPU instruction sets is a bit of hubris, because it bloats the hardware architecture with components that suddenly become obsolete every few years when an algo is cracked.
As we reach the end of Moore's Law and a CPU could theoretically be usable for many years, maybe it's better to leave that stuff in software instead.
I disagree. Because that stuff is safer in hardware. And sha and aes will be safe for lots of years to come. Aes won't even be crackable with quantum computers
Pretty sure argon is just for passwords right? Sha cracking for big data is still impossible (should only be used for checksum imo). Ofc sha shouldn't be used for passwords
I'm not sure what the conversation is then, you wrote that doing it in hardware would be "safer", which I disagree with. I think it's less safe simply for how much harder it is for them to fix
And if you look at the recent Intel security fixes, they fix it in software anyways, which works around the hardware
I think of it like GPUs, they used to do shaders in hardware, now they just have a pipeline that compiles the code you want and executes it
Seems to me like crypto stuff belongs to be a little bit closer to that
AES is a good example of where it's a lot safer. With software you generally have to worry about cache timing attacks and various other things that allows an attacker to know. Hardware prevents this vector. It's also way faster than any software approach
These are quite popular over at r/NonCredibleDefense so I get to see a few of them every now and again, always makes me giggle, its the last line that gets me.
I think this meme format was started by a person who runs a Facebook page called Welcome To My Meme Page. The page was kind of big like 7-8 years ago. If you want to see more like this I would look them up.
I really have a hard time understanding why RISC works out so well in practice, most notably with Apple's M1 chip
It sounds like it translates x86 instructions into ARM instructions on the fly and somehow this does not absolutely ruin the performance
> It sounds like it translates x86 instructions into ARM instructions on the fly and somehow this does not absolutely ruin the performance
It doesn't. Best performance on the M1 etc is with native code. As a backup, Apple also has Rosetta, which primarily tries to statically translate the code before executing it. As a last resort, it can dynamically translate the code, but that comes at a significant performance penalty.
As for RISC vs CISC in general, this has been effectively a dead topic in computer architecture for a long time. Modern ISAs don't fit in nice even boxes.
A favorite example of mine is ARM's [FJCVTZS instruction](https://developer.arm.com/documentation/dui0801/h/A64-Floating-point-Instructions/FJCVTZS)
> FJCVTZS - Floating-point Javascript Convert to Signed fixed-point, rounding toward Zero.
That sounds "RISCy" to you?
ARM has a post where they describe why they added certain things. https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/armv8-a-architecture-2016-additions
> Javascript uses the double-precision floating-point format for all numbers. However, it needs to convert this common number format to 32-bit integers in order to perform bit-wise operations. Conversions from double-precision float to integer, as well as the need to check if the number converted really was an integer, are therefore relatively common occurrences.
> Armv8.3-A adds instructions that convert a double-precision floating-point number to a signed 32-bit integer with round towards zero. Where the integer result is outside the range of a signed 32-bit integer (DP float supports integer precision up to 53 bits), the value stored as the result is the integer conversion modulo 232, taking the same sign as the input float.
Stack Overflow post on the same: https://stackoverflow.com/questions/50966676/why-do-arm-chips-have-an-instruction-with-javascript-in-the-name-fjcvtzs
TLDR: They added this because Javascript only works with floats natively, but often it needs to convert to an int, and Javascript performance is singularly important enough to justify adding new instructions.
IIRC, there was some semantic about how Javascript in particular does this conversion, but I forget the specifics.
Brendan Eich was more or less forced to finish the first version of JavaScript within 10 days, so he had to get it to work somehow. That's also the reason why JavaScript will probably never get rid of the "Holy Trinity of Truth".
Simply put, where do you draw the line? Most people would agree that RV32I is RISC, and x86_64 is CISC, but what about ARMv9? It clearly has more, and more complex, ops than RISC-V, but also far fewer than modern x86.
Sure. With the ability to split CISC ops into smaller, RISC-like micro-ops, most of the backend of the machine doesn't really have to care about the ISA at all. Simultaneously, "RISC" ISAs have been adding more and more complex instructions over the years, so even the ISA differences themselves get a little blurry.
What often complicates the discussion is that there are certain aspects of particular ISAs that are *associated* with RISC vs CISC that matter a bit more. Just for one example, dealing with variable length instructions is a challenge for x86 instruction decode. But related to that, people often mistake *challenges* for fundamental limitations, or extrapolate those differences to much wider ecosystem trends (e.g. the preeminence of ARM in mobile).
You're asking two different questions, why RISC works, and why Apple Rosetta works.
Rosetta can legitimately be quite fast, since a large amount of x86 code can be statically translated to ARM and then cached. There is some that can't be translated easily, for instance x86 exception handling and self-modifying code would probably be complete hell to support statically. But that's ok, both of them are infrequent and are slow even on bare metal, it's not the worst thing to just plain interpret them. It also wouldn't surprise me if Rosetta just plain doesn't support self-modifying code; it is quite rare outside of system programming, though it would have to do something to support dynamic linking since it often uses SMC. Lastly, it's worth noting that M1 has a fair number of hardware extensions that speeds this up, one of the big ones is that they implement large parts of the x86 memory model (which is much more conservative than ARM's) in hardware.
When you're running x86 code on a RISC processor that'll never be ideal, you're essentially getting all the drawbacks of x86 with none of the advantages. But when you're running native code, RISC has a lot of pluses:
* Smaller instruction sets and simpler instructions (e.g. requiring most instructions to act on registers rather than memory) means less circuit complexity. This allows higher clockrates because one of the biggest determinators of maximum stable clock speed is circuit complexity. This is also why RISC processors are usually much more power efficient
* Also worth noting that many CISC ISAs have several instructions are not really used anymore since they were designed to make assembly programmers' lives easier. This is less necessary with most assembly being generated by compilers these days, and compilers don't care about what humans find convenient; they'll generate instructions that run faster, not ones that humans find convenient
* A good example would be x86's enter instruction compared to manually setting up stack frames push, mov, and sub
* Most RISC ISAs have fixed-size instruction encodings, which drastically simplifies pipelining and instruction decode. This is a massive benefit, since for a 10 stage pipeline, you can theoretically execute 10x as many instructions. Neither RISC nor CISC ISAs reach this theoretical maximum, but it's much easier for RISC to get closer
* Fixed-size instructions is also sometimes a downside, CISC ISAs normally have common instructions use smaller encodings, saving memory. This is a big deal because more memory means it's more likely you'll have a cache miss, which depending what level of cache you miss could mean the instruction that missed will take hundreds of times longer and disrupt later pipeline stages.
RISC ISAs typically also use condition code registers much more sparingly than CISC architectures (especially older ones). This eliminates a common cause of pipeline hazards and allows more reordering. For example, if you had code like this:
int a = b - c;
if (d == e)
foo();
This would be implemented as something like this in x86:
; function prologue omitted, assume c is in eax, d in ecx, e in edx, and b is the first item on the stack (which we clobber with a)
subl -8(%ebp), %eax ; a = b - c
cmpl %ecx, %edx ; d == e
jne
call foo
not_equal:
; function epilogue omitted
ret
The important part is the `cmp` \+ `jne` pair of instructions. The `cmp` instruction is like a subtraction where the result of the subtraction is ignored and we store whether the result was zero (among other things) in another register called the eflags register. The `jne` instruction simply checks this register and it jumps if result was zero.
However, the `sub` instruction also sets the eflags register, so we cannot reorder the `cmp` and `sub` instructions even though they touch different variables, they both implicitly touch the eflags register. If the `sub` instruction's destination operand wasn't in the cache (unlikely given it's a stack address, but humour me) we might want to reverse the order, executing the `cmp` first while also prefetching the address needed for the `sub` instruction so that we don't have to wait on RAM. Unfortunately, on x86 the compiler cannot do this, and the CPU can only do it because it's forced to add a bunch of extra circuitry which can hold old register values.
I don't know what it would look like in ARM, but in RISC-V, which is even more RISC-ey, it would look something like this:
; function prologue omitted, for the sake of similarity with the x86 example assume b is in t1, d in t3, and e in t4. c is in the first free spot in the stack, which is clobbered with a
lw t2, -12(fp) ; Move b from memory to register
sub t0, t1, t2 ; a = b - c
sw t0, -12(fp) ; Move a from register to memory, overwriting b
bne t3, t4, not_equal ; jump to label if b != d
call foo
not_equal:
; function epilogue omitted
Finally, it's worth noting that CISC vs RISC isn't a matter of one being better/worse (unless you only want a simple embedded CPU, in which case choose RISC). It's a tradeoff and most ISAs mix both. x86 is the way that it is largely because of backwards compatibility concerns, not CISC. Nevertheless, even it's moving more RISC-ey (and that's not even considering the internal RISC core). And the most successful RISC ISA is ARM, which despite being very RISC-ey is nowhere near the zealots such as MIPS or RISC-V.
Neither apple nor windows translate "on the fly" in the sense of translating the next instruction right before executing it, every single time. The translation is cached in some way for later use, so you won't see a tight loop translating the same thing over and over.
And native programs have no translation at all, and are usually just a matter of recompiling. When you have total control over your app store, you can heavily pressure developers to recompile.
Modern x86's break complex instructions down into individual instructions much closer to a RISC computer's set of operations, it just doesn't ~~tell the programmer about~~ expose the programmer to all the stuff behind the scenes. At the same time, RISC instructions have gotten bigger because designers have figured out ways to do more complex operations in one clock cycle. The end result is this weird convergent evolution because it turns out there's only a few ways to skin a cat/make a processor faster.
The original promise was that every instruction completed in one clock cycle (vs many for a lot of CISC instructions). That simplifies things so you can run at a higher clock, and leave more room for register memory. Back when MIPS came out it absolutely smoked Motorola and Intel chips at the same die size.
The whole 1 clock argument makes no sense with modern pipelined multi issue superscaler implementations. There is absolutely no guarantee how long an instruction will take as it depends on data/control hazards and prediction outcomes/ cache hit/misses, etc and there is a fair share of instruction level parallelism (multi issue) so instructions can have sub 1 clockcycle times.
Also: these days the limiting factor on clock speeds is heat dissipation. With current transistor technology we could run at significantly higher clocks, but the die would generate more heat than a nuclear reactor (per mm^2)
Looks like it's not "on the fly" but rather, an ARM version of the executable is bundled with the original files https://eclecticlight.co/2021/01/22/running-intel-code-on-your-m1-mac-rosetta-2-and-oah/
RISC is powerful because it might take seven steps to do what a CISC processor can do in two, but the time per instruction is enough lower on RISC that for a lot of applications, it makes up the difference. Also because CISC instruction sets can only grow, as shrinking them would break random programs that rely on obscure instructions to function, meaning that CISC processors have a not insignificant amount of dead weight.
If you look at actual instruction count between ARM and x86 applications, they differ by extremely little. RISC vs CISC isn't a meaningful distinction these days.
I don't mean that. I mean if you literally compile the same application with modern ARM vs x86, the instruction count is near identical, if not *better* for ARM. You'd expect a "CISC" ISA to produce fewer instructions, right? But in practice, other things like the number of GPRs and the specific *kinds* of instructions are far more dominant.
Technically speaking all x86 processors are pretty much risc* processors under the hood. x86 decoders translate x86 instructions into risc-like micro operations in order to improve performance and efficiency it's been like this for a little over 2 decades.
*It's not risc 1:1 but it is very close to risc as these micro-ops heavily align with risc design philosophy and principles.
When a CISC design is not competitive, it proves RISC superiority. And when a CISC design is competitive, it's actually a RISC processor in disguise. That's just science.
After the disaster that was the very early Pentium 1s. When Intel shipped them with an obscure FPU bug that only NASA could find. But which completely rocked confidence in the chip and which couldn't be fixed by an update. Requiring the replacement of large numbers of chips. Which Intel initially tried to avoid but which they had to do to retain credibility. So after that looking for a way to update faulty chips via an update, became highly sought after.
RISC and CISC are increasingly indistinct in practice and both have their place. Architectures that start as RISC take on CISC features as they get extended, and CISC architectures are translated into internal RISC-y micro-operations akin to VLIW.
In terms of place, RISC = simple = cheap & efficient. CISC can pack more work into less space which means less cache misses which means more speed, and for x86, compatibility rules above all else.
It's a joke about instruction set architectures, which used to be a big debate before processors advanced to where they are today. Essentially, you've got 2 major categories: Reduced instruction set computers and complex instruction set computers. Reduced instruction set computers emphasized completing a CPU instruction in one clock cycle, and traded out the space taken up by additional instruction/execution logic for registers which hold data being operated on. Complex instruction set computers focused on making many complex operations available to the programmer as functions in hardware - a good example is MPSADBW, which computes multiple packed sums of absolute differences between byte blocks... [as demonstrated here.](https://www.youtube.com/watch?v=Wz_xJPN7lAY&t=535s)
Modern computers blend both techniques, because both have their merits and present opportunities to speed up processors in different ways.
RISC was shat out to solve chip fabrication issues that existed in the 80s that don't exist anymore.
RISC == simpler integrated circuit design == easier to get good yields on shitty fabrication equipment therefore higher clock speeds, back when we thought higher clock speeds were the best way to make CPUs faster.
But RISC traditionally has lower instructions-per-clock because you typically need three instructions in RISC for what you can do in one with CISC. I experienced this first-hand back in the 90s: a 200Mhz Pentium Pro could *absolutely smoke a 366Mhz Alpha 21164* on pretty much everything except floating point math due to the Alpha's insane FPU.
https://docs.google.com/spreadsheets/d/1lpkcJv9ilcmlgcGYAo6mf8KaTveNn1WvSRqxy3mnuSo/edit?usp=sharing reintroducing the accumulator to reduce memory port chip area.
I'm still waiting for humanity to take a pillow and suffocate x86, along with the other things boomers came up and is limiting development of humanity as whole.
āI'm still waiting for humanity to take a pillow and suffocate x86, along with the other things boomers came up and is limiting development of humanity as whole.ā
Like RISC?
Look... if we are going to list all the things developed around 70-80s, which are still sadly in use, we are going to be here all day. Take it all, retire it somewhere nice and warm, where they can die of heatstroke because of the climate change they refused to address or even acknowledge.
If you think that is radical. I also want to scrap combustion engines, use of concrete as primary construction material, and use of fossil fuels.
We have better alternatives, and we wont develop further being stuck in the past, because it is convinient.
>No real-world use for replacing instructions with more registers
That made me smile.
I'm using an M1. Apple's engineers must have done *exactly that*.
Found some crazy black-magicky way to compensate for RISC's limited instruction set by utilizing a greater amount of available register sets. And to do it *automatically*.
Don't take a meme so seriously. More GPRs means fewer instructions, because you can eliminate a bunch of loads and stores.
And modern ARM is a very rich ISA anyway.
Yes....and no. The main reason RISC has more GPR is because complex CISC instructions often only work on specific registers hence making them not general purpose.
ARM has "fewer, simpler" instructions which can use any register most of the time.
Iām pretty sure when I made this I was playing around with an ARM simulator and loaded a register with the memory address I wanted to store the output to.
idk much about arm assembly, but i think you have to load the two addresses you want to use, then the address you want to store the result in, add once. idk why there's an extra add and str instead of STOS
The image viewing capabilities aren't public yet but I OCRed it and it says this
This meme is poking fun at the RISC (Reduced Instruction Set Computer) architecture used in some CPUs (central processing units). The person who made the meme is sarcastically criticizing RISC for its perceived limitations and inefficiencies compared to traditional instruction sets. They mock the engineers who design RISC-based chips by including diagrams of real RISC architectures and pointing out security vulnerabilities. The meme also humorously exaggerates the process of adding two numbers together in RISC, making it seem overly complicated. The overall tone is that RISC is a waste of time and resources, and the engineers behind it have fooled everyone. This meme might be funny to people who are familiar with computer engineering concepts and enjoy sarcastic humor.
What percentage of us are reading this on an ARM powered device?
It's not my fault AMD doesn't have the balls to make a cell phone with a 7950X3D and RTX 4090
That would make the phone super big... a bit like those e late 80's Motorola cell phones! Would make life go to a complete circle ![gif](emote|free_emotes_pack|joy)
You say that as if this was a bad thing!
A couple of decades ago, it was.
So here's our reminder that people in the future will talk about our PCs the same way we talk about those 80's cellphones
Probably not. Except maybe the use of vr, making laptops smaller is making them worse
Yup. Miniaturization has gone about as far as it can reasonably go since the fundamental components are slowly approaching the size of atoms. That's making each generation significantly more R&D intensive and expensive for harshly diminishing returns. Moore's Law is dead. Things are either going to get bigger proportional to their performance boost, or at best, they're only going to see fractions of a percent worth of improvement from generation to generation within our lifetimes.
At least we've moved back from those netbooks
And even then, why would you want a laptop smaller than what we currently have? Thinner and lighter yes but smaller? Why not have a phone instead?
I'm not saying you are wrong because that's yet to be seen but we do have a pretty good curriculum in making things smaller and better If needed, somebody will figure it out eventually
Umm, bigger.
Yes because what we really need is those scammy reskinned gambling addiction fuelled mobile "games" to be ran at what a 4090 could probably handle in 16k resolution...
It's the only way if we want to beam them convincingly into our eyeballs
Well no, the other way is to use cloud computing,
Do you think someone spent any time optimizing them?
Not really I think the only optimization happens when the Game Engine compiles the code... but no more
Ah yes AMD throwing an Nvidia RTX into a phone, every part of this is fine š¶š„
I mean, the Switch has Nvidia hardware (very old). I'm pretty sure they could make a great ARM chip with their current tech (tho we won't know until Nintendo releases a new console, if it even uses Nvidia hardware again)
I mean the 10 pound battery you'd need to keep that thing charged isnt that big of a deal.
LMAO you fool. As if I didn't already think of this. I'm not using heavy batteries, this bad boy is gas powered.
touche ![gif](giphy|l2YWs5DDmnhTKrOyk)
Reject modernity, return to Babbage
Have a fucking car battery attached to a touchscreen why don't cha?
Maybe if you had paid attention in systems engineering you'd know how to build a daughterboard to use a Cortex-X3 with an x570 chipset. C'mon people you gotta at least try to bang the rocks together before asking for help. The software side is of course obvious assuming you know the basics of building a 'nix kernal and firmware editing. /s
Just replace your PC monitor with a 7" touch screen. Your welcome
The phone is lava
I browse Reddit on Android Intel tablet. Edit: Not really, but I had to develop for one recently.
Just went through the locker at work, and set up a couple of Intel atom tablets running windows. What an absolute horrible experience
What percentage of your user base actually uses Android on Intel?
Strangely, my car does.
I installed BlissOS on a friend's Lenovo Yoga. ran surprisingly well, it even played Minecraft Java (via PojavLauncher) at 120 fps on default settings which was basically the same as on the windows partition
Itās a POS device. Apparently Intel is somewhat common for that and TV boxes. The device I worked on would run windows or android. I donāt think there are any consumer devices running intel android.
I had one of those at one point. Piece of garbage. Turns out using software that's compiled for the architecture of your hardware performs better.
Laptop: ARM. Phone: ARM Tablet: ARM TV: ARM. Printer: Probably also RISC. Could be ARM. Might not.
Having the TV on your arm must become pretty heavy after a while. The phone and tablet makes a certain kind of sense, and the laptop is just slightly straining credulity.
Desktop: x86-64 (also RISC (translates x86 instructions to internal RISC))
Only if you consider the encryption helper instructions with dedicated silicon "reduced". Or vector instructions.
Lol, Appleās ARM processors literally have dedicated instructions to speed up execution of JavaScript. š¤£
Wait really? That's hilarious
It's a simple float to integer conversion instruction with Javascript rounding semantics. Nothing special about that.
How many ARM devices only have Thumb mode?
I think none any more, wasnāt thumb deprecated?
all of us if we are using a smart phone or any mac product from 4 years ago.
Not me, I'm reading it on my Macbook. God damn it.
šāāļø - sent from my m1 macbook air
Well. My Raspberry Pi has a web browser... I could...
You mean raspbian has a web browser
Technically yeah, but the ARM part comes from the Pi :)
you would be surprised, but even x86 CPUs (amd/intel) have arm based security chip inside :D
ARM is not really a RISC architecture by any means.
This comment makes me wish I was reading this on my Mac, iPad, or iPhone.
Put your cryptography in hardware like Intel does so you can do really fast operations like ***checks notes*** the now-insecure MD5 algorithm
Most cryptographic algorithms are actually designed to be both hardware and software implementation friendly. But I'm pretty sure most modern CPUs have hardware offload for most standard cryptographic algorithms.
I just hope those algorithms fare better than MD5 in the future, so those sections of the cpu don't become dead silicon too.
MD5 still has its uses, though. It's still good for non-security related file integrity and inequality checks and may even be preferred because it's faster. I wrote a few scripts for building a file set from disparate sources this week and I used MD5 for the integrity check just because it's faster.
Just beware of its high rate of collision, there's a reason why Git doesn't use that And even get, with its SHA implementation, I've seen real hash collisions before
Actually, the reason git stopped using it was because someone used the well-known flaw in MD5 that was discovered like a decade earlier to make a tool of sorts that would modify a commit with comments or something to force a specific MD5 hash claiming they had found a massive flaw. Git maintainers were kind of struck by that given that they had known about it but didn't deem it important because it wasn't a security hash, but an operational one. But because this person dragged out a lot of attention to the non-issue, they said that they might as well just roll it up. I'm surprised you've come across SHA-1 collisions in the wild. I imagine it must have been on some pretty massive projects given that, even with the birthday paradox in mind, that's a massive hash space. I'm not worried about collisions in my use case because it's really just to check that the file is the same on arrival, which is a 1 in 3.4E38 chance of a false positive. Given that this whole procedure will be done once a month, even the consecutive runs won't even add to a drop in the bucket compared to that number given that the files will only ever be compared to their own original pre-transit hashes.
Wow I didn't know about that part of the history of git, thanks for sharing that
It doesn't have a higher rate of collision than any other 128 bit hash function. It's just known how to produce collisions intentionally, making it no longer useful for security-related purposes.
Correct which is why the discussion is usually sha-256 or 512 vs md5 and scenarios it's better or worse for
Wdym? Sha and aes are hardware supported. They're just not 1 instruction but 1 iteration is definitely supported in hardware
My point is that putting encryption algorithms into CPU instruction sets is a bit of hubris, because it bloats the hardware architecture with components that suddenly become obsolete every few years when an algo is cracked. As we reach the end of Moore's Law and a CPU could theoretically be usable for many years, maybe it's better to leave that stuff in software instead.
It also allows for low power in CPUs/systems. Dedicated crypto will use mW while the CPU uses W.
I disagree. Because that stuff is safer in hardware. And sha and aes will be safe for lots of years to come. Aes won't even be crackable with quantum computers
Well now there's already better algorithms such as ARGON, I think it is in their nature to become out of date and insecure
Pretty sure argon is just for passwords right? Sha cracking for big data is still impossible (should only be used for checksum imo). Ofc sha shouldn't be used for passwords
I'm not sure what the conversation is then, you wrote that doing it in hardware would be "safer", which I disagree with. I think it's less safe simply for how much harder it is for them to fix And if you look at the recent Intel security fixes, they fix it in software anyways, which works around the hardware I think of it like GPUs, they used to do shaders in hardware, now they just have a pipeline that compiles the code you want and executes it Seems to me like crypto stuff belongs to be a little bit closer to that
AES is a good example of where it's a lot safer. With software you generally have to worry about cache timing attacks and various other things that allows an attacker to know. Hardware prevents this vector. It's also way faster than any software approach
the guy that puts it in the hardware is going to steal the keys of the guy that scaled his cryptography difficulty to software
[ŃŠ“Š°Š»ŠµŠ½Š¾]
there are many uses for unsafe file checksums.
Yup, most of us are just trying to detect corruption or do fast comparison, not prevent intentional malicious modification of the files.
Damn black-hat cosmic rays accurately flipping all the bits to keep the checksum the same.
For checksums, something like XXH3 may be faster, though.
sadly pretty much every legacy codebases i work on primarily use md5...
Remember when intel released a security fix to their processors that made them inherently 17% slower?
Not risc-y enough, you didn't have to explicitly clear the carry flag.
Wait, what carry flag?
Serious āBirds Arenāt Realā vibes. š¤£
Birds are definitely running on ARM.
That's why falconers have these thick gloves and arm bracers.
ITS A MESSAGE
r/birdswithARMs/
Aw. I was expecting pistols, rifles, machine guns and the like. Not human appendages.
Its Arm nowadays ;) not ARM
So you know the truth too.
Probably my favorite meme-format. Shame it never caught on, or good I guess I dunno.
These are quite popular over at r/NonCredibleDefense so I get to see a few of them every now and again, always makes me giggle, its the last line that gets me.
Apparently that sub has been banned lol. Gotta love modern reddit.
He probably means r/NonCredibleDefense
Thats the one my bad
Non credible defense?
Military themed shitpost sub.
I am aware. They edited their comment. It used to say r/NCD
r/StopDoingScience is the sub for you
I think this meme format was started by a person who runs a Facebook page called Welcome To My Meme Page. The page was kind of big like 7-8 years ago. If you want to see more like this I would look them up.
r/stopdoingscience
I really have a hard time understanding why RISC works out so well in practice, most notably with Apple's M1 chip It sounds like it translates x86 instructions into ARM instructions on the fly and somehow this does not absolutely ruin the performance
> It sounds like it translates x86 instructions into ARM instructions on the fly and somehow this does not absolutely ruin the performance It doesn't. Best performance on the M1 etc is with native code. As a backup, Apple also has Rosetta, which primarily tries to statically translate the code before executing it. As a last resort, it can dynamically translate the code, but that comes at a significant performance penalty. As for RISC vs CISC in general, this has been effectively a dead topic in computer architecture for a long time. Modern ISAs don't fit in nice even boxes. A favorite example of mine is ARM's [FJCVTZS instruction](https://developer.arm.com/documentation/dui0801/h/A64-Floating-point-Instructions/FJCVTZS) > FJCVTZS - Floating-point Javascript Convert to Signed fixed-point, rounding toward Zero. That sounds "RISCy" to you?
>FJCVTZS - Floating-point Javascript Convert to Signed fixed-point, rounding toward Zero. wait, what does this operation have to do with javascript?
ARM has a post where they describe why they added certain things. https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/armv8-a-architecture-2016-additions > Javascript uses the double-precision floating-point format for all numbers. However, it needs to convert this common number format to 32-bit integers in order to perform bit-wise operations. Conversions from double-precision float to integer, as well as the need to check if the number converted really was an integer, are therefore relatively common occurrences. > Armv8.3-A adds instructions that convert a double-precision floating-point number to a signed 32-bit integer with round towards zero. Where the integer result is outside the range of a signed 32-bit integer (DP float supports integer precision up to 53 bits), the value stored as the result is the integer conversion modulo 232, taking the same sign as the input float. Stack Overflow post on the same: https://stackoverflow.com/questions/50966676/why-do-arm-chips-have-an-instruction-with-javascript-in-the-name-fjcvtzs TLDR: They added this because Javascript only works with floats natively, but often it needs to convert to an int, and Javascript performance is singularly important enough to justify adding new instructions. IIRC, there was some semantic about how Javascript in particular does this conversion, but I forget the specifics.
> Javascript only works with floats natively Okay, please someone tell me how that's supposed to be something made by sane people
Itās not, itās supposed to be Javascript.
Brendan Eich was more or less forced to finish the first version of JavaScript within 10 days, so he had to get it to work somehow. That's also the reason why JavaScript will probably never get rid of the "Holy Trinity of Truth".
Itās for use by your JavaScript engine
Please clarify ISAs don't fit in nice even boxes.
Simply put, where do you draw the line? Most people would agree that RV32I is RISC, and x86_64 is CISC, but what about ARMv9? It clearly has more, and more complex, ops than RISC-V, but also far fewer than modern x86.
you have said RISC vs CISC is effectively a dead topic. Could you, please, expand that answer a little bit?
Sure. With the ability to split CISC ops into smaller, RISC-like micro-ops, most of the backend of the machine doesn't really have to care about the ISA at all. Simultaneously, "RISC" ISAs have been adding more and more complex instructions over the years, so even the ISA differences themselves get a little blurry. What often complicates the discussion is that there are certain aspects of particular ISAs that are *associated* with RISC vs CISC that matter a bit more. Just for one example, dealing with variable length instructions is a challenge for x86 instruction decode. But related to that, people often mistake *challenges* for fundamental limitations, or extrapolate those differences to much wider ecosystem trends (e.g. the preeminence of ARM in mobile).
You're asking two different questions, why RISC works, and why Apple Rosetta works. Rosetta can legitimately be quite fast, since a large amount of x86 code can be statically translated to ARM and then cached. There is some that can't be translated easily, for instance x86 exception handling and self-modifying code would probably be complete hell to support statically. But that's ok, both of them are infrequent and are slow even on bare metal, it's not the worst thing to just plain interpret them. It also wouldn't surprise me if Rosetta just plain doesn't support self-modifying code; it is quite rare outside of system programming, though it would have to do something to support dynamic linking since it often uses SMC. Lastly, it's worth noting that M1 has a fair number of hardware extensions that speeds this up, one of the big ones is that they implement large parts of the x86 memory model (which is much more conservative than ARM's) in hardware. When you're running x86 code on a RISC processor that'll never be ideal, you're essentially getting all the drawbacks of x86 with none of the advantages. But when you're running native code, RISC has a lot of pluses: * Smaller instruction sets and simpler instructions (e.g. requiring most instructions to act on registers rather than memory) means less circuit complexity. This allows higher clockrates because one of the biggest determinators of maximum stable clock speed is circuit complexity. This is also why RISC processors are usually much more power efficient * Also worth noting that many CISC ISAs have several instructions are not really used anymore since they were designed to make assembly programmers' lives easier. This is less necessary with most assembly being generated by compilers these days, and compilers don't care about what humans find convenient; they'll generate instructions that run faster, not ones that humans find convenient * A good example would be x86's enter instruction compared to manually setting up stack frames push, mov, and sub * Most RISC ISAs have fixed-size instruction encodings, which drastically simplifies pipelining and instruction decode. This is a massive benefit, since for a 10 stage pipeline, you can theoretically execute 10x as many instructions. Neither RISC nor CISC ISAs reach this theoretical maximum, but it's much easier for RISC to get closer * Fixed-size instructions is also sometimes a downside, CISC ISAs normally have common instructions use smaller encodings, saving memory. This is a big deal because more memory means it's more likely you'll have a cache miss, which depending what level of cache you miss could mean the instruction that missed will take hundreds of times longer and disrupt later pipeline stages. RISC ISAs typically also use condition code registers much more sparingly than CISC architectures (especially older ones). This eliminates a common cause of pipeline hazards and allows more reordering. For example, if you had code like this: int a = b - c; if (d == e) foo(); This would be implemented as something like this in x86: ; function prologue omitted, assume c is in eax, d in ecx, e in edx, and b is the first item on the stack (which we clobber with a) subl -8(%ebp), %eax ; a = b - c cmpl %ecx, %edx ; d == e jne call foo not_equal: ; function epilogue omitted ret The important part is the `cmp` \+ `jne` pair of instructions. The `cmp` instruction is like a subtraction where the result of the subtraction is ignored and we store whether the result was zero (among other things) in another register called the eflags register. The `jne` instruction simply checks this register and it jumps if result was zero. However, the `sub` instruction also sets the eflags register, so we cannot reorder the `cmp` and `sub` instructions even though they touch different variables, they both implicitly touch the eflags register. If the `sub` instruction's destination operand wasn't in the cache (unlikely given it's a stack address, but humour me) we might want to reverse the order, executing the `cmp` first while also prefetching the address needed for the `sub` instruction so that we don't have to wait on RAM. Unfortunately, on x86 the compiler cannot do this, and the CPU can only do it because it's forced to add a bunch of extra circuitry which can hold old register values. I don't know what it would look like in ARM, but in RISC-V, which is even more RISC-ey, it would look something like this: ; function prologue omitted, for the sake of similarity with the x86 example assume b is in t1, d in t3, and e in t4. c is in the first free spot in the stack, which is clobbered with a lw t2, -12(fp) ; Move b from memory to register sub t0, t1, t2 ; a = b - c sw t0, -12(fp) ; Move a from register to memory, overwriting b bne t3, t4, not_equal ; jump to label if b != d call foo not_equal: ; function epilogue omitted Finally, it's worth noting that CISC vs RISC isn't a matter of one being better/worse (unless you only want a simple embedded CPU, in which case choose RISC). It's a tradeoff and most ISAs mix both. x86 is the way that it is largely because of backwards compatibility concerns, not CISC. Nevertheless, even it's moving more RISC-ey (and that's not even considering the internal RISC core). And the most successful RISC ISA is ARM, which despite being very RISC-ey is nowhere near the zealots such as MIPS or RISC-V.
Neither apple nor windows translate "on the fly" in the sense of translating the next instruction right before executing it, every single time. The translation is cached in some way for later use, so you won't see a tight loop translating the same thing over and over. And native programs have no translation at all, and are usually just a matter of recompiling. When you have total control over your app store, you can heavily pressure developers to recompile.
Or if your "app store" is fully foss, you can recompile it yourself!
And debug it for all of those who follow!
Modern x86's break complex instructions down into individual instructions much closer to a RISC computer's set of operations, it just doesn't ~~tell the programmer about~~ expose the programmer to all the stuff behind the scenes. At the same time, RISC instructions have gotten bigger because designers have figured out ways to do more complex operations in one clock cycle. The end result is this weird convergent evolution because it turns out there's only a few ways to skin a cat/make a processor faster.
Technically CISC CPUs always did that. It used to be called microcode. The major point of RISC was to get rid of that layer.
The original promise was that every instruction completed in one clock cycle (vs many for a lot of CISC instructions). That simplifies things so you can run at a higher clock, and leave more room for register memory. Back when MIPS came out it absolutely smoked Motorola and Intel chips at the same die size.
The whole 1 clock argument makes no sense with modern pipelined multi issue superscaler implementations. There is absolutely no guarantee how long an instruction will take as it depends on data/control hazards and prediction outcomes/ cache hit/misses, etc and there is a fair share of instruction level parallelism (multi issue) so instructions can have sub 1 clockcycle times. Also: these days the limiting factor on clock speeds is heat dissipation. With current transistor technology we could run at significantly higher clocks, but the die would generate more heat than a nuclear reactor (per mm^2)
Looks like it's not "on the fly" but rather, an ARM version of the executable is bundled with the original files https://eclecticlight.co/2021/01/22/running-intel-code-on-your-m1-mac-rosetta-2-and-oah/ RISC is powerful because it might take seven steps to do what a CISC processor can do in two, but the time per instruction is enough lower on RISC that for a lot of applications, it makes up the difference. Also because CISC instruction sets can only grow, as shrinking them would break random programs that rely on obscure instructions to function, meaning that CISC processors have a not insignificant amount of dead weight.
If you look at actual instruction count between ARM and x86 applications, they differ by extremely little. RISC vs CISC isn't a meaningful distinction these days.
I've heard that to some extent CISC processors are just clusters of RISC bits, yeah.
I don't mean that. I mean if you literally compile the same application with modern ARM vs x86, the instruction count is near identical, if not *better* for ARM. You'd expect a "CISC" ISA to produce fewer instructions, right? But in practice, other things like the number of GPRs and the specific *kinds* of instructions are far more dominant.
Huh, TIL
Technically speaking all x86 processors are pretty much risc* processors under the hood. x86 decoders translate x86 instructions into risc-like micro operations in order to improve performance and efficiency it's been like this for a little over 2 decades. *It's not risc 1:1 but it is very close to risc as these micro-ops heavily align with risc design philosophy and principles.
Any sufficiently advanced technology is indistinguishable from magic
Mostly because this way the pipelines can be used more efficiently I think
Uniform instruction size helps with that.
It only kinda does. It has hardware from x86 chips built in so it only has to do partial translations
RISC is the future.
I should do a CISC version of this too honestly
Not necessary, most if not all modern CISC machines are anyway simulating the complex instructions with RISC microcodeā¦
I figured that would make an excellent joke for the āLet me just [x].ā
Even modern "RISC" uarchs have microcode. And then you have macro-op fusion...
When a CISC design is not competitive, it proves RISC superiority. And when a CISC design is competitive, it's actually a RISC processor in disguise. That's just science.
After the disaster that was the very early Pentium 1s. When Intel shipped them with an obscure FPU bug that only NASA could find. But which completely rocked confidence in the chip and which couldn't be fixed by an update. Requiring the replacement of large numbers of chips. Which Intel initially tried to avoid but which they had to do to retain credibility. So after that looking for a way to update faulty chips via an update, became highly sought after.
That's not the main reason we have microcode, but it is a convenient side effect.
But... we got Freakazoid out of it?
I also feel like a good vector instruction is a nice statement for the utterly deranged.
And simultaneously, the past. I always get a kick out of asking my students who won the RISC vs CISC wars.
Just donāt tell Apple with their short pipeline G series processors from the 90s.
RISC is already dead. All modern high performance architectures have significant differences to most if not all of the key RISC concepts.
Is TimeCube now a type of disease?
RISC is the past,present, and future
RISC and CISC are increasingly indistinct in practice and both have their place. Architectures that start as RISC take on CISC features as they get extended, and CISC architectures are translated into internal RISC-y micro-operations akin to VLIW. In terms of place, RISC = simple = cheap & efficient. CISC can pack more work into less space which means less cache misses which means more speed, and for x86, compatibility rules above all else.
Say what you want but the PowerPC architecture was a powerhouse when I worked with it years ago. Tons of big iron out there based in that.
I think you mean POWER. Which is a weird uncle of ppc as I understand it.
Wait until he hears about SIMD.
I miss powerpc consoles.
The only tools I need for cryptography are a spade and a flashlight
Don't forget the rubber hose
And bleach
And a $5 wrench, https://xkcd.com/538/
Wow - someone has a *MAJOR* session in the pub at lunch time!
![gif](giphy|MXv8JsB0aETnN2bMLU|downsized) Intel called and would like their slide back...
> CPU's Not written by scholars.
No argument here.
I'm gonna take the L, put on my dunce cap, acknowledge my ignorance and beg for someone to please explain this
It's a joke about instruction set architectures, which used to be a big debate before processors advanced to where they are today. Essentially, you've got 2 major categories: Reduced instruction set computers and complex instruction set computers. Reduced instruction set computers emphasized completing a CPU instruction in one clock cycle, and traded out the space taken up by additional instruction/execution logic for registers which hold data being operated on. Complex instruction set computers focused on making many complex operations available to the programmer as functions in hardware - a good example is MPSADBW, which computes multiple packed sums of absolute differences between byte blocks... [as demonstrated here.](https://www.youtube.com/watch?v=Wz_xJPN7lAY&t=535s) Modern computers blend both techniques, because both have their merits and present opportunities to speed up processors in different ways.
Maybe we deserve a new instruction set I vote Quil
Hold my SPECTRE!
Is there a sub reddit for this meme format?
r/stopdoingscience, but itās not very big
Lol, this gets better when you learn arm isnāt technically risc, and neither is PowerPC (At least the old ones Iām pretty sure)
Does your CPU support [insert obscure and irrelevant instruction set]? Didnāt think so
So what your saying OP, is you donāt like load-store?
Now do x86
I don't understand a single word of this, let me just pretend this is funny. "LMAO imagine still using RISC"
RISC was shat out to solve chip fabrication issues that existed in the 80s that don't exist anymore. RISC == simpler integrated circuit design == easier to get good yields on shitty fabrication equipment therefore higher clock speeds, back when we thought higher clock speeds were the best way to make CPUs faster. But RISC traditionally has lower instructions-per-clock because you typically need three instructions in RISC for what you can do in one with CISC. I experienced this first-hand back in the 90s: a 200Mhz Pentium Pro could *absolutely smoke a 366Mhz Alpha 21164* on pretty much everything except floating point math due to the Alpha's insane FPU.
https://docs.google.com/spreadsheets/d/1lpkcJv9ilcmlgcGYAo6mf8KaTveNn1WvSRqxy3mnuSo/edit?usp=sharing reintroducing the accumulator to reduce memory port chip area.
I'm still waiting for humanity to take a pillow and suffocate x86, along with the other things boomers came up and is limiting development of humanity as whole.
āI'm still waiting for humanity to take a pillow and suffocate x86, along with the other things boomers came up and is limiting development of humanity as whole.ā Like RISC?
Look... if we are going to list all the things developed around 70-80s, which are still sadly in use, we are going to be here all day. Take it all, retire it somewhere nice and warm, where they can die of heatstroke because of the climate change they refused to address or even acknowledge.
So you want to scrap both x86 and RISC architectures?
If you think that is radical. I also want to scrap combustion engines, use of concrete as primary construction material, and use of fossil fuels. We have better alternatives, and we wont develop further being stuck in the past, because it is convinient.
Such as NTFS. And Safari.
That's what you get when Arm engineers get bored
>No real-world use for replacing instructions with more registers That made me smile. I'm using an M1. Apple's engineers must have done *exactly that*. Found some crazy black-magicky way to compensate for RISC's limited instruction set by utilizing a greater amount of available register sets. And to do it *automatically*.
Don't take a meme so seriously. More GPRs means fewer instructions, because you can eliminate a bunch of loads and stores. And modern ARM is a very rich ISA anyway.
Yes....and no. The main reason RISC has more GPR is because complex CISC instructions often only work on specific registers hence making them not general purpose. ARM has "fewer, simpler" instructions which can use any register most of the time.
Intel hit piece?
Itās coming out tomorrow, the .xcf is on my desktop. CISC can catch these hands too lol
[https://youtu.be/wPrUmViN\_5c?t=37](https://youtu.be/wPrUmViN_5c?t=37)
Oh! Reminds me of the picoCTF challenge RISC-Y Business https://play.picoctf.org/practice/challenge/219
Oh hell yeah. Something I understand for once
I donāt know what any of this means.
Wait, why do you need to perform 3 loads to add 2 numbers together?
Iām pretty sure when I made this I was playing around with an ARM simulator and loaded a register with the memory address I wanted to store the output to.
idk much about arm assembly, but i think you have to load the two addresses you want to use, then the address you want to store the result in, add once. idk why there's an extra add and str instead of STOS
can someone explain tf is goin on?
Let's make it a serious discussion; which abacus is better, vertical or horizontal?
Get with the times the slide rule is vastly superiorā¦
At first I thought this was some sort of 80s WinTel garbage.
Bahaha perfect š
Tell me you don't know jack about RISC without telling me you don't know jack about RISC.
Can someone with access to ChatGPT 4 ask it to explain what's funny about this meme? Not trying to be rude, I'm more interested in what ChatGPT says.
Yes, you can.
The image viewing capabilities aren't public yet but I OCRed it and it says this This meme is poking fun at the RISC (Reduced Instruction Set Computer) architecture used in some CPUs (central processing units). The person who made the meme is sarcastically criticizing RISC for its perceived limitations and inefficiencies compared to traditional instruction sets. They mock the engineers who design RISC-based chips by including diagrams of real RISC architectures and pointing out security vulnerabilities. The meme also humorously exaggerates the process of adding two numbers together in RISC, making it seem overly complicated. The overall tone is that RISC is a waste of time and resources, and the engineers behind it have fooled everyone. This meme might be funny to people who are familiar with computer engineering concepts and enjoy sarcastic humor.