I don't think one needs to view memory contents of their own program to know what what the memory contents are, roughly, or to know how to use memory efficiently.
Debuggers and profilers already exist for the developers of applications to know these things.
this tool seems much more useful for the reverse engineer who is watching memory of a target application visually while they step in a debugger. this wouldn't even be for reading specific values of RAM, again the debugger is usually quite good at that, but instead would be useful to see how things change as execution continues.
> Debuggers and profilers already exist for the developers of applications to know these things.
One big difference between an intermediate and an expert programmer is that an expert develops their intuition for how the program they write will compile and run. Can you guess correctly how fast, or how slow each function will be? Or what the optimizer will do a good or a bad job at optimizing? Can you tell before you've written your code when avoiding allocations is going to speed things up, and when it won't matter?
Debuggers and profilers honestly aren't very good at giving you a "zoomed out" view of whats going on in your program. Each tool shows you a specific aspect of your program, and hides everything else. For profilers, thats usually what the CPU spends its time on. For debuggers, the execution path of a single function. Godbolt shows how the optimizer works. And so on.
But from my perspective, having more tools which show different aspects of my code is almost always a win. I never know ahead of time which perspective will let me double my program's performance, or halve memory usage. Writing code is easy. Understanding code is much more complex.
So yeah, from a software development point of view I think this is neat! I want to give it a try on some of my programs because I expect to see my mental model animated back at me, and I anticipate being surprised. This looks cool!
You can also check statistics like number of page faults, data/instruction cache misses with a profiler. Usually (at least for me), looking at the execution trace, CPU statistics, understanding the code and input are enough for optimization. I think profilers can only help you to focus on certain hot spots of your program, and provide hints to things that are most expensive. You still have to make some educated guess.
I think dumping the raw memory is usually used for debugging (postmortem?) rather than to optimize for performance.
Because “compiler explorer” is a wordy, generic and boring name. “Godbolt” is short, specific and memorable. I think my chance of being understood is much higher by calling it godbolt.
You're dying on a weird hill here. Deciding on a name is a multiplayer game. It involves the author and the general public. We're collectively trying to converge on something short, memorable and snappy. We respect the author. But not too much.
I wrote a blog post last year with a working title of "CRDTs go brrr". I renamed it to something more boring before posting it, but "crdts-go-brrr' still shows up in the URL. Universally when people talk to me about that article, they use the original title. Not whatever I renamed it to.
What do I do about that? Do I get angry about it? Do I demand people stop using the catchy title I invented for my writing, then shied away from? No. The wisdom of the crowd has spoken. I accept it, learn and move on.
Matt Godbolt hosted his tool at godbolt.org, and everyone started calling it godbolt. Then he labelled it "Compiler Explorer" and ... everyone kept calling it godbolt because we remember it, and its in the URL, and its frankly a better name. Its telling that everyone (including you) knew what I meant in my comment. If I said "Compiler Explorer", I bet more people would have been confused. (I would have been confused!).
So yes, call me whatever you want. Exercise your freedom of speech boldly! But obviously, if you pick a name that other people don't recognise, you won't be understood. And if you insult me, I'll feel insulted. Its your right to do that, and my right to react however I like.
To be fair, memory profilers and analysers are probably much easier and more accessible than just raw memory dumps. Modern tools ranging from Valgrind to the web browser heap analyser is a lot easier to master than scrolling through megabytes of hex trying to find an area of memory that's not necessary.
Even if I were to debug memory using raw hex, I'd probably take a snapshot and open that in a good hex editor instead of just watching some blocks blink.
One of the first things I did as a c programmer on VMS (1987) was deference a pointer and look at my app memory map (I didn't know about virtual memory so I thought I was reading physical ram)
Even before that I'd scan through various parts of apple iie memory using the machine language lister. I love to troll thru ram.
I think the confusing part is the live view of utf-8 encoded memory scrolling by. As opposed to samples or profiles, which are more evidently useful to those who aren't doing systems programming regularly.
First off, Justine is a better programmer than I. But, and I don't mean this as a humblebrag, the use of all global variables for state makes me uncomfortable. If this is good C code (not saying it isn't) then maybe that's why I'm not a C programmer. Whatever the case, Justine is great.
That's a good instinct to have. 99% of the time we're writing something like an object library that's part of a much larger program. To use global variables in such code would impose difficulties on the application as a whole, with regard to things like threading, pollution of the linker symbol table, etc. But when you're writing small main.c programs like this one which don't use threads, globals can be a real advantage. In gdb, you can easy inspect their values. You can look at the linker output manifest listing to see how they're being arranged in your binary. If you look at a lot of the old original UNIX programs that were written back in the day, a lot of them looked very similar to this. So it's a great style. It's just not one that scales to large monolithic programs that most companies prefer to create. So over the years a cultural aversion to it was developed in many style guides.
I typically split any single main.c app into two parts: a library which depends on no shared State and a driver program that wraps around it. It's a lot harder to build than a monolithic main.c but in my experience it allows more people to build off of your application.
>If you look at a lot of the old original UNIX programs that were written back in the day, a lot of them looked very similar to this. So it's a great style.
The original UNIX programs weren't known for good style or being big free
Then why is everything based on UNIX then? (Or at least fated to be, via WSL.) If you want a real jewel, check out the v6 rand() function. It's an example of a function so bad that world-class experts on the subject of randomness have been falling over themselves for decades in academic papers talking about how to fix it.
It's not based off UNIX's code. UNIX based system's popularity can essentially be attributed to network effects. For most use cases it's good enough that it's not worth switching to something better because you lose the mountain of resources (both technological and human) that exist in the UNIX ecosystem.
if you mean the straight-forward nature of the code, I agree.
I think we over-complicate code today because we are promised ease of maintenance, or high-level declaration, or something else, and I don't think those promises have ever come true, except in very small textbook-type examples.
I wrote a similar thing with a Qt based GUI that, I think, exposes a little more information (more of the kernel's page flags). It reaches a quite respectable update rate for what it's doing (>=40 fps or so?) and it's fun to watch, though I haven't found particularly useful, err, uses.
https://github.com/KDAB/QMemstat
Please put screenshots in your README file because I'd love to see your work! Especially if they're GIFs. Contact me if you want to know the ffmpeg commands I used for memzoom.
this reminds me of the days when i was a teenager in the 80s and one of my hobbies was ripping the music from video games which basically meant identifying and isolating the code and data responsible for the audio. i remember taking a hex monitor and browsing/ scrolling through all the 64k memory of the commodore c64 and i could tell you just by looking at visual repeating data patterns in the raw hex dump where the song data was located.
I can think of two where this tool could be a first step -
1. Do you ever have a program that kind of just sucks? A bit slower than you expect, laggy but not in any specific way? The fundamental cause could be many things, but it could be, for example, thrashing memory pointlessly. I've seen processes memset/bzero then write, then memset/bzero for seemingly no reason and the source is difficult to follow.
2. How does struct alignment and malloc alignment impact your program? Maybe you could reduce your working set by using packed structs or changing the order of elements. Maybe you could choose a different allocator. But this tool could show you if you've got a bunch of loose space floating around
This is good information. On one of my other blog posts, I talk about what different types of memory look like under this viewer. https://justine.lol/sizetricks/#look It should give you the basic idea of how to interpret what you see under this intuitive display. It also goes more in depth into how size optimization tricks like struct alignment can be done.
Not for the first time[1], my virus scanner (Windows Defender this time, Sophos previously) flags the downloaded executable, in this case for "Trojan:Win32/Wacatac.B!ml" Which given how it analyzes memory may make sense as a false positive.
1) Justine's blinkenlights and one other I can't remember at the moment have done so previously as well.
This. I'd be nice to have a list of strings to monitor (ex: half of the ssh private key) and warn when they are found somewhere, to detect data exfiltration.
I'm not sure if text is the ideal way to look at memory. Perhaps something like a color gradient. With special cases for 0x00 and 0xff. But the Hilbert curve is neat.
Debuggers and profilers already exist for the developers of applications to know these things.
this tool seems much more useful for the reverse engineer who is watching memory of a target application visually while they step in a debugger. this wouldn't even be for reading specific values of RAM, again the debugger is usually quite good at that, but instead would be useful to see how things change as execution continues.
One big difference between an intermediate and an expert programmer is that an expert develops their intuition for how the program they write will compile and run. Can you guess correctly how fast, or how slow each function will be? Or what the optimizer will do a good or a bad job at optimizing? Can you tell before you've written your code when avoiding allocations is going to speed things up, and when it won't matter?
Debuggers and profilers honestly aren't very good at giving you a "zoomed out" view of whats going on in your program. Each tool shows you a specific aspect of your program, and hides everything else. For profilers, thats usually what the CPU spends its time on. For debuggers, the execution path of a single function. Godbolt shows how the optimizer works. And so on.
But from my perspective, having more tools which show different aspects of my code is almost always a win. I never know ahead of time which perspective will let me double my program's performance, or halve memory usage. Writing code is easy. Understanding code is much more complex.
So yeah, from a software development point of view I think this is neat! I want to give it a try on some of my programs because I expect to see my mental model animated back at me, and I anticipate being surprised. This looks cool!
I think dumping the raw memory is usually used for debugging (postmortem?) rather than to optimize for performance.
why do people call that tool "Godbolt"? it's "Compiler Explorer."
people who don't have an eye for detail about things like this are always the ones telling me what I'm doing wrong.
I wrote a blog post last year with a working title of "CRDTs go brrr". I renamed it to something more boring before posting it, but "crdts-go-brrr' still shows up in the URL. Universally when people talk to me about that article, they use the original title. Not whatever I renamed it to.
What do I do about that? Do I get angry about it? Do I demand people stop using the catchy title I invented for my writing, then shied away from? No. The wisdom of the crowd has spoken. I accept it, learn and move on.
Matt Godbolt hosted his tool at godbolt.org, and everyone started calling it godbolt. Then he labelled it "Compiler Explorer" and ... everyone kept calling it godbolt because we remember it, and its in the URL, and its frankly a better name. Its telling that everyone (including you) knew what I meant in my comment. If I said "Compiler Explorer", I bet more people would have been confused. (I would have been confused!).
So yes, call me whatever you want. Exercise your freedom of speech boldly! But obviously, if you pick a name that other people don't recognise, you won't be understood. And if you insult me, I'll feel insulted. Its your right to do that, and my right to react however I like.
Even if I were to debug memory using raw hex, I'd probably take a snapshot and open that in a good hex editor instead of just watching some blocks blink.
Even before that I'd scan through various parts of apple iie memory using the machine language lister. I love to troll thru ram.
Feels really old school. Looks like something from people used to write DOS programs.
The original UNIX programs weren't known for good style or being big free
https://www.dreamsongs.com/WorseIsBetter.html
:-)
It's not based off UNIX's code. UNIX based system's popularity can essentially be attributed to network effects. For most use cases it's good enough that it's not worth switching to something better because you lose the mountain of resources (both technological and human) that exist in the UNIX ecosystem.
I think we over-complicate code today because we are promised ease of maintenance, or high-level declaration, or something else, and I don't think those promises have ever come true, except in very small textbook-type examples.
[0] - https://www.youtube.com/watch?v=MVrNn5TuMkY&t=145s
1. Do you ever have a program that kind of just sucks? A bit slower than you expect, laggy but not in any specific way? The fundamental cause could be many things, but it could be, for example, thrashing memory pointlessly. I've seen processes memset/bzero then write, then memset/bzero for seemingly no reason and the source is difficult to follow.
2. How does struct alignment and malloc alignment impact your program? Maybe you could reduce your working set by using packed structs or changing the order of elements. Maybe you could choose a different allocator. But this tool could show you if you've got a bunch of loose space floating around
1) Justine's blinkenlights and one other I can't remember at the moment have done so previously as well.
Try downloading the older release.