There are EV's which have drum-brakes. That's only possible because the regenerative braking takes most of the load. Also, there are stories of brake-discs rusting out on EV's. Both point to less (friction)-brake use on an EV compared to an ICE.
I suspect drum brakes were chosen by the electron pinching EV engineers. They're the only brakes that are friction-free when not applied. Disc brakes rub (and slow the car) even when not applied.
They use drum brakes because drum brakes are protected better from the environment while brake discs are not and will quickly get covered in rust and dirt when not used for awhile and then be less effective when they are actually needed for an emergency braking situation.
We only ever really went to disc brakes because they were slightly cheaper and easier to manufacture and since racing vehicles used disc brakes (because they benefit from the extra cooling capacity that commuters don't need) it was easy to convince customers that they were "better" and they became standard.
There was also a time when they didn't figure out traction control very well using brake drums while they did manage it with brake discs, but part of that could be just because brake drums were out of fashion in racing where traction and stability control were invented and implemented first and nobody bothered improving drum brakes to take advantage of that tech until decades later.
Now that EV drivers can go weeks without touching their actual brakes and just rely on regen braking, disc brakes have become a liability since they aren't worn down smooth and cleaned whenever someone stops at the end of their driveway.
I've used drum brakes in older cars and motorcycles, and their stopping power is terrible, fade is terrible, and they are horrible in the rain.
The only recent cars I've had with drum brakes used them for the parking brake. They tended to corrode and not work well. Also, as an emergency brake even with a pedal you could push hard on, they were beyond terrible, even dangerously ineffective.
Seems like EV manufacturers should set their cars to use the friction brakes for the first few stops of each trip, both to clean off the rust & dirt, and also to test whether they still work.
An electric motor is really good at arresting high rpm movement while charging, not so great at bringing low rpm movement to a stop. EVs blend together Regen and friction at slow speeds.
> An electric motor is really good at arresting high rpm movement
I don't think any EV that I've heard of has full-range electric brakes.
There are two interesting kinds of things that I think EVs could use...
brake resistors - if the battery can't absorb the full power of regenerative braking, maybe giant resistors can take the dissipate the rest of the energy.
eddy currents - it might be cool to use eddy currents to brake.
Not significantly. Otherwise they’d get hot and work less well. Pads ride very closely to the disc so that road stuff can’t get wedged between the surfaces, and so that you don’t waste break pedal travel just getting the pads close to the surface. Well adjusted drum brakes should be arranged almost exactly the same way.
Are you familiar with how disk brakes on a car operate? They’re essentially a hydraulic piston clamping the brake pads against the rotor. When you let off the brake pedal, the pressure is removed, but there’s not a “retraction” of any kind. So there’s no pressure but nothing is actually making that gap. That article was articulating basically that the piston, when not compressing the brake pads, should not be too far out, because that’s just unnecessary travel of the pedal, but it does not mean that the brake pads are somehow gapped away from the rotors.
Drum brakes by contrast have springs that retract the pads from the braking surface, so the OP has a very valid point.
I'm very familiar, having changed many sets over the years. If there's no air in the system, pulling fluid away from a hydraulic piston must retract it. It can't just sit there unless there's an air bubble to expand or so much negative pressure that it forms a vacuum somewhere. Even then, pressure on the atmosphere-facing side would push the piston back toward wherever the vacuum or air bubble is.
The rotors push the pads away from the surface if the slides and spring clip seats are maintained. I have seen many unbalanced brake systems with uneven pad wear of all kinds due to rust/dust/heat impacting the system.
Something makes them retract slightly - how they’re seated in the caliper retaining clip maybe I’m not sure because trivially you can take the wheel off and press the brake and see it.
It’s even easier to see on a bicycle with hydraulic discs.
> When you let off the brake pedal, the pressure is removed, but there’s not a “retraction” of any kind. So there’s no pressure but nothing is actually making that gap.
Technically there is a slight amount of rubber spring back for a fraction of a millimeter and the air traveling with the rotor surface puts a small amount of pressure back on the pad and pushes it imperceptibly backwards. Of course that is only really effective if your rotors are perfectly flat and warp free, which most peoples are not because rotors never get resurfaced any more and 95% of them are super cheaply casted and turned which leads to warpage extremely quickly.
The default for drum is less friction (gap increases, takes more pedal) over service life whereas pads default to more friction (slides gunk up and spring clip faces rust and swell) from failing to retract as well.
Yeah, my VE id.3 has drums on the back and disks on the front. Apparently the brake pads are effectively life-of-the-vehicle items under normal driving conditions.
I’ve only had to change them one time on any car newer than 1990, after ~200k miles/10 years of use. For most people that qualifies as life of the vehicle, but there was plenty of life left.
There has been some testing within llama.cpp, which supports both Vulkan and ROCM-Blas. When it works, the latter is about 2x faster than the Vulkan version.
There are likely plenty of unrealized opportunities to improve mature BLAS libraries. For example, this guy who was able to outperform OpenBLAS' GEMM on Zen 4:
Concidentally, the Intel MKL also outperforms OpenBLAS, so there being room for improvement is well known. That said, I have a GEMV implementation that outperforms both the Intel MKL and OpenBLAS in my tests on Zen 3:
That is unless you shoehorn GEMV into the Intel MKL's batched GEMM function, which then outperforms it when there is locality. Of course, when there is no locality, my code runs faster.
I suspect if/when this reaches the established amd64 BLAS implementations' authors, they will adopt my trick to get their non-batched GEMV implementations to run fast too. In particular, I am calculating the dot products for 8 rows in parallel followed by 8 parallel horizontal additions. I have not seen the 8 parallel horizontal addition technique mentioned anywhere, so I might be the first to have done it.
ISA cards, like the soundblaster had the MIDI and joystick on the same connector. The joystick had up to 4 analog inputs, maybe that's what's meant here.
The PC game port is a nearest thing to intentional GPIO that PC has. Parallel port is almost always better for digital GPIOs, but it was not designed that way and the fact that it can be used like that (and extended several times into what in the end was SCSI-like protocol) is kind of an coincidence.
> The PC game port is a nearest thing to intentional GPIO that PC has.
Er, what? Not every IBM PC (clone) had a (sound) card with joystick ports, but almost every PC clone had (ISA, later PCI) extension slots. There were/are plenty of digital i/o adapter cards for those available, from plain, cheap 8255 based ones to those with slave CPUs (potentially more powerful than the host's CPU).
But then, perhaps I don't understand what you mean by 'intentional' GPIO.
If there's a chain of dependencies (libraries depending on other libraries), a single process might end up with different versions of the same library in it's memory.
That's not going to work, since the interface/API of the library is typically not versioned.
