194 karma · joined July 2, 2010
the bottleneck in lots of database workloads is memory bandwidth. for example, hash join performance with a build side table that doesn't fit in L2 cache. if you analyze this workload with perf, assuming you have a well written hash join implementation, you will see something like 0.1 instructions per cycle, and the memory bandwidth will be completely maxed out.
similarly, while there have been some attempts at GPU accelerated databases, they have mostly failed exactly because the cost of moving data from the CPU to the GPU is too high to be worth it.
i wish aws and the other cloud providers would offer arm servers with apple m-series levels of memory bandwidth per core, it would be a game changer for analytical databases. i also wish they would offer local NVMe drives with reasonable bandwidth - the current offerings are terrible (https://databasearchitects.blogspot.com/2024/02/ssds-have-be...)
1) programming takes a long time, and it only makes sense to take the time to do it if you're making a bunch of copies of something. this is something that could be improved with better software and ux - if cad programs made it easy to just drag and drop joints from a joint library into your model then this would be a different story. a hardware+software solution could also work here, something like a cnc version of https://www.woodpeck.com/multi-router-group.html where the software makes it easy to scale the templates to your work piece.
2) setup takes a long time on the affordable machines. every time you change bits you have to recalibrate. positioning the work piece on the table and clamping/taping it down takes a lot of time. if you have to flip the work piece over then that takes even longer and positioning is even more critical, and programming is more complicated as well. regardless of whether your designs require cutting on one or both sides, you have to program tabs into your design so the router doesn't cut all the way through (or else the piece will move and the router will screw it up), and then you have to go back and cut the pieces out the rest of the way manually and trim off the tabs with a flush trim router bit. the high end production quality machines mitigate a lot of these issues, but now you are talking about a machine that costs at least $100,000 and takes up a whole room.
i could see how a machine big enough for 4x8 sheets with an automatic tool changer, a vacuum table, and all the automatic calibration gizmos might be a time saver for a production shop, but if you're building something that's a one-off or you don't have all the setup automation goodies (which are $$$$$) then setup and programming usually end up taking longer than doing the work the old fashioned way.
for tenon cutting like in the bed rail example you gave, i have a hard time imagining any situation where cnc is going to be more efficient than a domino xl.
this tweet is not talking about compressing customer data in s3, i seriously doubt that aws compresses customer data in s3 for all the reasons i've already listed. i am right and amazon does know what they're doing, which is why they don't compress customer data in s3.
4 bytes per megabyte becomes significant at scale when you have to keep it in ram, which you have to do if you want to avoid the extra IO.