spacenick88 (u/spacenick88)

spacenick88 commented on Windows Subsystem for Linux: The lost potential jmmv.dev/2020/11/wsl-lost... · Posted by u/r0sk

userbinator · 5 years ago

Linux and Unix in general seems to love huge writeback caching, which is great for speed but horrible for consistency and reliability to power failure and such; on the other hand, Windows flushes the caches more often, providing greater reliability but without as much speed.

That's been my experience, in any case; doing lots of small file operations barely causes any disk activity in Linux, but far more in Windows. Moreover, abruptly cutting power in the middle of that would likely result in far more writes lost on Linux than on Windows.

spacenick88 · 5 years ago

Linux/Unix just trust that if you want something persisted with certainty you'll do an fsync, if you do it will absolutely guarantee you're not losing that. It will absolutely make sure that your filesystem doesn't get corrupted by a power loss but if you didn't fsync your write you had no place believing it was persisted.

Doing that IMHO matches real world use much better. If I do a compile and get a power outage I don't care if some object files get lost. If I do an INSERT in a DB I do care a lot but the DB knows that and will fsync before telling me it succeeded. So making sync explicit gives you both great performance and flexibility.

spacenick88 commented on 2020 Mac Mini – Putting Apple Silicon M1 To The Test anandtech.com/show/16252/... · Posted by u/kissiel

CapriciousCptl · 5 years ago

From the article's conclusion... "The M1 undisputedly outperforms the core performance of everything Intel has to offer, and battles it with AMD’s new Zen3, winning some, losing some. And in the mobile space in particular, there doesn’t seem to be an equivalent in either ST or MT performance – at least within the same power budgets."

This is the first in-depth review validating all the hype. Assuming the user experience, Rosetta2 things, first generation pains, kernel panics, are all in-check, it's amazing. At this point I'm mostly interested in the Air's performance with its missing fan.

spacenick88 · 5 years ago

As for kernel panics, with iOS likely sharing most if not all of it's kernel code with macOS I'd be surprised if Apple hasn't had an iPhone macOS build since before they released the first iPhone.

spacenick88 commented on An ex-ARM engineer critiques RISC-V gist.github.com/erincande... · Posted by u/ducktective

pizlonator · 5 years ago

I don’t think that beefier cpu and overflow checks are that related. I mean, you’re right, I just want to place some limits on how right you are.

1. Folks totally run JS and other crazy on small CPUs.

2. Other safe languages (rust and swift I think?) also use overflow checks. It’s probably a good thing if those languages get used more on small cpus.

3. The C code that normally runs on small cpus is hella vulnerable today and probably for a long time to come. Compiling with sanitizer flags that turn on overflow checks is a valuable (and oft requested) mitigation. So theres a future where most arithmetic is checked on all cpus and with all languages.

And yeah, it’s true that the overflow check is well predicted. And yeah, it’s true that what arm and x86 do here isn’t the best thing ever, just better than risc-v.

spacenick88 · 5 years ago

Interestingly it seems rust only does full overflow checking in debug builds: https://huonw.github.io/blog/2016/04/myths-and-legends-about...

spacenick88 commented on An ex-ARM engineer critiques RISC-V gist.github.com/erincande... · Posted by u/ducktective

pizlonator · 5 years ago

I don’t think that beefier cpu and overflow checks are that related. I mean, you’re right, I just want to place some limits on how right you are.

1. Folks totally run JS and other crazy on small CPUs.

2. Other safe languages (rust and swift I think?) also use overflow checks. It’s probably a good thing if those languages get used more on small cpus.

3. The C code that normally runs on small cpus is hella vulnerable today and probably for a long time to come. Compiling with sanitizer flags that turn on overflow checks is a valuable (and oft requested) mitigation. So theres a future where most arithmetic is checked on all cpus and with all languages.

And yeah, it’s true that the overflow check is well predicted. And yeah, it’s true that what arm and x86 do here isn’t the best thing ever, just better than risc-v.

spacenick88 · 5 years ago

Yeah I know about 1 e.g. also MicroPython, no idea if that's used outside DIY though. I agree about rust but I would think that with much stronger type safety and static compilation it should be able to remove a lot more of the overflow checks and most that remain would be needed in correct C too. At least that's what I learned from my compilers prof who worked on Ada compilers for many years and that should be quite similar. But maybe that's my biased hope as I really really hate working with dynamic languages.

spacenick88 commented on An ex-ARM engineer critiques RISC-V gist.github.com/erincande... · Posted by u/ducktective

rwmj · 5 years ago

The idea is that high end processors will recognise these sequences of instructions and optimize them (something called macro-op fusion). Whether this is a good idea is an open question because we don't yet have such high performance RISC-V chips, but that's what the RISC-V designers are thinking. At the same time it permits very simple implementations which wouldn't be possible if the base instruction set contained every pet instruction that someone thought was a good idea.

Note macro op fusion is widely used for other architectures already, particularly ones like x86 where what the processor actually runs looks nothing like the machine code.

spacenick88 · 5 years ago

Instead of fusing them, shouldn't it be possible to speculate that it will not overflow, process the check on a separate slow path and do a roll back in case it did overflow?

spacenick88 commented on An ex-ARM engineer critiques RISC-V gist.github.com/erincande... · Posted by u/ducktective

pizlonator · 5 years ago

The lack of condition codes is a big deal for anyone relying on overflow checked arithmetic, like modern safe languages that do this for all integer math by default, or dynamic languages where it’s necessary for the JIT to speculate that the dynamic “number” type (which in those languages is either like a double or like a bigint semantically) is being used as an integer.

RISC-V means three instructions instead of two in the best case. It requires five or more instead of two in bad cases. That’s extremely annoying since these code sequences will be emitted frequently if that’s how all math in the language works.

Also worth noting, since this always comes up, that these things are super hard for a compiler to optimize away. JSC tries very aggressively but only succeeds a minority of the time (we have a backwards abstract interpreter based on how values are used, a forward interpreter that uses a simplified octagon domain to prove integer ranges, and a bunch of other things - and it’s not enough). So, even with very aggressive compilers you will often emit sequences to check overflow. It’s ideal if this is just a branch on a flag because this maximizes density. Density is especially important in JITs; more density means not just better perf but better memory usage since JITed instructions use dirty memory.

spacenick88 · 5 years ago

I wonder how this interacts with branch prediction. Since overflows should happen very rarely I guess the branch on overflow should almost always predict as non taken. So wouldn't it be possible to have a "branch if add would overflow" instruction or even canonical sequence that a higher end CPU can completely speculate around and just use speculation rollback if it overflows?

I think an important design point here is that the languages that need a lot of dynamic overflow checks are primarily used on beefier CPUs so if you can get around the code size issue, making it performant only on more capable designs is fine since the overflow check will be rare on simpler CPUs.

spacenick88 commented on Linux maintains bugs: The real reason ifconfig on Linux is deprecated (2018) blog.farhan.codes/2018/06... · Posted by u/pjmlp

loeg · 6 years ago

It seems like for many userspace applications, the appropriate backwards compatibility ABI would have been at the SO level. ELF shlibs make it easy to version interfaces without breaking old dynamically linked programs. Linux is sort of the odd duck in that it considers the entire syscall surface a stable ABI. It leads to a lot of neat results, but can obviously also cause pain when some older interfaces are not sufficient.

That said — new ioctls could be added and new ifconfig could use those? Old ifconfig and user programs could continue using the old ABIs.

spacenick88 · 6 years ago

I would argue that the stable syscall interfaces is one of the main drivers behind Linux success. Containers as we know them would be quite different if they needed to somehow merge the kernel version appropriate .so files into the fs. They would forever remain just sandboxes of the essentially the same distro as the host just like they are on Solaris/FreeBSD.

Also something like WSL would be impossible

spacenick88 commented on Why did I wake up before my alarm clock went off? (2015) joearms.github.io/publish... · Posted by u/gloftus

spacenick88 · 6 years ago

Maybe I'm missing something but e.g. on the Android clock you can dismiss an upcoming alarm. So now if you wake up, dismiss it and it never rings that kind of proofs you really woke up before, right?

spacenick88 commented on PCILeech github.com/ufrisk/pcileec... · Posted by u/peter_d_sherman

drewg123 · 6 years ago

The problem is that, used properly, IOMMUs are horribly expensive.

Consider a NIC driver where you're mapping an outgoing packet for DMA. What used to essentially be a virtual to physical translation becomes a virt to phys + entering the phys in the iommu + removing the mapping when the transmit is complete. This is expensive for hardware and software reasons. At one point I benchmarked a 100g setup on linux, and with the IOMMU enabled, we lost about 90% of the bandwidth and most of the CPU time was spent in lock contention over the red-black tree that managed the IOMMU tables. This was 5-ish years ago, so perhaps things have gotten better.

So that makes people want to just enable the IOMMU for SR-IOV (and full device) pass-thru to VMs. This is cheaper, since you just set the mapping up when you allocate phys mem for the guest, and tear them down when freeing phys mem.

MacOS used to use a really cool trick where they pre-mapped all mbufs into the IOMMU. That made network traffic transmit and receive comparatively fast. However,it also prevented lots of optimizations that modern operating systems use for zero-copy IO (like attaching pages from sendfile directly to mbufs, similer to skb_frags).

spacenick88 · 6 years ago

I think the most expensive isn't the address translation itself but TLB housekeeping when mappings get remapped or invalidated. This is especially true with virtualization where the hypervisor often needs to do extra work like (un)pinning guest pages, translating guest real addresses to host real and reissuing TLB flushes.

spacenick88 commented on Electric motor design claims remarkable improvements newatlas.com/linear-labs-... · Posted by u/bmh

Svip · 7 years ago

I am genuinely curious, why aren't there transmissions for electric engines? Surely the advantage would be the same as for an IC engine. I remember hearing that Tesla tried to build a 2 speed transmission for their Roadster back in the day, but apparently it kept breaking, so they stuck with no transmission.

Are there transmissions out there for EVs, and I just haven't been paying attention? And if no, why is it so hard? Is it because of the torque?

spacenick88 · 7 years ago

Afaic the upcoming Porsche Taycan has a two speed transmission. In the Taycan it's used for more efficiency at >160 kph or so something an American car really doesn't need and it costs them a slower 0-100 kph. Tesla uses another trick to get better acceleration to 100 kph. They have two motors and one is geared for high efficiency at US highway cruising speeds (so ca 120 kph).

In general electric motors have a very wide band of excellent efficiency and an even wider band of great efficiency and they are orders of magnitude more efficient than ICE in any part of their operational torgue/speed range.