Readit News logoReadit News
ljchen commented on PCI-SIG announces PCIe 8.0 spec with twice the bandwidth   tomshardware.com/tech-ind... · Posted by u/LorenDB
ljchen · 18 days ago
It's interesting that at the bottome of this article there is a recommened article about PCIE 7.0 published in June 2025. And it says "While PCIe 8.0 is still years away, PCIe 7.0 is a lot closer." Never know how these committees work.

Nevertheless, the perf increases of IO devices these days are in insane. I am wondering whether and when these perf promises will materialize. We are only on PCIE 5 this year and it's not that common yet. I am wondering how fast adoptions would be, which pushes manufacturers to iterate. The thing is that at the current level of PCIE 5, a lot of softwares already need to be rewritten to take full advantages of new devices. But rewriting softwares takes time. If software iterations are slow, it's questionable if consumers will continue to pay for new generations of devices.

ljchen commented on Ask HN: Have you ever regretted open-sourcing something?    · Posted by u/paulwilsonn
poszlem · 18 days ago
This is a very thoughtful post, and I sympathize with the sentiment, but I don't think it's really about "open sourcing" anything. The same could be said if you spent that time building model trains, working on a car, or engaging in any other hobby.
ljchen · 18 days ago
Agreed. "Open sourcing" means you do it for free but your work benefits others. And you may have an opportunity to pass the torch to others. For hobbies you keep it to yourself. I played an instrument for many years in spare time. I enjoyed it a lot. I eventually gave up, because my life changed and many other things popped up. On reflection, I still think it was an intersting experince for all those years. But I don't feel anything for it now.
ljchen commented on Show HN: Scar – A programming language for easy concurrency and parallelism   scarlang.pages.dev/... · Posted by u/death_eternal
ljchen · 19 days ago
Interesing idea. I am wondering what are the use cases on top of your head? I am asking because in my understanding people who care concurrency and parallelism are often those who care performance.
ljchen commented on Why doctors hate their computers (2018)   newyorker.com/magazine/20... · Posted by u/mitchbob
ljchen · 20 days ago
My personal feeling is that medical practices have not evovled too fast with computing. Electrical engineering, mechanical engineering, biomedical engineering etc all contributed a lot to how doctors treat diseases. But whether medical records are digitialized or not is not significant. It helps, but does not increase cure rate. Old fashioned doctors have good reasons to reject. But they do not say no to new medicine, new devices, new procedures.
ljchen commented on RIP Amazon QLDB   news.alvaroduran.com/p/if... · Posted by u/ohduran
ljchen · 24 days ago
I always find it odd to put the two keywords "blockchain" and "DB" together (though I know quite a few similar projects). The essence of blockchain, in my view, is to decentrialize because people don't want or can't have a single authority, whereas DB is centralized. The priority of blockchain is not performance (well, after decentralization, of course you don't have performance), and DB always prioritizes performance. Putting the two together is the most conflicting thing I've seen in the tech world.
ljchen commented on Writing memory efficient C structs   tomscheers.github.io/2025... · Posted by u/aragonite
munificent · 25 days ago
This is a good article, but it bugs me that it sort of only tells half the story.

Why are you making your structs smaller. Probably for "performance". If your goal is literally just reducing memory usage, then this is all fine. Maybe you're running on a small microcontroller and you just straight up don't have much RAM.

But these days, in most areas, memory is cheap and plentiful. What's expensive is CPU cache. If you're optimizing memory use for that, it's really about runtime speed and less about total memory usage. You're trying to make things small so you have fewer cache misses and the CPU doesn't get stuck waiting as much.

In that case, the advice here is only part of the story. Using bitfields and smaller integers saves memory. But in order to access those fields and do anything with them, they need to get loaded into registers. I'm not an expert here, but my understanding is that loading a bitfield or small int into a word-sized register can sometimes have some bit of overhead, so you have to pay attention to the trade-off.

If I was optimizing for overall runtime speed and considering packing structs to do that, I'd really want to have good profiling and benchmarks in place first. Otherwise it's easy to think you're making progress when you're actually going backwards.

ljchen · 24 days ago
I most agree, only except that perf is determined by a myriad of facors. Even if this piece of data fits into a cache line, it may have no or negative effect on the following code. For complex softwares, even if it's faster after the change, it's hard to tell what's the contributing factor really is. I once read a system paper (forgot the name) from a recent system research conference on how changing the code layout, e.g., moving a block of code, randomly may have unexpected impacts on perf.

Personally, I only pay attention to the cache line and layout when the structure is a concurrent data structure and needs to sync across multiple cores.

ljchen commented on Show HN: EloqKV – Scalable distributed ACID key-value database with Redis API   eloqdata.com/blog/2024/08... · Posted by u/hubertzhang
hodr_super · a year ago
If it's not open-sourced, I’m not going to use it to store my critical data. Just saying...
ljchen · a year ago
I second this. It's too risky and simply not worth it. Nevertheless, I find this "optional ACID" thing interesting. Many years ago when I was a graduate student, NoSQL was a big thing. It was widely claimed that transactions were expensive and you had to drop them in exchange to scale. I always had this question that if transactions were the culprit, why not turning them off? I later found that the relational system is such a monolith that everything (caching, concurrency control, logging, locking) is wired together in an extremely complex way and there is simply no "turning off".

u/ljchen

KarmaCake day1August 13, 2024View Original