Brett (ggtgp.delete@this.yahoo.com) on November 27, 2020 1:18 pm wrote:
> anon2 (anon.delete@this.anon.com) on November 26, 2020 5:59 pm wrote:
> > Brett (ggtgp.delete@this.yahoo.com) on November 26, 2020 4:11 pm wrote:
> > > Andrey (andrey.semashev.delete@this.gmail.com) on November 26, 2020 12:33 pm wrote:
> > > > Brett (ggtgp.delete@this.yahoo.com) on November 26, 2020 11:29 am wrote:
> > > > >
> > > > > The beauty of this approach is that all this database needs is to import/export git, and
> > > > > have a filesystem driver, and you don’t care what the rest of the world is doing.
> > > > >
> > > > > You don’t even need git, git can write to the filesystem, there are just some opportunities
> > > > > to optimize git while you are at it. You can inline compression if it is free, etc.
> > > > >
> > > > > Everything just works, and you can now optimize the speed of builds and git by tuning the database
> > > > > layout behavior. A folder tree with hundreds of files spread all over the disk is now a small
> > > > > set of large linear packed files that stream quickly and use less disk and less ram.
> > > >
> > > > You're forgetting about fragmentation, which will inevitably happen as you modify the sources.
> > > > And if we're talking about SSDs then fragmentation is not an issue in either case.
> > >
> > > Git updates are largely a write only operation, compiles are a read only operation,
> > > editor changes only effect a handful of files and are irrelevant.
> > > The database only holds code, compiler output goes to the filesystem.
> > > Detecting disk idle and rewriting the database for speed is a given.
> > > Detecting a compile is trivial, saving the access order so
> > > as to rewrite the file order packing to match is trivial.
> > > Grep does not care about file order generally, gets a database
> > > directory file list in compile order, which is near optimal.
> > > Actual file order will go in and out of subdirectories almost randomly
> > > but a custom grep executable can follow database file order.
> > > The database knows which files are redundantly read from the last compile and keeps those sectors mapped.
> > >
> > > Now are you starting to see the benefits?
> > >
> > > A simple smart database turns a thousand different reads into almost one linear fire hose of packed
> > > data. The Linux compile advantage of 2X over MacOS and 4X+ over Windows turns into a deficit.
> > >
> > > What if the database gets corrupt?
> > > sudo rm -rf/*
> > > git
> > >
> > > Yes I included a typo.
> > >
> > > The Linux compile advantage is a stupid pet trick with little real world
> > > use outside of compiles, and will one day be rendered obsolete.
> >
> > Do you honestly believe you are in a position to be making such claims?
> >
> > I absolutely believe in the visionary or polymath who can see things in a different way
> > or at a higher level and revolutionizes a field or a technology. I've seen it happen.
> >
> > These people are not idle talkers or musers or outsiders who know or care little about existing
> > technologies and practices, they work hard, they are dedicated, they know the current state
> > of the art as well as anybody, and that's how they understand they can do better.
>
> I spent 20 years in the video game industry optimizing code everyone else said was already optimized,
> and the proof was that the code was 20 years old and used by hundreds of AAA titles.
> Much of the code WAS optimal for the previous generation of hardware,
> or more often the previous-previous generation of hardware.
>
> Few programmers understand how CPU’s work and most importantly how that effects code performance. Others
> think I am pulling off miracles, it is just simple engineering, just as you say, hard work and knowledge.

This knowledge and experience does not transfer to filesystems and CPU logic though. It might give you a bit more idea than the average programmer, but maybe not.

I have no problem with people pointing out what sucks in their experience without understanding how it works. I have no problem with dreaming big from people who aren't experts ("oh hey I have this great idea the filesystem could be a database...").

What annoys me is the combination of 1. pointed criticism of the state of the art and people who actually make this stuff happen as in your rant (obviously motivated by your upset that Linux beats OSX in performance). 2. proclaiming that you know what all the problems are and exactly how they should be fixed despite clearly having a flimsy awareness of the problems that arise with your "the right way" to do things (which has been tried more than once before). 3. Not only that but you also demonstrated that not only are you oblivious to the current state of technology, you don't even understand the very basics of the simplest building blocks from half a century or more ago.

And yet you still seem to feel no shame or humility and go on boasting and proclaiming about how you know everything. I point out a clear fundamental misunderstanding you had about filesystem updates, and you just completely ignore my post and go on to make even more fanciful claims.

This is why you are a blowhard and a charlatan. Just for once try the next time you post here to not begin with the assumption that you know everything about everything.

>
> > You on the other hand seemed to be unaware of a basic filesystem metadata block cache or buffer cache
> > that has been a thing for half a century. This is just like your "post-RISC" incoherent babbling. You
>
> RISC was optimal for a short decade in the last century,

"RISC" including RISC ideas in x86 is what all of the world's top CPU designers still do, are still pursuing and they are making billions of dollars from billions of dollars of investment, and continue to improve the technology while these handwavy "post-RISC" concepts you proclaim to be far better are nowhere to be seen. Surely the self-proclaimed genius video game programmer would know better than all those thousands of researchers and logic designers though.

> I want to know what comes next.

Again I have no problem with that, but that's not what you say and act like, is it? You act like you *know* what comes next or what should come next, and it is your super-duper thing that solves everything.

>
> I have learned a lot, my most recent proposal over on comp.arch to use a pair of tightly
> coupled six wide cores to run loops 12 wide is somewhat viable. You do need to be smart
> with cloning data across the pair of L0 and L1 data caches or you will be data starved.
>
> Yes this is mental masterbation as I am in software and this is a hardware issue.

Again, no problem with that. But you're painting yourself a little more humble than reality, aren't you?

Your bullcrap about filesystems and databases is also mental masturbation because you are as far away from those concepts as you are from CPU design. Being "in software" doesn't help. So try being humble about that as well.