Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A friendly tour of process memory on Linux

0xkato.xyz

Post reply on HN
Print view View original

31–36 of 36 posts

Re: A friendly tour of process memory on Linux

#31

Post by eru »

drbig wrote: post #5

Instruction pipelining and this is exactly why I wish we still have the time to go back to "it is exactly as it is", think the 6502 or any architecture that does not pretend/map/table/proxy/ringaway anything. That, but a hell lot of it with fast interconnect! ... one can always dream.

Do you want to throw out out-of-order-execution and pipelining while you are at it, too?

I'm semi-serious: there are actually modern processor designs that put this burden on the programmer (or rather their fancy compiler / code generator) in order to keep the silicon simple. See eg https://en.wikipedia.org/wiki/Groq#Language_Processing_Unit

Re: A friendly tour of process memory on Linux

#32

Post by harry8 »

taeric wrote: post #30
harry8 wrote: post #29

Earlier quoted context omitted.

Think about using a modern x86-64 cpu core to run one process with no operating system. Know exactly what is in cache memory. Know exactly what deadlines you can meet and guarantee that. It's quite a different thing to running a general purpose OS to multiplex each core with multiple processes and a hardware walked page table, TLB etc. Obviously you know what you prefer for your laptop. As we get more and more cores…

I just don't know that I see it running any better for the vast majority of processes that I could imagine running on it. Was literally just transcoding some video, playing a podcast, and browsing the web. Would this be any better? I think that is largely my qualm with the dream. The only way this really works is if we had never gone with preemptive multitasking, it seems? And that just doesn't seem like a win. You d…

> Was literally just transcoding some video, playing a podcast, and browsing the web.

Yeah that's the perfect use case for current system design. Nobody sane wants to turn that case into an embedded system running a single process with hard deadline guarantees. Your laptop may not be ideal for controlling a couple of tonnes of steel at high speed, for example. Start thinking about how you would design for that and you'll see the point (whether you want to agree or not).

Re: A friendly tour of process memory on Linux

#33

Post by taeric »

harry8 wrote: post #32
taeric wrote: post #30

Earlier quoted context omitted.

I just don't know that I see it running any better for the vast majority of processes that I could imagine running on it. Was literally just transcoding some video, playing a podcast, and browsing the web. Would this be any better? I think that is largely my qualm with the dream. The only way this really works is if we had never gone with preemptive multitasking, it seems? And that just doesn't seem like a win. You d…

> Was literally just transcoding some video, playing a podcast, and browsing the web. Yeah that's the perfect use case for current system design. Nobody sane wants to turn that case into an embedded system running a single process with hard deadline guarantees. Your laptop may not be ideal for controlling a couple of tonnes of steel at high speed, for example. Start thinking about how you would design for that and yo…

Apologies, almost missed that you had commented here.

I confess I assumed writing controllers for a couple of tonnes of steel at high speed would not use the same system design as a higher level computer would? In particular, I would not expect most embedded applications to use virtual memory? Is that no longer the case?

Re: A friendly tour of process memory on Linux

#34

Post by harry8 »

taeric wrote: post #33
harry8 wrote: post #32

Earlier quoted context omitted.

> Was literally just transcoding some video, playing a podcast, and browsing the web. Yeah that's the perfect use case for current system design. Nobody sane wants to turn that case into an embedded system running a single process with hard deadline guarantees. Your laptop may not be ideal for controlling a couple of tonnes of steel at high speed, for example. Start thinking about how you would design for that and yo…

Apologies, almost missed that you had commented here. I confess I assumed writing controllers for a couple of tonnes of steel at high speed would not use the same system design as a higher level computer would? In particular, I would not expect most embedded applications to use virtual memory? Is that no longer the case?

"Hard Real Time" is the magic phrase to go as deep as you want to.

Re: A friendly tour of process memory on Linux

#35

Post by taeric »

harry8 wrote: post #34
taeric wrote: post #33

Earlier quoted context omitted.

Apologies, almost missed that you had commented here. I confess I assumed writing controllers for a couple of tonnes of steel at high speed would not use the same system design as a higher level computer would? In particular, I would not expect most embedded applications to use virtual memory? Is that no longer the case?

"Hard Real Time" is the magic phrase to go as deep as you want to.

This isn't really answering my question. Have they started using virtual memory in hard real time applications? Just generally searching the term confirms that they are still seen as not compatible.

Re: A friendly tour of process memory on Linux

#36

Post by harry8 »

taeric wrote: post #35
harry8 wrote: post #34

Earlier quoted context omitted.

"Hard Real Time" is the magic phrase to go as deep as you want to.

This isn't really answering my question. Have they started using virtual memory in hard real time applications? Just generally searching the term confirms that they are still seen as not compatible.

In addition to search engines you can learn a great deal about all sorts of things using an LLM. This works well enough if you don't want to pay. They are very patient and you canb go as deep as you want. https://duckduckgo.com/?q=DuckDuckGo+AI+Chat&ia=chat&duckai=...
Post reply on HN