What's up faggots. I want to read an ARM assembly reference manual (~160MB) without running out of memory on my M1 Macbook Air. How do you guys read large PDF files typically? Chrome, Preview, Skim, Safari, they all use a bunch of memory >=700MB and don't even run very well (Preview hangs for a minute or more before starting).
I'm a linuxfag so I use mupdf. By default it has a 256mb cache, but you can use a low-memory flag to remove it. I'm not a macfag so idk if you can use it.Just like your computer uses more memory to display images than a text file, A PDF behaves the same way. Make sure your copy is a native pdf and not a scanned version.Why are you so hung up on ram usage anyway? Apparently an M1 Macbook Air has 8-16GB ram. Using ~1GB to read a hefty 500+ page book seems reasonable and shouldn't be affecting performance. Maybe it's your browser with a 100 tabs open or the viruses from all that dolphin porn. Alternatively, buy a physical copy of the book or load it on a separate device so you can multitask.
that's a good book. i just got to chapter 7. it's always rewarding when your compiler passes all of the test cases.
>>108945486I was using it with VSCode and docker and dev containers because the book is for x86 asm but M1 Mac so emulation. I would frequently get close to 80% mem usage and I don't like swap for autistic reasons (why add extra writes to my SSD)I'm going to move to vim+terminal+arm64 asssembly so memory usage doesn't matter much after that. It's mostly a principle thing. The whole PDF is 160MB so why does it take 5x that to simply display a portion of it? I read the PDF spec a little bit to see what it might take to write my own PDF viewer and I don't see why this RAM usage is justified. In addition to using a bunch of RAM, these programs don't even run well. If it ran well or used a little memory that's one thing, but doing neither offends me a bit.
>>108945182I found Evince actually runs pretty well for being GNOME software.
>>108945182https://github.com/homebrew-zathura/homebrew-zathura
>>108945565>uses VSCode and docker and dev containers>hmm must be the pdf I have open causing lagTypical "optimization" fag focusing on the wrong issues.>I don't see why this RAM usage is justifiedLike I asked, are you using a native pdf or scanned? Given your filesize and ram consumption, it sounds like the latter. A lot of times the resolution of these scans are crazy, and your computer caches multiple neighboring pages for smooth browsing. That's like opening several 5,000x5,000 images on your computer. That can reach 1GB ram very easily. It's not the program's fault for doing what you ask.Your options would be to shrink the page sizes (somehow), or see if the viewer has some cache settings to only store 1 page at a time (but it would make scrolling through pages slower).>The whole PDF is 160MB so why does it take 5x that to simply display a portion of it?That filesize is the compressed version. The PDF has be decompressed to be read. Pretty much all files stored on a computer works this way.
>>108945722This is the PDF used: https://documentation-service.arm.com/static/69d7cbfc3fb3b839f93e5b1e?token=Even with VSCode closed and docker off scrolling through this PDF is choppy.Good point about 5Kx5K images.Keeping ten of those in memory if they were BMPs would be a gig.Looking at the information of the file, Finder claims that it's 595x792, 17,153 pages.
>>108945182>I want to read an ARM assembly reference manual>the book is for x86 asm
Okular works just fine
>>108945794>>108945182picrel explains how to convert to and emit x86 but my computer is ARM. Most of the instructions are simple (idiv, imul, sh*, mov, pop, push, etc) but I wanted documentation for operand order and which instructions (if any) accept memory addresses as operands. Then I tried opening the damn thing.
>>108945835>picrel>no picnot beating the charges >>108945794 at this rate
>>108945864Why post another picture of Writing a C Compiler when I already did in the original post?Is the dude mementoposting not aware that I'm making my way through WACC?Perhaps I'm drinking retard juice.
>>108945774Interesting. I've never encountered a pdf with so many pages.With firefox it loaded at 400MB ram, but as I kept scrolling to a thousand pages, it climbed to over 1GBSame thing with XReader, which is my OS's default pdf viewer. Eventually it froze.With mupdf, it was about 150MB, and when I managed to scroll to the end it reached a peak of 800MB. When I scrolled back down it wouldn't increase anymore. Didn't really lag or anything but still surprising behavior.I assumed that pdf viewers would just cache like 10 pages, but apparently they cache every page you scroll past? It's weird. If you open the pdf and jump to the page you wanted instead of spinning your mouse wheel like in jeopardy, you probably wouldn't have this issue. But as you view more pages over time, the ram usage will slowly climb. I wonder if there is a software that doesn't have this issue.
>>108946027>jeopardyThe Price Is Right?Wheel of Fortune?
idk where the fuck you got a 160MB reference manual but I found a 22MB "ARMv7-A and ARMv7-R Reference Manual.pdf" with 2738 pages
>>108946308I meant price is right. Idk why I mix those names up
>>108946351the M1 is ARMv8.4-A
>>108946410i doubt armv7 to armv8.4 adds almost 10x more instructions
>>108945794only the final pass of the compiler emits x86 assembly. you could modify the code generation pass to be support ARM or even change the three-address code pass to be compatible with an existing multi-platform compiler backend. the book isn't going to spoonfeed how to do it thoughever.
