tanelpoder

Another way to look at is that the ratio between capacity and physical IOPS constraints have gotten exponentially better over time. It's just that you can't treat all that capacity as hot capacity anymore.

I recall a whitepaper on HP high-end storage arrays from over 10 years ago, their arrays already read and cached at least 256kB of data, even if you wanted only a 4kB block.

I was thinking that the controller probably takes care of interleaving data across platters, so at least small enough random I/Os would be able to use only one actuator.

I did some more reading and the PDF [1] says it shows up as two separate LUNs behind a single SAS port, but sharing the drive cache.

But what I initially didn't catch (and another comment here pointed out), is how come they claim to do over 500 MB/s of sequential scanning I/O. Small random IOPS I get, but for large sequential I/Os you still have the same amount of platters, with the same bit-density, rotating at the same speed... Or is even the sequential I/O throughput "bottleneck" mostly dominated by the tiny seeks + calibration to the next adjacent track and not the actual magnetic reading part?

I now really want to buy one for (some?) reason. Could get an used version from amazon for $150 but I'll try to hold back. It's also interesting that there are no new, unused versions available there (discontinued?)

[1] https://www.seagate.com/files/www-content/solutions/mach-2-m...

That's a good point, as if you don't seek, the total number of disk platters, rotation speed and bit-density is still the same regardless of two actuators. (Or do they have more platters?) Makes me wonder how come they advertise 500+ MB/s sequential IO rate then.

I assumed that too. Probably cheaper and more space efficient to have just one actuator position in the HDD enclosure though and they split it vertically.

Apparently both Seagate and Western Digital sell dual-actuator disks (double the IOPS and throughput up to 448 IOPS and 524 MB/s per drive)

Reminds me of the IBM Cloud slogan: "We have a cloud?!"

I think it was @quinnypig who coined it...

Also, for multiprocess database engines like Postgres (and Oracle), starting up and tearing down connections will be much faster with hugepages too, as the shared memory attach and detach system calls have less pagetable setup work to do in the kernel.

Older versions of strace (like in RHEL 7) did not have such an option.

There's also strace -kk (--stack-trace=source), but when I just ran it on Ubuntu 24.04, got this error:

  $ strace -kk pwd
  strace: Stack traces with source line information (-kk/--stack-trace=source option) are not supported by this build of strace

Also, there's "perf trace" that has now gotten pretty good reporting the system call arguments and context (in older versions it didn't report enough details of the system call arguments & their contents).

As strace uses userspace ptrace(), it slows down the traced processes and may even cause failures due to mucking around with signalling, perf trace doesn't have that problem as it uses kernel tracepoints.

From the article: "Now ME firmware includes a full-fledged operating system with processes, threads, memory manager, hardware bus driver, file system, and many other components."

Thanks for confirming. (I deliberately worded my question like that, as it makes sense to roll such features out in phases, just like plenty of others have done - off the top of my head, DuckDB and Apache Impala for example.)

Edit: In the post you mentioned that you optimized the hot path for likely taking the non-matching record path. Sometimes with well-designed partition wise joins, most of the records actually do match and survive the join - I guess in such (estimated or detected) cases you could switch to an alternative path with a match being the likely branch in the hot path…

Does the (build side) hash table have to entirely fit in RAM with the current implementation?

Just random LLM use (no training) and some cuDF experiments so far. So far I haven't noticed any issues (and I tend to investigate any unexplained glitches).

It was 3am! :-)

I suspect that longer PCIe extender cables would have signal quality issues (so far with my setup I haven't seen any issues, mem copy throughput is as expected and no PCIe AER errors reported)

That's a topic for another blog post, but I use these as servers, so don't need direct HDMI/display connectivity - but one reason is to reduce noise. And I don't have a garage!

There's indeed some comparison there as (as far as I understand) the current implementation of domain constraints all still works on a single table (one column or multicolumn). But the flexible domains (enforce different domains based on a field's value or expression's result) are pretty cool and the JSON-schema based domains could make some (JSON-related) validation things easier out of the box too (I searched the web, looks like Postgres has support for domains too).

For more complex cases, one could write (or autogenerate) triggers, but that will likely cause performance and maintenance issues... so the other option is to standardize any important data validation & logic into application code - and that part of application code can be stored procedures if it needs to be close to the database.

Edit: Sometimes it's easier to sell the idea of using stored procedures for (data) logic to non-database developers when you call them database APIs instead of stored procedures :-)

FWIW, Oracle now has data domains that allow more complex constraints, including JSON schema based ones:

https://docs.oracle.com/en/database/oracle/oracle-database/2...

I can’t find the blog/article anymore, but its message was that “when you see something suboptimal in the code, do not assume incompetence”. As people who wrote the code may have had tight deadlines, different priorities set for them and other factors that may have prevented the developers from “doing the right thing” immediately…

I had been using DuckDuckGo for the last 2-3 years, but starting from early this year I noticed that their search index just didn’t index some of the things I searched for (enterprise tech stuff). These searches worked ok before and still worked with other engines. So I finally switched to Kagi and am happy with it.

Or the fact that Couchbase wants to get even deeper into building a SQL layer (SQL++) on top of their datastore.

It interprets where it needs to jump and then jumps to the precompiled binary machine code locations that are executed natively on the CPU, no interpretation going on (I guess it's conceptually something like instruction traces inside the CPU trace cache, but done at higher level). These precompiled building blocks are shipped in separate libraries, one library for each CPU architecture on a platform (SSE4.2, AVX, AVX2, AVX-521 on AMD64 and other SIMD architectures on other platforms that Oracle supports). Oracle dynamically loads the correct library matching the CPUs capability during the startup and starts jumping there as needed.

So this is not bytecode interpretation, it's native machine code executed directly on CPU whenever the SQL exec engine decides to jump there. This is different from, say Apache Impala that compiles new LLVM machine code for each query execution for the query's scanning tight loops.

Edit: I guess why I see this as not just not regular bytecode interpretation (I don't actually know that much about it in general), is that these building blocks can include various loops (and can do their thing on entire vectors of data), so looks like they can push quite a bit of complexity into the machine code sections, before returning back to the normal interpreted AST/opcode land.

4. lots of small building blocks of static machine code precompiled/shipped with DB software binary, later iterated & looped through based on the query plan the optimizer came up with. Oracle does this with their columnar/vector/SIMD processing In-Memory Database option (it's not like LLVM as it doesn't compile/link/rearrange the existing binary building blocks, just jumps & loops through the existing ones in the required order)

Edit: It's worth clarifying that the entire codebase does not run like that, not even the entire plan tree - just the scans and tight vectorized aggregation/join loops on the columns/data ranges that happen to be held in RAM in a columnar format.

I just tested llama3:70b with ollama on my old AMD ThreadRipper Pro 3965WX workstation (16-core Zen4 with 8 DDR4 mem channels), with a single RTX 4090.

Got 3.5-4 tokens/s, GPU compute was <20% busy (~90W) and the 16 CPU cores / 32 threads were about 50% busy.

I also love that it can be done with just a few code line changes:

https://github.com/NVIDIA/open-gpu-kernel-modules/commit/1f4...

Oracle does this as well and I suspect many other row-major RDBMS storage engines do too.

If you look into the edits in Wayback Machine, you see that previously, the "Ken's experience" was:

"Unnerved by the idea that he could have rolled over on his watch while sleeping and allowed criminals to take over his Apple account, Ken said ..."

Once the article was updated, the original sentence implying that criminals could take over your account while you are sleeping was completely rewritten to say the 180 degree opposite - completely reversing what the initial sensational content said. In reality it is not possible to accidentally hand over your account to attackers by accidentally tapping Allow on your watch in your sleep.

The update disclosure only says: "Added perspective on Ken’s experience."

There's an important omission in the article and the top comments here don't mention it either: Accidentally tapping "Allow" does not allow the attacker to change the password on their web browser. When you tap Allow on your device, you are shown the 6-digit pin on your device and you can use it to change your password on your device. The final part of the attack is that the attacker calls you using a spoofed Apple phone number and asks you to read out the 6-digit pin to them. If you choose to give out the 6-digit pin to the attacker over an incoming phone call, then they can use it in their browser to reset your password.

It's surprising that Krebs chose to omit this little detail in the security blog and instead seemed to confirm that someone could completely give away access to their account while sleeping.

I recently bought an old Mac Pro 2013 (trashcan) with 12 cores/24 threads and 128 GB ECC RAM for my upgraded "always-on" machine - total cost $500. Installed Ubuntu 22.04, works out of the box (23.10 had some issues). Unfortunately it's hard/impossible to completely suspend/disable the two internal AMD Radeon GPUs to lower power consumption. I got it down to ~99W consumption when idle, when using "vgaswitcheroo" to suspend one of the GPUs (and it set the other one to D3hot state). My Intel NUC consumes almost nothing when idle (my UPS reports 0 W output while its running, even with 4 NVMe disks attached via a Thunderbolt enclosure). I don't want a 100W heat generator running 24x7, especially when I'm away from home, so will need to stick with the NUC...

Understand first, then fix. And you understand by measuring the right thing at the right time (scope). Systemwide resource utilization averages are not gonna tell you where your critical thread or database connection is spending their time at - you need to measure (profile) precisely where your task of interest is spending their time.

I've learned a lot from Cary Millsap over the last 2 decades and he recently published a general performance optimization book "How to Make Things Faster" that I can recommend [1]. It's less about tools, more about the method and systematic approach for performance optimization:

[1] https://method-r.com/books/faster/

I don't have an ASD, but back in 2020 I bought the LG UltraFine 5K from Apple's website together with a laptop and the LG monitor's colors all had a yellowish hue to them. Some Internet searches and possibly their support forums claimed that this is normal, it's just how the monitor works, or something like that (yes I did try various color temperature and config settings - all yellow).

Luckily this "wasn't my first monitor", so I quickly returned it and went back to Dell that's always been OK enough so I don't ever have to pay attention to which monitor or display setting I'm using.