No need for a car != agreeable to live as a pedestrian. For example, I don’t need a car in SF but I wouldn’t compare it to a real and agreeable walkable city like we have in europe or asia. It’s mostly large streets designed for cars, residential areas, with shops only allowed to exist in limited commercial streets.
Both considered commuter hubs for DC. And I think they're alluding to being able to utilize the DC metro 'inside the beltway' (I-495) hence the distinction there, which is true to an extent, but I wouldn't live in NOVA or MD without a car personally. There is Amtrak service to areas outside of the beltway, but my experience with Amtrak has been extremely poor. I know many people in DC and they all own a car because the metro, while great for getting in and out of DC, is somewhat limited when it comes to going anywhere else.
Is it not a good reason to avoid living in red states if your rights are being taken away? I'd love to keep living in my blue city in the south, but I'd also love to keep getting the health care I need.
I will always remember that I was listening to Eleven Rings while driving from Portland to Smith Rock years ago. It's one of my favorite places and one of my favorite books. Those two things definitely became melded together in my mind.
What about climbing gyms, run clubs, book clubs, gardening clubs, bars/trivia, etc? If you're near a city, almost any of these will be an option. And if you're not, a high percentage of those people are probably still going to church. It seems there are still a lot of opportunities out there for regular communion with others.
Hobby clubs are better than nothing, but religions have much better structure to keep community members in check and check their mental health regularly.
My point was more that 'RISC vs CISC' is not a useful way to compare two processors. In the same way CISC CPUs break down instructions into a series of micro-ops, RISC CPUs (like the RISC-V) fuse instructions into macro-ops. Yes the ISA is different and yes that imposes some constraints on the design but it's not a particularly useful way of comparing two processors.
Ok CISC ISAs are out of favor today, although I suspect as some of these RISC ISAs age, they'll accrete instructions. The ARM ISA sure is a lot chonkier than it used to be. Modern ARM CPUs have a massive micro-op cache just like x86 CPUs do. I wouldn't be surprised if we wake up one day and it's half way to x86.
In my opinion ISA isn't relevant or interesting. [1]
I echo the sentiments in this article:
> In short, there’s no meaningful difference between RISC/ARM and CISC/x86 as far as performance is concerned. What matters is keeping the core fed, and fed with the right data which puts focus on cache design, branch prediction, prefetching, and a variety of cool tricks like predicting whether a load can execute before a store to an unknown address.
So to your point that:
> Today, [RISC] makes more sense than ever.
I would respond, today, it makes less difference than ever.
What actually happens under the hood of a modern performance-optimized CPU is so far removed from the ISA that the ISA is just a design curiosity.
'RISC architecture' isn't going to 'change everything' - how it's implemented: advances in branch prediction, prefetching, etc - that's going to continue to iteratively improve processors. The number of instructions is truly not a factor of note.
Does it never matter? Probably sometimes. Once in a while in some very specific applications - like pico-amp scale microcontrollers - it might? But for anything you’re thinking of it’s super irrelevant.
>My point was more that 'RISC vs CISC' is not a useful way to compare two processors.
It isn't. Instead, it is a way to compare ISAs. And RISC is the way to go, because we've known for some 40+ years that CISC is bad.
>In my opinion ISA isn't relevant or interesting.
Except when it is.
One example: x86 is too complex to be reasoned with, so it's not an option where high assurance (and thus formal proofs) is a necessity.
>What matters is keeping the core fed, and fed with the right data which puts focus on cache design, branch prediction, prefetching, and a variety of cool tricks...
Another example: ARMv8 and v9 have horrendous code density. As a result, L1 needs to be larger to fit the same amount of code. Which means lower frequency. larger area and higher power usage. Similarly, a microcontroller's ROM would have to be larger to fit the same program, also bad.
>RISC CPUs (like the RISC-V) fuse instructions into macro-ops.
Not really. Fusion is mostly academic, rather than an industry standard. E.g. no RISC-V processor in the market does fusion[0].
>I would respond, today, it (RISC) makes less difference than ever.
For most applications, end users don't know or care what ISA is in there.
But, for anyone actually designing systems, it does matter. Complexity breeds bugs. Most bugs are security bugs. x86's (the one CISC that still sees chips fabbed, large scale) complexity is insane. And security thus impossible; a losing proposition.
In the present hyper-networked world, this is unacceptable. In IoT, using x86 should be criminal negligence, and we will no doubt see it actually recognized as such in the courts at some point in the not-so-distant future.
x86 had a good run. It's already well past the time to move on, leave it in the past where it belongs.
These are all great opinions that are countered soundly by the article I linked. Do you have articles you suggest I read?
> And RISC is the way to go, because we've known for some 40+ years that CISC is bad.
Quantify 'bad'. Again these are all opinions.
Nobody will argue with you x86 is terrible. What I'm saying, backed by the article I linked, is that the fact the x86 ISA is terrible really doesn't hold it back. And once you start optimizing a RISC architecture, over time, for performance, it quickly approaches the same thing.
> Not really. Fusion is mostly academic, rather than an industry standard. E.g. no RISC-V processor in the market does fusion[0].
It doesn't depend on fusion but since 2016 it's pretty clear it'll be an optimization. A big one! Which means that complexity is coming whether or not any market cores implement it today or not, which is part of the argument I'm making haha. Once you take the path of these optimizations, the cores start to look pretty familiar. Read the reply to the comment you linked.
Nobody is going to leave performance on the table to satisfy some niche opinions on complexity being bad.
> But, for anyone actually designing systems, it does matter.
What is "actually designing systems" today? There's complexity in everything (especially anything performant) and frankly, that complexity is abstracted effectively by compilers and operating systems.
> In the present hyper-networked world, this is unacceptable. In IoT, using x86 should be criminal negligence, and we will no doubt see it actually recognized as such in the courts at some point in the not-so-distant future.
Citation needed?
> x86 had a good run. It's already well past the time to move on, leave it in the past where it belongs.
> The world is falling apart and people are still worried about harmless words.
The parent mentioned that it prevents him from sharing, not that they were personally worried about it. I'm also perfectly comfortable using salty language with friends and family, but very rarely use it on social channels. It's all about context.
The world is falling apart and people are worried about Nim compiler version 2.0. Talk about misplaced concerns.
The world is falling apart and people are worried about who wins champions league this year. Talk about misplaced concerns.
Where exactly is the line for you? What if this article began with a picture of a guy with his dick out fucking a pig that had a picture of an airport drawn on it. Would that still be acceptable? Because if its not then I have to say. The world is falling apart...
