[flagged]
DRAM has a design flaw from 1966. I bypassed it [video]
101–110 of 174 posts
Re: DRAM has a design flaw from 1966. I bypassed it [video]
#102Really enjoyed this video, and I'm pretty picky. I learned a lot, even though I already know (or thought I knew) quite a bit about this subject as it was a particular interest of mine in Comp Sci school. I highly recommend. Skip forward through chunks of the train part though where she is messing around. It does get more informative later though so don't skip all of the train part
Re: DRAM has a design flaw from 1966. I bypassed it [video]
#103Earlier quoted context omitted.
it's explained in the video, and there's no way I'll be explaining it better than her
you could however link to the timestamp where that particular explanation starts. i am afraid i don't have time to watch a one hour video just to satisfy my curiosity.
The three answers it found were:
- Avoiding lock-in to them: http://www.youtube.com/watch?v=KKbgulTp3FE&t=1914
- Competitive advantage: http://www.youtube.com/watch?v=KKbgulTp3FE&t=1852
- Perceived Lack of Use Case: http://www.youtube.com/watch?v=KKbgulTp3FE&t=1971
Those points do actually exist in the video, I checked. If there are more, I don't know about them, as I haven't yet watched the rest of the video.
Re: DRAM has a design flaw from 1966. I bypassed it [video]
#104Earlier quoted context omitted.
No I felt the same way, they're exactly like the usual LLM bot comment where a LLM recap ops and ends with an platitude or witty encouragement. But all the accounts are old/legit so I think that you and me have just become paranoid...
I have become oversensitive to this, and my brain is probably generating a lot of false positives. I don't think it's necessarily the case here, but I've wondered if people who use LLMs a lot take over some of its idiosyncrasies and in a way start sounding like one a bit. A strange side effect is that I've come to appreciate text with grammatical errors, videos where people don't enunciate well etc because it's a sig…
Re: DRAM has a design flaw from 1966. I bypassed it [video]
#105Earlier quoted context omitted.
1. not that I can think of, due to the core split. It really has to be independent cores racing independent loads. anything clever you could do with kernel modules, page-table-land, or dynamically reacting via PMU counters would likely cost microseconds...far larger than the 10s-100s of nanoseconds you gain. what I wished I had during this project is a hypothetical hedged_load ISA instruction. Issue two requests to t…
Is there a reason you can think of why AMD, Intel etc. would not want to do this? Really enjoyed the video and feel that I (not being in the IT industry) better understand CPUs und and RAM now.
However, I do seem at least 2 downsides to this method.
Number one it is at least 2x the memory. That has for a decently long time been a large cost of a computer. But I could see some people saying 'whatever buy 8x'.
The second is data coherency. In a read only env this would work very nicely. In a write env this would be 2x the writes and you are going to have to wait for them to all work or somehow mark them as not ready on the next read group. Now it would be OK if the read of that page was some period of time after the write. But a different place where things could stall out.
Really liked her vid. She explained it very nicely. She exudes that sense of joy I used to have about this field.
Re: DRAM has a design flaw from 1966. I bypassed it [video]
#106Earlier quoted context omitted.
Indeed. And only for certain DRAM refresh strategies. I mean, it's at least conceivable that a memory management system responsible for the refresh notices that a given memory location is requested by the cache and then fills the cache during the refresh (which afaiu reads the memory) or -- simpler to implement perhaps -- delays the refresh by a μs allowing the cache-fill to race ahead. (seems that in the earlier sub…
None of the DDR2 and onwards memories have anywhere near enough bandwidth to meet refresh frequency on each bit by you even just reading it in a loop. The refresh that we do is run in parallel on the memory arrays inside the RAM chips completely bypassing any of the related IO machinery.
I'm not saying that it's easy or cheap or worthwhile (I'd rather guess it's not in most cases), but I don't see why it couldn't be done.
Re: DRAM has a design flaw from 1966. I bypassed it [video]
#107Am I the only one who feels the comments here don't sound organic at all?
No I felt the same way, they're exactly like the usual LLM bot comment where a LLM recap ops and ends with an platitude or witty encouragement. But all the accounts are old/legit so I think that you and me have just become paranoid...
It's like when you interact with any other piece of language oriented media.
Re: DRAM has a design flaw from 1966. I bypassed it [video]
#108Earlier quoted context omitted.
[flagged]
This is not a problem which needed to be fixed, it's an improvement in efficiency - though a costly one. We are talking about a company which do make their own custom microchips so you could very well be right, but it may also be that they weren't even aware this was possible. Citadel executes trades in about 10 microseconds, so a 500 nanosecond reduced execution time is a 5% improvement. For a company which executes…
Re: DRAM has a design flaw from 1966. I bypassed it [video]
#109Earlier quoted context omitted.
For an HFT firm, RAM cost is a non-issue. Even the tiniest improvement in latency can result in millions of dollars of extra profit. They can octuple their RAM usage and still make a killing. I bet Citadel already has reached out to Laurie :)
[flagged]
this is unnecessary.
Re: DRAM has a design flaw from 1966. I bypassed it [video]
#110Earlier quoted context omitted.
This is not a problem which needed to be fixed, it's an improvement in efficiency - though a costly one. We are talking about a company which do make their own custom microchips so you could very well be right, but it may also be that they weren't even aware this was possible. Citadel executes trades in about 10 microseconds, so a 500 nanosecond reduced execution time is a 5% improvement. For a company which executes…
I saw a few years ago one group buying spools of fiber just to 'slow down' the trades. As they were submitting them to different datacenters across the country. They wanted everything to show up at the exact same time so no one would front run their trades on different datacenters. They are willing spend millions on HW if it gives them an edge in the market. They would buy bespoke boards that could hold 16x the RAM i…