ljchen · HackerTrans

10 bulan yang laludiscuss

Most tech companies need vc money to bootstrap product development and businesses. The question is how much is "too much"? A very subjective question, especailly considering huge diferences across different domains and industries. It's easy for most people (investors/founders/LPs) to simply follow market trends. Few have cool heads at volatile times. The market will play out anyway.

ljchen

11 bulan yang laludiscuss

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

11 bulan yang laludiscuss

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

11 bulan yang laludiscuss

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

11 bulan yang laludiscuss

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

12 bulan yang laludiscuss

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

12 bulan yang laludiscuss

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

2 tahun yang laludiscuss

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".

comments