The immune systems does nothing by accident. The immune system is always trying to keep the microbiome in balance and the microbiome helps the immune system as well.
If you’re not speculatively executing, you don’t need a branch hint because you don’t need to speculate which way it goes.
Also, I don’t think executing both sides of a branch ever took off on any mainstream CPUs (unless Itanium counts). It wastes power to spend half your execution units on things that won’t be committed, why not use them on the other hyperthread instead?
> Also, I don’t think executing both sides of a branch ever took off on any mainstream CPUs
That part I am sure off. I will double check with a friend of mine of of curiosity, but one thing to note is that the execution units are processing branches up to the point when branch is evaluated, then the false path is dropped.
Back then the speed was trumping the power draw. I am not sure what are the priorities today.
In terms of hyperthread, i don't think you can safely execute instructions of both siblings due to possible shared cache mem clashes. But I am guessing now. Its been a while since I have been working that low level to remember the details.
I don't know of any CPU that speculates both sides of a branch. I work on a CPU design team.
Modern CPUs speculate hundreds of instructions ahead, and with just a dozen branches you can have a few thousand different paths. It makes more sense to speculate down one path with very high accuracy.
I think a lot of folks get mixed up with GPU and/or SIMD architecture, where you execute both sides of the branch out of necessity: Some of the lanes need to go one way and some the other, so you have to do both.
I’ve always thought this would be an interesting use for a hyperthread (send it to execute both sides of an if, when the programmers knows the branch predictor is likely to not be able to know which side is right). But, never got around to coding anything like that up…
the problem is that when you care (unpredictable but hot branches), there are probably too many of them to execute in parallel (use up all your speculation depth). 2^n, you know!
Is both. They cause gravitational waves, which is how the system gets rid of energy, which allows the orbits to decay, causing the collision (and more waves).
To be clear, the fact that the collision causes more waves does not seem to be relevant here.
It is the loss of energy due to gravitational wave emission that causes the collision. Ambient gravitational waves from other sources do not seem to play a part?
My uninformed opinion: lots of speculative execution is good for single core performance, but terrible for power efficiency.
Have data centres always been limited by power/cooling costs, or did that only become a major consideration during the move to more commodity hardware?
One thing I really appreciate about Suica is the low latency. You can tap while walking quickly and not have to slow down to get through the ticket gate. Compared with e.g. London, where you have to almost stop because the gates take so long to open, it really makes it easy for a trainload of people to get out of a station.
The name is also a bad pun; Sui-sui is onomatopoeia for smooth movement (like fish swimming), so it’s the card for moving smoothly. Also, suica means watermelon so the card is green.
So I purchased an Apple watch and I was really excited to have contactless payments...it's fucking awkward with Mastercard or Visa to be standing there with your arm twisted in a strange way waiting for the payment to be approved. Kind of always seems like it's not going to work and people always have to make some type of joke to make you feel less weird about it.
Suica is also available on the watch and it's much better? Why is that?
Suica is a stored value card, so you don't have to do an online balance check to validate a transaction.
There is also probably a practical element to it, in that Suica and other IC cards are managed by entities that are closely linked to the various train systems in Japan. The terminals are known to them, the cards were all issued by them; they can probably preload a lot of stuff at all the train stations and keep the data regarding the cards synced directly among the stations. (It's at least feasible that by the time you get to the next station, 90% of the time, the information about your card is already there.) This is in contrast to what would happen if you used Mastercard or Visa to pay for train fares, where all the data would first have to go to northern Virginia...
Suica defaults to express/transit mode in Apple Pay/Wallet. Using it in your phone is as quick as using a physical card.
Express mode can be configured with plenty of other cards as well, even regular credit cards. That's how it works in London. The difference in speed is because of the gates, not the payment system.
That has nothing to do with the technology in the IC card.
In terms of real life use, a Suica card in Apple Wallet is indistinguishable from a physical Suica card. Suica itself isn't that much different from any other prepaid transit card, so I don't get the hype. This is some early 2000s technology.
Personally, I see no difference in speed when paying with either an Oyster card (London), an EZCard (Taiwan), a Suica Card, or any Apple Wallet card in transit mode.
the 100-200ms is a big deal, and it's not some random spec, JR made it a binding requirement to use their system after real world evaluation of the latency impact. So yes, Felica is also sub 200ms for that part.
As a user, there's so much going on when touching a card at rush hour for instance, getting virtually no perceivable latency helps us to focus on the rest (distance, angle, check the screen, distance with the person ahead). As you point out in other comment, of course the design of the whole gate comes into play to help the user deal with it.
It reminds me of the microsoft study on how low the latency has to be to become transparent to the user. Except JR actually cared about their results.
The difference is immense between an Oyster or EZCard and a Suica.
The EZCard and Oyster gates often have lines because of how long it takes for the gates to recognize the EZCard; you'll have people queuing up to get into the station. They as a bottleneck where the flow of traffic is interrupted and slowed down to below walking speed.
This is important as it disrupts flow and public transit during rush hour and is unacceptable. You can see for instance in this video, when people are tapping their cards they are slowing down and waiting for the transaction.
This makes a BIG difference for how many people can enter the station at once. With Suica/NFC-F you've essentially removed the station gates as a barrier for traffic flow, whereas with Oyster/EZCard (and EZCard being a HUGE offender) you're introducing barriers to traffic.
It may not matter if you're not at a huge station and you have tons of time, but imagine people constantly filing out of Shinjuku station during rush hour and having to queue up on the stairs outside of the gates just to get in - the delay is unacceptable and a human health hazard. When rush hour happens and someone's card is declined, the second or so it takes for them to back out creates a huge jam and crowding. During large events (for instance, people trying to file in/out of stations for performances), this is especially a problem when people don't have enough money on their cards.
In addition to the latency, Suica & these other IC cards also start the process at a further distance, and also work better through wallets/card holders. EZCards are especially bad at that (and won't work through pretty much anything). This reduces the friction required to take the card out, as people can just tap their whole wallet and it'll go through multiple credit cards as well.
The whole goal is to create a smooth process where you can walk through transit gates without stopping or slowing down, and Oyster and EZCards fail at doing that.
Oyster cards and EZCards are fine low traffic transit solutions but the requirement for walking speed not to be interrupted is why they aren't feasible in Japan. EZCards are especially terrible, as they pretty much need to contact the reader to scan. It's painful to see people coming out of the trains in Taiwan and having to line up to leave the station.
I think you are conflating many different things here.
NFC-F is widespread. It's not a Japanese thing anymore. Also, the difference in latency between NFC-F based IC cards, and lower end NFC cards, is perhaps 100ms to 200ms, tops.
You seem to think that Suica cards make a huge difference by comparing London and Tokyo flows of traffic, but London underground stations are older, narrower, and less modernized than those in Tokyo. Most stations in London are several decades older than those in Tokyo, poorly maintained, with a handful of gates for hundreds of people coming out at once. It's worth noting that latest Oyster cards are actually based on Mifare Desfire, meaning that they should be twice as fast as Felica cards on paper.
On the other hand, why not compare other systems based on NFC-F, like those in Bangalore or Jakarta?
Ignoring factors such as infrastructure, culture, prevalence of means of transportation, etc., and focus on one hundred milliseconds, is a bit myopic.
In Jakarta, the MRT and KRL systems use FeliCa technology but also accept Mifare-based cards. The speed difference is significant; FeliCa offers a smoother flow, while with Mifare-based systems, there is a noticeable wait time.
