• jart 44 days ago
    I'm loving how half the comments are, "I don't know why I'd ever need to look at my program's memory?" And folks wonder why things are so bloated!
    • naikrovek 43 days ago
      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.

      • josephg 43 days ago
        > 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!

        • pca006132 43 days ago
          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.

        • naikrovek 43 days ago
          I had so much more here but I'll just leave this:

          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.

          • josephg 42 days ago
            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.
            • naikrovek 42 days ago
              ok so I get to call you the name I prefer, then? or do I have to respect your name?
              • josephg 42 days ago
                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.

    • jeroenhd 43 days ago
      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.

    • dekhn 43 days ago
      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.

    • usmannk 43 days ago
      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.
  • marcodiego 44 days ago
    The code is interesting: https://github.com/jart/cosmopolitan/blob/master/tool/viz/me...

    Feels really old school. Looks like something from people used to write DOS programs.

    • eatonphil 43 days ago
      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.
      • jart 43 days ago
        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.
        • dekhn 43 days ago
          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.
        • charcircuit 43 days ago
          >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

          • jart 43 days ago
            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.
            • donut 43 days ago
              I'm reminded of the thesis that worse is better:



            • charcircuit 43 days ago
              >Then why is everything based on UNIX then?

              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.

          • charcircuit 43 days ago
            bug free
      • elteto 43 days ago
        The "rule" that I've sort of figured out from reading old C code is that global state in the file that contains main() is ok.
      • marcodiego 43 days ago
        For a well written code that is less than 1000 lines in a single file using very few abstractions, that number of global variables is not a problem.
    • chris1993 43 days ago
      It's a work of beautiful clarity
    • mcdonje 43 days ago
      Really digging the retro vibe of the code, man.
      • naikrovek 43 days ago
        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.

  • ahartmetz 43 days ago
    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
    • jart 43 days ago
      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.
  • teddyh 44 days ago

  • CyMonk 43 days ago
    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.
  • anitil 43 days ago
    The first thing I thought of was blinkenlights, and of course it's Justine. Fantastic!
  • PenguinRevolver 44 days ago
    someone's gonna recreate bad apple on this.
  • ape4 44 days ago
    The one executable supports PE+ELF+MachO+ZIP+SH
  • makeworld 44 days ago
    Can anyone provide an example use case for this? Especially those different curves.
    • anitil 43 days ago
      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

      • jart 43 days ago
        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.
        • anitil 43 days ago
          Ah thanks for that I remember that page now, time for a reread!
    • zamadatix 44 days ago
      The different curves do a good job of preserving locality when mapping to 2d space.
  • Arrath 43 days ago
    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.

  • atorodius 44 days ago
    Looks pretty sweet. Not sure what I'd use it for but I love live updating stuff
    • fortyseven 44 days ago
      Reverse engineering; getting an idea of what an unknown app might be doing, and where, so you can trace it back in the code. And so on.
      • Loocid 43 days ago
        Surely whatever RE tool you're using already has a memory viewer built in.
    • T3OU-736 44 days ago
      Hrm. As a half-bakes thought - if code handles sensitive data, making sure it is correctly obfuscated in memory?
      • csdvrx 44 days ago
        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.
  • IAmLiterallyAB 43 days ago
    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.
  • DonHopkins 44 days ago
    Oh cool! That would make a great screen saver, too. ;)
  • DrBazza 43 days ago
    Reminds me of *mzap on the bbc micro 40 years ago.