962 karma · joined September 28, 2016
* https://ianhowson.com -- my blog
* https://rdrr.io -- the world's most comprehensive index of R package documentation
Feel free to email me anytime -- ian@mutexlabs.com
I'm not claiming anything of the sort.
My point is that memory consumption seems to be greatly reduced in Big Sur, and that might make 8GB machines much better to use than before. All of my testing is on Intel machines. It's not exclusively an M1 phenomenon.
I would still recommend 16GB to anyone, and if the extra $200 was a factor, I would recommend that they buy last year's Intel with 16GB of RAM.
This is fascinating to me, because:
(a) every 8GB Mac I've used in the past has been unusably slow
(b) since upgrading my 32GB Hackintosh to Big Sur, my usual 40GB working set is only about 20GB.
(c) My 2015 16GB MBPr with Big Sur is also using about half as much physical memory on the same workload. Swappiness is up a little, but I haven't noticed.
So my guess is that something in Big Sur has dramatically reduced memory consumption and that fix is being commingled with the M1 announce.
Filesystems don't read SMART data. You might have a separate daemon which monitors SMART.
ZFS checksumming is amazing for this. You know, without doubt, which file(s) are bad. You can still use failing or unknown quality drives because the checksumming will protect you from silent data corruption.
If you're still interested in hardware, there's the NVIDIA BlueField 2 and its regex accelerator: https://www.nvidia.com/en-us/networking/products/data-proces...
PhotoSync (https://www.photosync-app.com/home.html) lets you do a good-old-fashioned dump to a NAS.
Yes, Block Storage: https://us.ovhcloud.com/public-cloud/block-storage/
> Do they at least support the same API?
Yes
> Can OVH actually scale on demand?
Not as big as AWS, but yes.
Remember that you're getting 5x the compute resources for the same money. You don't need to autoscale as much. You're not fighting crappy EBS performance. You're not architecting around remote-network RDS databases with milliseconds of RTT. I firmly believe that for most applications you're going to be better off just massively overprovisioning your hardware and keeping the software stack simple.
> I don't know how good OVH is with outage and availability.
I've personally observed failure rates similar to AWS EC2 and EBS. You need to plan for failure, like any cloud provider.
> the raw compute is cheaper
Dramatically so. 20% of the price.
> There's also storage
You can get local NVMe, cheaply, with literally 100x the perf you can get with the most expensive EBS volumes. AWS does not have a storage offering that comes close, not even their instance store NVMe.
> what happens to his disks
VM images can be backed up automatically without downtime (on a schedule, not live.) They offer an EBS equivalent.
> OVH doesn't have regions everywhere
They have enough. us-west, us-east, eu-west, APAC, others. I'll grant that the US regions are operated by a different corporate entity and a different web interface, and that is annoying.
This is true, but keep in mind that that sort of algorithm runs insanely well on any CPU or GPU because they, too, do not want to touch main memory. You would be blown away by how much work a CPU can do if you can keep the working set within L1 cache.
Re. ASICs, it's a continuum:
- "flexible, low performance, cheap in small quantities" (CPUs)
- "reasonably flexible, better performance, cheap-ish in small quantities" (GPUs)
- "inflexible, best performance, expensive in small quantities" (ASICs)
FPGAs fit somewhere between GPUs and ASICs -- poor flexibility, maybe great performance, moderate small-quantity price.
If your problem is too big for GPUs, as you say, sometimes it's easiest to jump straight to an ASIC. But it's such a narrow window in the HPC landscape. The vast majority of customers, even with large problems, are just buying a lot of GPUs. They're using off-the-shelf frameworks even though a custom CUDA kernel would give them 10x performance and 10% cost. The cost to go to an FPGA is too great and the performance gain simply isn't there.
The big benefit of having FPGA closely attached to CPU is that you can access the memory and internal buses quickly. Transferring stuff over PCIe hurts a lot. So you could make an argument for jobs using small work units requiring fast turnaround; CUDA kernels take milliseconds to launch.
I worked with some of the early Xeon+FPGA parts and there just wasn't that much we could do with them. There wasn't enough fabric to build anything meaningful and we had an abundance of CPU cores, so the best we could do was specialized I/O accelerators.
Maybe you could argue that four RPis on a network are more reliable than a single x86 with VMs, but that doesn't seem to be the point of this machine.
On a past project we had two DDR RAMs and a NOR Flash on the same bus. There was one hardware engineer, and he laid out the memory subsystem in about a day. (The power supplies were dramatically more complicated.)
It almost worked first time. I noticed about one memory error per day per device, which I repro'd with repeated `md5sum /tmp/largefile`.
We just dropped the clock rate in U-Boot.
Failed devices? Heat it up with a hot air gun for a while. Fixed 90% of them. Still doesn't work? Throw it away.
There are no mysteries, just stuff you don't know yet.
- power supply
- quality SD card
- heatsinks
- a case
and then deal with
- non-x86
- thermal issues
- SD cards
- the CPU is too tiny to do anything useful anyway
Sorry to hear that X2x0 is expensive where you live. I find that the small additional investment over the RPi is worthwhile.
Much less hassle and similar price to an RPi.
I use Zilents on my daily driver. They're pretty quiet as far as mech switches go, but still a lot noisier than a standard laptop keyboard. No complaints so far.
- Small children don't really understand "mummy's working, talk to me instead." Interruptions are death to productivity. Children can't interrupt you if you're not present.
- Most daycares are closed or at reduced capacity.
- Nanny services are harder to find and come with risks.
- Time at the office is time resting from the kids, and time at home is resting from the office. If it's all one place, there is no rest.
My wife and I are finding it easier to alternate childcare instead of try to do everything at once, and being out of the home during the work time gives rest and focus.
Pretty much every bigcorp I've ever worked for has some crucial service on a box under someone's desk...
They tend to warp the structure of your software and prevent usage of many useful language features.
If you're not doing safety work, the Linux kernel is a great example of 'nice' modern C.
For me, at least, it's not a big win. I'm mostly touching the inner edge of the key because my pinkies aren't that laterally flexible.
I like a lot of tilt and low to the desk, and that extra 0.5u of width ends up raising the whole thing more than it needs to.
I have large hands and the ErgoDox thumb cluster is just too damn far away. Bringing it within reach is a meaningful improvement.
No. Bitstream formats are not in any way compatible across devices. Because timing is a factor, even if you had the same physical layout of LUTs and routing, it's unlikely that your design would work.
(From parent)
> use that bitstream for any other device in the same device family
Not at the bitstream level. However, you can take a place&routed chunk of logic and treat it as a unit. You can replicate it (without repeating P&R), move it around, copy it onto other devices in the same family. This is super useful as most FPGA applications have large repeating structures, but P&R doesn't know that it's a factorable unit. It'll repeat P&R for each instance and you'll get unpredictable timing characteristics.
> Should manufacturers provide new formats closer to final form yet would allow binaries that can be adjusted, kind of like .a .so or even llvm?
> would building whole images for many families of FPGA make sense
You can license libraries that are a P&R'd blob and drop them into your design. There's no easy way to make this generalizable across devices without shipping the original RTL, and conversion from RTL->bitstream is where most of the pain lies.
Database CPU usage is negligible.
It was easier to put a replica on every host than try to rearchitect things to tolerate single-digit millisecond RTT to a cloud database.
This is sort-of-OK for consumers but amazing for Apple and its shareholers.
I'm predicting the opposite: you won't actually see any difference.
Once you look closely at power profiles on modern machines you'll see that most energy is going into display and GPU. CPUs mostly run idle. Even if you had a theoretical CPU using zero energy, most people are not going to get 30% battery life gains [1]. Not one thing that they demoed requires any meaningful CPU power.
Similarly, while ARM parts are more efficient than x86 per compute cycle, it's not a dramatic change.
The big changes, I think, are more mundane:
- Apple is going to save $200-$800 cost per Mac shipped
- Apple can start leaning on their specialized ML cores and accelerators. They will probably put that stuff in T2 for Intel Macs. If they're already shipping T2 on every machine, with a bunch of CPU cores, why not just make those CPU cores big enough for the main workload?
Doubling CPU perf is meaningless if you can ship the right accelerators that'll do 100x energy/perf for video compression, crypto and graphics.
[1] for a regular web browsing type user; obviously if you're compiling stuff this may not apply; if that is true you're almost certainly better off just getting a Linux desktop for the heavy lifting
Keep in mind that this doesn't imply a different chip design. TDP is primarily a function of intended application and cooling capacity, not chip tech.
That said, they've already demonstrated ability to do this with A12/A12X/A12Z, which are the same chip at different CPU/GPU core counts. Clock rates are not impacted except where thermal limitations (TDP) impose a limit.
I haven't bothered calibrating it.