jeffffff (u/jeffffff)

jeffffff commented on Mongo but on Postgres and with strong consistency benefits github.com/event-driven-i... · Posted by u/oskar_dudycz

aden1ne · 2 years ago

Had a similar experience. What killed it for me, is that no statistics can be gathered for JSONB columns. This in turn really messes with the query planner once you do something like `select a.* from a join b on a.id = b.a_id where b.my_jsonb_column ->> 'foo' = 'bar';`.

Given the lack of statistics, the query planner loves going for a nested loop rather than hash or merge join where those would appropriate, leading to abysmal performance.

There is an thread[0] on the PostgreSQL mailing list to add at least some statistics on JSONB column, but this has gone nowhere since 2022.

[0]: https://www.postgresql.org/message-id/flat/c9c4bd20-996c-100...

jeffffff · 2 years ago

it's kind of dumb that postgres uses a nested loop join instead of a hash join there. hash join almost always has the best worst-case behavior, and without stats it should be the default choice.

jeffffff commented on Digital Wood Joints openup.design/we-learn/50... · Posted by u/montgomery_r

chiffre01 · 2 years ago

I'd like to think we're at a place where CNC machines are cheap and accessible enough that clever tricks or new tools are just around the corner to overcome some of the inherent issues of making basic wood joints on a CNC router.

To me, these look like a stepping stone to something better. They're all intended to be used with a flat-shaped endmill, and all probably have strength and aesthetic issues. One solution is using different router bit shapes in combination with traditional techniques, but this is more labor-intensive.

jeffffff · 2 years ago

we're not really close, for two reasons:

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.

jeffffff commented on Digital Wood Joints openup.design/we-learn/50... · Posted by u/montgomery_r

mauvehaus · 2 years ago

I wasn't in the trade in 2004, so some of this is a bit speculative:

It looks like everything on the poster is made to be cut on a 3-axis machine. Stepping up to five-axis is a huge leap in cost at present, and surely was then as well.

Tooling has likely improved in availability and cost since 2004 as well. Automatic tool changers have probably also become more affordable, but just like going to five-axis, you're getting into a whole different class of machine once you start talking about adding that.

Some of the reasons to cut stuff single-sided on the flat are unchanged by any of that though. It still costs you precision (and time) to flip a workpiece over, and you're going to have issues if you don't have good consistency with your material thickness if you need to reference your Z axis to the material surface rather than the bed surface.

Working an end of a long piece remains a pain in the ass for fixturing that involves a hole in your machine bed, and possibly the floor as well. Tenoning a bed rail, for instance, is inconvenient however you do it.

All of my CNC experience is on a three-axis machine, five-axis gets you a lot of flexibility that most places won't have unless CNC work is their primary focus, or at least core to their workflow. I've seen a shop that builds high-end windows with a large five axis machine. I have no concerns about the durability of their products, it's just that most people don't have access to that kind of capability.

jeffffff · 2 years ago

i'm a hobbyist woodworker with more money than time. i have a pretty basic 3-axis cnc and i thought it would save me time, but it really doesn't. the only thing i actually use it for is cutting out router templates, and even that would be done better with a laser cutter (although a good laser cutter costs a lot more than my cnc).

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.

jeffffff commented on Ask HN: Any felons successfully found IT work post-release? · Posted by u/publicprivacy

droptablemain · 2 years ago

When you are searching Indeed, you can check the "Fair Chance" option where the employer has indicated a willingness to work with this kind of stuff.

This is not something I'm experienced in though. Best of luck.

jeffffff · 2 years ago

Speaking of Indeed, the first employee (https://en.wikipedia.org/wiki/Chris_Lamprecht) was a felon and a great engineer

jeffffff commented on Zenbleed lock.cmpxchg8b.com/zenble... · Posted by u/loeg

hinkley · 3 years ago

Or adds a guard.

They mention perf issues for the workaround but they're notably absent from the microcode commentary.

I wonder what this is going to do to the new AMD hardware AWS is trying to roll out, which is supposed to be a substantial performance bump over the previous generation.

jeffffff · 3 years ago

shouldn't have any effect, the new amd hardware is zen 4 and this only affects zen 2

jeffffff commented on Backend of Meta Threads is built with Python 3.10 twitter.com/llanga/status... · Posted by u/BerislavLopac

jonhohle · 3 years ago

I’m not sure why someone of facebook’s scale would want JIT instead of AOT. That’s a lot of servers all JITing the same thing that could be done once at build time.

jeffffff · 3 years ago

JIT compilation has the opportunity to do profile-guided optimization at runtime. JIT compilation is also simpler when distributing an application to non-identical servers, as it can optimize for the exact hardware it is running on.

jeffffff commented on Are You Sure You Want to Use MMAP in Your Database Management System? (2022) db.cs.cmu.edu/mmap-cidr20... · Posted by u/nethunters

pclmulqdq · 3 years ago

It's kind of disingenuous to talk about how great your concurrency system is when you only allow a single writer. RCU (which I imagine your system is isomorphic to) is pretty simple compared to what many DB engines use to do ACID transactions that involve both reads and writes.

jeffffff · 3 years ago

take a look at http://nms.csail.mit.edu/~stavros/pubs/OLTP_sigmod08.pdf - the overhead of coordinating multiple writers often makes multi-writer databases slower than single-writer databases. remember, everything has to be serialized when it goes to the write ahead log, so as long as you can do the database updates as fast as you can write to the log then concurrent writers are of no benefit.

jeffffff commented on Dynamic bit shuffle using AVX-512 lemire.me/blog/2023/06/29... · Posted by u/ibobev

anonymousDan · 3 years ago

By coincidence I just started playing with AVX-512 this week. It's a lot of fun, but I have to say there is a dearth of resources on how to use it. For example I would love a simple visualisation for each operation as to how the various vectors and/or memory are transformed. Can anyone recommend some good books/learning resources?

jeffffff · 3 years ago

there are only a handful of instructions that do interesting things beyond parallel versions of basic arithmetic and bitwise operations. https://branchfree.org/2019/05/29/why-ice-lake-is-important-... provides a good overview of them.

jeffffff commented on Dynamic bit shuffle using AVX-512 lemire.me/blog/2023/06/29... · Posted by u/ibobev

pjmlp · 3 years ago

In Intel's case they were thinking about turning the CPU into a GPU, but failed at that several times, AVX is what is left from Larrabee.

jeffffff · 3 years ago

AVX and AVX2 are pretty awful because of lane-crossing limitations, but AVX512 is actually really nice and feels like a real programmer designed it rather than an electrical engineer.

jeffffff commented on What every programmer should know about memory (2007) [pdf] people.freebsd.org/~lstew... · Posted by u/quackulus

dragontamer · 3 years ago

1. RAM is a parallel machine of its own. This document describes DDR3 (which is 2 versions out from modern DDR5), but that doesn't really matter. Today's DDR5 is just more parallel.

2. This document very precisely describes the parallelization mechanism of DDR3. Read/writes to DDR3 are parallelized by channel, rank, and bank. DDR4 added bank-group as an additional layer of parallelism (above bank below rank).

3. An individual bank has performance characteristics: an individual bank is much faster when it can stay "open", thus only getting a CAS-latency, rather than a close+precharge+RAS+CAS latency cycle.

4. CPUs try to exploit this parallelism with various mechanisms. Software prefetching, hardware prefetchers, levels of cache, and so forth.

5. NUMA is more relevant today as EPYC systems are innately quad-NUMA. HugePages is also more relevant today as 96MB+ L3 per CCX have appeared on Ryzen/EPYC machines, meaning you need HugePages to access L3 without a TLB hit. TLB isn't really RAM, but its closely related to RAM and could be a bottleneck before you hit a RAM bottleneck, so its still important to learn if you're optimizing against RAM-bottlenecks.

jeffffff · 3 years ago

one thing that is missing from this document is that there are a limited number of line fill buffers in the L1 cache of each core, which limits the number of concurrent memory accesses that can be in flight well before anything related to channels/ranks/banks begins to matter. https://lemire.me/blog/2018/11/05/measuring-the-memory-level...