https://github.com/FFmpeg/FFmpeg/blob/master/libavutil/x86/x...
This is a matter of exit cost: for instance look at linux bitkeeper->git exit.
Yeah, but I'd really only be concerned with what the ffmpeg developers want here.
On startup, it runs cpuid and assigns each operation the most optimal function pointer for that architecture.
In addition to things like ‘supports avx’ or ‘supports sse4’ some operations even have more explicit checks like ‘is a fifth generation celeron’. The level of optimization in that case was optimizing around the cache architecture on the cpu iirc.
Source: I did some dirty things with chromes native client and ffmpeg 10 years ago.
Would it ever make sense to write handwritten compiler intermediate representation like LLVM IR instead of architecture-specific assembly?
> Would it ever make sense to write handwritten compiler intermediate representation like LLVM IR instead of architecture-specific assembly?
IME, not really. I've done a fair bit of hand-written assembly and it exclusively comes up when dealing with architecture-specific problems - for everything else you can just write C (unless you hit one of the edge cases where C semantics don't allow you to express something in C, but those are rare).
For example: C and C++ compilers are really, really good at writing optimized code in general. Where they tend to be worse are things like vectorized code which requires you to redesign algorithms such that they can use fast vector instructions, and even then, you'll have to resort to compiler intrinsics to use the instructions at all, and even then, compiler intrinsics can lead to some bad codegen. So your code winds up being non-portable, looks like assembly, and has some overhead just because of what the compiler emits (and can't optimize). So you wind up just writing it in asm anyway, and get smarter about things the compiler worries about like register allocation and out-of-order instructions.
But the real problem once you get into this domain is that you simply cannot tell at a glance whether hand written assembly is "better" (insert your metric for "better here) than what the compiler emits. You must measure and benchmark, and those benchmarks have to be meaningful.
perf is included with the Linux kernel, and works with a fair amount of architectures (including Arm).
Not really. There are a couple of reasons to reach for handwritten assembly, and in every case, IR is just not the right choice:
If your goal is to ensure vector code, your first choice is to try slapping explicit vectorize-me pragmas onto the loop. If that fails, your next effort is either to use generic or arch-specific vector intrinsics (or jump to something like ISPC, a language for writing SIMT-like vector code). You don't really gain anything in this use case from jumping to IR, since the intrinsics will satisfy your code.
If your goal is to work around compiler suboptimality in register allocation or instruction selection... well, trying to write it in IR gives the compiler a very high likelihood of simply recanonicalizing the exact sequence you wrote to the same sequence the original code would have produced for no actual difference in code. Compiler IR doesn't add anything to the code; it just creates an extra layer that uses an unstable and harder-to-use interface for writing code. To produce the best handwritten version of assembly in these cases, you have to go straight to writing the assembly you wanted anyways.
You could invent a DSL for writing the kernels in… but they did, it's x86inc.asm. I agree ispc is close to something that could work.
The factors are something like:
- specialization: there's already a decent plain-C implementation of the loop, asm/SIMD versions are added on for specific hardware platforms. And different platforms have different SIMD features, so it's hard to generalize them.
- predictability: users have different compiler versions, so even if there is a good one out there not everyone is going to use it.
- optimization difficulties: C's memory model specifically makes optimization difficult here because video is `char *` and `char *` aliases everything. Also, the two kinds of features compilers add for this (intrinsics and autovectorization) can fight each other and make things worse than nothing.
- taste: you could imagine a better portable language for writing SIMD in, but C isn't it. And on Intel C with intrinsics definitely isn't it, because their stuff was invented by Microsoft, who were famous for having absolutely no aesthetic taste in anything. The assembly is /more/ readable than C would be because it'd all be function calls with names like `_mm_movemask_epi8`.
[0] https://gitlab.xiph.org/xiph/theora/-/blob/main/lib/x86/mmxl... is an example of what we are talking about here.
In the timespan of a L1 miss, the CPU could execute several dozen instructions assuming a L2 hit, hundreds if it needs to go to L3.
No wonder optimizing memory access can work wonders.
(Or at least add new features specifically for you to adopt.)
Wouldn't Intel be the one defining the intrinsics? They're referenced from the ISA manuals, and the Intel Intrinsics Guide regularly references intrinsics like _allow_cpu_features() that are only supported by the Intel compiler and aren't implemented in MSVC.
The few chapters I saw seemed to be pretty generic intro to assembly language type stuff.
The bigger issue is instruction ordering and register allocation. On code where the compiler effectively has to lower serially-dependent small snippets independently, I think the compiler does a great job. However, when it comes to massive amounts of open code I'm shocked at how silly the decisions are that the compiler makes. I see super trivial optimizations available at a glance. Things like spilling x and y to memory, just so it can read them both in to do an AND, and spill it again. Constant re-use is unfortunately super easy to break: Often just changing the type in the IR makes it look different to the compiler. It also seems unable to merge partially poisoned (undefined) constants with other constants that are the same in all the defined portions. Even when you write the code in such a way where you use the same constant twice to get around the issue, it will give you two separate constants instead.
I hope we can fix these sorts of things in compilers. This is just my experience. Let me know if I left anything out.
God bless you, ffmpeg.
cr125rider•5mo ago
prisenco•5mo ago
Imagine all projects were similarly committed.
byteknight•5mo ago
ackfoobar•5mo ago
lo_zamoyski•5mo ago
imchillyb•5mo ago
Once the competition fails, the value extraction process can begin. This is where the toxicity of our city begins to manifest. Once there is no competition remaining we can begin eating seeds as a pastime activity.
The toxicity of our city; our city. How do you own the world? Disorder.
Disorder…
godelski•5mo ago
https://x.com/FFmpeg/status/1775178803129602500
https://x.com/FFmpeg/status/1856078171017281691
https://x.com/FFmpeg/status/1950227075576823817
Oh, and here's one making fun of HN comments. Hi ffmpeg :) https://x.com/FFmpeg/status/1947076489880486131
hdgvhicv•5mo ago
hluska•5mo ago
astrange•5mo ago
ffmpeg was however, always the best open-source project, basically because it had all the smart developers who were capable of collaborating on anything. Its competition either wasn't smart enough and got lost in useless architecture-astronauting[2], or were too contrarian and refused to believe their encoder quality could get better because they designed it based on artificial PSNR benchmarks instead of actually watching the output.
[0] For complicated reasons I don't fully understand myself, audio encoders don't get quality improvements by sharing code or developers the way decoders do. Basically because they use something called "psychoacoustic models" which are always designed for the specific codec instead of generalized. It might just be that noone's invented a way to do it yet.
[1] I eventually fixed this by writing a new multithreading system, but it took me ~2 years of working off summer of code grants, because this was before there was much commercial interest in it.
[2] This seems to happen whenever I see anyone try to write anything in C++. They just spend all day figuring out how to connect things to other things and never write the part that does anything?
godelski•5mo ago
astrange•5mo ago
I was thinking about two types of people; one gets distracted and starts writing their own UI framework and standard library and never gets back to the program. The other starts writing a super-flexible plugin system for everything because they're overly concerned with developing a community to the point they don't want to actually implement anything themselves.
(In this space the first was a few different mplayer forks and the second was gstreamer.)
godelski•5mo ago
I'm pretty sure there are a lot more types and the two you wrote aren't the copy-pasters either. Me, I try to follow the Unix philosophy[0] though I think there's plenty of exceptions to be made. Basically just write a bunch of functions and make your functions simple. Function overhead calls are usually cheap so this allows things to be very flexible. Because the biggest lesson I've learned is that the software is going to change so it is best to write with this in mind. The best laid plans of mice and men and all I guess. So write for today but don't forget about tomorrow.
Then of course there are those that love abstractions, those that optimize needlessly, and many others. But I do feel the copy-pasters are the most common type these days.
[0] https://en.wikipedia.org/wiki/Unix_philosophy
skeaker•5mo ago
Almondsetat•5mo ago
EliRivers•5mo ago
6SixTy•5mo ago
oguz-ismail•5mo ago
Any concrete examples where we can see the code?
6SixTy•5mo ago
EliRivers•5mo ago
pjc50•5mo ago
lo_zamoyski•5mo ago
Programming is a small piece of a larger context. What makes a program "good" is not a property of the program itself, but measured by external ends and constraints. This is true of all technology. Some of these constraints are resources, and one of these resources is time. In fact, the very same limitation on time that motivates the prioritization of development effort toward some features other than performance is the very same limitation that motivates the desire for performance in the first place.
Performance must be understood globally. Let's say we need a result in three days, and it takes two days to write a program that takes one day to get the result, but a week to write a program that takes a second to produce a result, then obviously, it is better to write the program the first way. In a week's time, your fast program will no longer be needed! The value of the result will have expired.
This is effectively a matter of opportunity cost.
godelski•5mo ago
Sesse__•5mo ago
ronsor•5mo ago
To be fair, this is because they mostly care about serving ads. Without the ads, the pages are often fine.
Sesse__•5mo ago
phalanx104•5mo ago
fkyoureadthedoc•5mo ago
godelski•5mo ago
People argue "sure, it's not optimal, but it's good enough". But that compounds. A little slower each time. A little slower each application. You test on your VM only running your program.
But all of this forgets what makes software so powerful AND profitable: scale. Since we always need to talk monetary value, let's do that. Shaving off a second isn't much if it's one person or one time but even with a thousand users that's over 15 minutes, per usage. I mean we're talking about a world where American Airlines talks about saving $40k/yr by removing an olive and we don't want to provide that same, or more(!), value to our customers? Let's say your employee costs $100k/yr and they use that program once a day. That's 260 seconds or just under 5 minutes. Nothing, right? A measly $4. But say you have a million users. Now that's $4 million!
Now, play a fun game with me. Just go about your day as normal but pay attention to all those little speedbumps. Count them as $1m/s and let me know what you got. We're being pretty conservative here as your employee costs a lot more than their salary (2-3x) and we're ignoring slowdown being disruptive and breaking flow. But I'm willing to bet in a typical day you'll get on the order of hundreds of millions ($100m is <2 minutes).
We solve big problems by breaking them into a bunch of smaller problems, so don't forget that those small problems add up. It's true even if you don't know what big problem you're solving.
Capricorn2481•5mo ago
Then you agree with the poster. Performance critical software should focus on performance.
godelski•5mo ago
Fuck this "we don't need to optimize" bullshit. Fuck this "minimum viable product" bullshit. It's just a race to the bottom. No one paper cut is the cause of death, but all of them are when you have a thousand.
andrekandre•5mo ago
ironically, sometimes its the reactions to big issues that cause paper-cuts to flourish (aka red-tape, incident mitigation, rushing to deadlines, "temporary" bug fixes piling up etc etc)
godelski•5mo ago
brookst•5mo ago
Users want to load and edit PDFs. Finnish has been rendering right to left for months, but the easy fix will break Hebrew. The engineers say a new rendering engine is critical or these things will just get worse. Sales team says they’re blocked on a significant contract because the version tracking system allows unaudited “clear history” operations. Reddit is going berserk because the icon you used (and paid for!) for the new “illuminated text mode” turns out to be stolen from a Lithuanian sports team.
Knowing that most of your users only start the app when their OS forces a reboot… just how much priority does startup time get?
jntun•5mo ago
hugo1789•5mo ago
On my Laptop where I am forced by my company to run windows, I run word 2010 and it runs far better(speed and stability) that the newest word I have to use ob my office pc.
windward•5mo ago
Part of getting this to happen is setting the right culture and incentives. PM is such a nebulous term that I can't say this definitively, but I don't think the responsibility for this lies with them. Some poor performance is simply tech debt and should be tackled in the same way.
$WORD_PROCESSOR employees should be capable of this: we've all seen how they interview.
not_your_vase•5mo ago
fkyoureadthedoc•5mo ago
dwringer•5mo ago
kiwijamo•5mo ago
robinsonb5•5mo ago
But I also have a Core 2 Duo-based WinXP machine in easy reach (just to keep a legacy software environment alive) and its keyboard has a dedicated calculator button. The calculator is just there the moment I press that button - it's appeared long before I can even release the button.
fkyoureadthedoc•5mo ago
I definitely got the stupid hourglass in win 95 when trying to open anything, but my understanding of computers at the time was that black ones were faster than beige ones, so my computer was probably shit.
I tried to look up calculator win 95 vids on YouTube, there are a couple. One gets an hourglass - but less than a second, one is instant, one shows the calculator crashing lol.
During this I also found out that Microsoft Calculator is open source: https://github.com/microsoft/calculator
adolph•5mo ago
const_cast•5mo ago
The reality is that non-performant apps aren't non-performant because they're doing so many cool things. No, that compute is wasted. The digital equivalent of pushing a box up a hill then back down 1000 times.
I mean, the types of performance issues I've seen is like: grab 100,000 records from the database, throw away 99,900, return 100 to the front end.
Optimizing that saves orders of magnitude of time but the thing does the same thing. Like we're just being wasteful and stupid. Those records we throw away aren't being used for some super cool AI powered feature. Its just waste.
therealmarv•5mo ago
sfn42•5mo ago
Sadly lots of software is blatantly wasteful. But it doesn't take fancy assembly micro optimization to fix it, the problem is typically much higher level than that. It's more like serialized network requests, unnecessarily high time complexities, just lots of unnecessary work and unnecessary waiting.
Once you have that stuff solved you can start looking at lower level optimization, but by that point most apps are already nice and snappy so there's no reason to optimize further.
harikb•5mo ago
sfn42•5mo ago
pjmlp•5mo ago
godelski•5mo ago
But to anyone complaining, I want to know, when was the last you pulled out a profiler? When was the last time you saw anyone use a profiler?
People asking for performance aren't pissed you didn't write Microsoft Word in assembly we're pissed it takes 10 seconds to open a fucking text editor.
I literally timed it on my M2 Air. 8s to open and another 1s to get a blank document. Meanwhile it took (neo)vim 0.1s and it's so fast I can't click my stopwatch fast enough to properly time it. And I'm not going to bother checking because the race isn't even close.
I'm (we're) not pissed that the code isn't optional, I'm pissed because it's slower than dialup. So take that Knuth quote you love about optimization and do what he actually suggested. Grab a fucking profiler, it is more important than your Big O
nwallin•5mo ago
The enterprising hacker then wrote a simple binary patch that reduced the startup time from 5-10 minutes to like 15 seconds or something.
To me that's profound. It implies that not only was management not concerned about the start up time, but none of the developers of the project ever used a profiler. You could just glance at a flamegraph of it, see that it was a single enormous plateau of a function that should honestly be pretty fast, and anyone with an ounce of curiousity would be like, ".........wait a minute, that's weird." And then the bug would be fixed in less time than it would take to convince management that it was worth prioritizing.
It disturbs me to think that this is the kind of world we live in. Where people lack such basic curiosity. The problem wasn't that optimization was hard, (optimization can be extremely hard) it was just because nobody gave a shit and nobody was even remotely curious about bad performance. They just accepted bad performance as if that's just the way the world is.
[0] Oh god it was 4 years ago: https://nee.lv/2021/02/28/How-I-cut-GTA-Online-loading-times...
godelski•5mo ago
How is it that these companies spend millions of dollars to develop games and yet modders are making patches in a few hours fixing bugs that never get merged. Not some indie game, but AAA rated games!
I think you're right, it's on both management and the programmers. Management only knows how to rush but not what to rush. The programmers fall for the trap (afraid to push back) and never pull up a profiler. Maybe over worked and over stressed but those problems never get solved if no one speaks up and everyone is quiet and buys into the rush for rushing's sake mentality.
It's amazing how many problems could be avoided by pulling up a profiler or analysis tool (like Valgrind).
It's amazing how many millions of dollars are lost because no one ever used a profiler or analysis tool.
I'll never understand how their love for money makes them waste so much of it.
bigstrat2003•5mo ago
godelski•5mo ago
I'm just wondering if/when anyone will realize that often desire gets in the way of achieving. ̶T̶h̶e̶y̶ ̶m̶a̶y̶ ̶b̶e̶ ̶p̶e̶n̶n̶y̶ ̶w̶i̶s̶e̶ ̶b̶u̶t̶ ̶t̶h̶e̶y̶'̶r̶e̶ ̶p̶o̶u̶n̶d̶ ̶f̶o̶o̶l̶i̶s̶h̶.̶ Chasing pennies with dollars
pjmlp•5mo ago
Back then, the indies stuff was only if you happened to live nearby someone you knew doing bedroom coding, distributing tapes on school, or they got lucky land their game on one of those shareware tapes collection.
Trying to actually get a publisher deal was really painful, and if you did, they really wanted their money back in sales.
versteegen•5mo ago
pjmlp•5mo ago
There are tons of games that you can fit into 60m, 90m, or 180m tapes, when 48 KB/128 KB is all you got.
More like 20 or something.
Magazines like Your Sinclair and Crash would have such cassete tapes,
https://archive.org/details/YourSinclair37Jan89/YourSinclair...
https://www.crashonline.org.uk/
They would be glued into the magazine with adhesive tape, and later on to avoid them being stolen, the whole magazine plus tape would be in a plastic.
skeaker•5mo ago
tinyhitman•5mo ago
p_l•5mo ago
It slowed down gradually as the JSON manifest of optional content grew.
bakugo•5mo ago
Odds are that someone did notice it during profiling and filed a ticket with the relevant team to have it fixed, which was then set to low priority because implementing the latest batch of microtransactions was more important.
I feel like this is just a natural consequence of the metrics-driven development that is so prevalent in large businesses nowadays. Management has the numbers showing them how much money they make every time they add a new microtransaction, but they don't have numbers showing them how much money they're losing due to people getting tired of waiting 15 minutes for the game to load, so the latter is simply not acknowledged as a problem.
Sophira•5mo ago
I don't know if it's still applicable or not because I haven't played it for ages, but just in case it is, here's the post: https://www.reddit.com/r/GTAV/comments/3ysv1d/pc_slow_rsc_au...
LarMachinarum•5mo ago
I see what you did there ;)
Ygg2•5mo ago
I see this is a datapoint, but not for your argument. This thing sat in the code base didn't cause problems and didn't affect sales of the game pre or post GTAO launch.
This sounds a lot like selection bias. You want to enhance airplanes that flew and returned. Rather than those that didn't come back.
Let's say they did the opposite and focused on improving this over a feature or a level from GTA. What level or what feature that you liked could you remove to make way for investigating and fixing this issue? Because at the end of the day - time is zero-sum. Everything you do comes at the expense of everything you didn't.
pjc50•5mo ago
(which makes it all the more strange that it wasn't fixed)
Ygg2•5mo ago
Is it? It didn't become noticable until GTA got a bunch of DLCs.
Sure someone might have spotted it. But it would take more time to spot it early, and that time is time not spent fixing bugs.
godelski•5mo ago
But what's much harder to measure is the number of sales you missed. Or where the downed planes were hit. You don't have the downed planes, you can't see where they were hit! You just can't have that measurement, you can only infer the data through the survivors.
Time is a weird thing. It definitely isn't zero sum. There's an old saying from tradesmen "why is there always time to do things twice but never time to do things right?" Time is made. Sometimes spending less time gives you more time. And all sorts of other weird things. But don't make the classic mistake of rushing needlessly.Time is only one part of the equation and just like the body the mind has stamina. Any physical trainer would tell you you're going to get hurt if you just keep working one group of muscles and keep lifting just below your limit. It's silly that the idea is that we'd go from sprint to sprint. The game industry is well known to be abusive of its developers, and that's already considering the baseline developer isn't a great place to start from, even if normalized.
Ygg2•5mo ago
Not really. There are about 300 million gamers [1] if you exclude Androids and iPhones. How many sales units did GTA V make? 215 million[2]. It's a meteoric hit. They missed a sliver (35%) of their target audience.
You could argue that they missed the mobile market. But the biggest market - Android is a pain to develop for; the minimum spec for GTA V to have parity on phones would exclude a large part of the market (most likely), and the game itself isn't really mobile-friendly.
Ok, but we have a counter example (pun intended). Counter-Strike. Similarly, multiplayer, targets PCs mostly, developed by Valve, similarly excellent and popular to boot. However, it's way faster and way better optimized. So how much it "sold" according to [3]? 70 million. 86 if you consider Half-Life 1 and 2 as its single player campaign.
I'm not sure what the deciding factor for people is, but I can say it's not performance.
> Time is a weird thing. It definitely isn't zero sum.
If you are doing thing X, you can't do another thing Y, unless you are multitasking (if you are a time traveler, beware of paradoxes). But then you are doing two things poorly, and even then, if you do X and Y, adding other tasks becomes next to impossible.
It definitely is. Tim Cain had a video[4] about how they spent man months trying to find a cause for a weird foot sliding bug, that's barely noticeable, which they managed so solve. And at that time Diablo came out and it was a massive success with foot sliding up the wazoo. So, just because it bugs you doesn't mean others will notice.
> "why is there always time to do things twice but never time to do things right?"
Because you're always operating with some false assumption. You can't do it right, because the right isn't fixed and isn't always known, nor is it specified right for whom?
[1]https://www.pocketgamer.biz/92-of-gamers-are-exclusively-usi...
[2]https://web.archive.org/web/20250516021052/https://venturebe...
[3]https://vgsales.fandom.com/wiki/Counter-Strike
[4]https://youtu.be/gKEIE47vN9Y?t=651
godelski•5mo ago
Honestly, there's no point in trying to argue with you. Either you're trolling, you're greatly disconnected from reality, or you think I'm brain dead. No good can come from a conversation with someone that is so incorrigible.
Ygg2•5mo ago
Fine, I'll concede it's the wrong word used. But:
> Honestly, there's no point in trying to argue with you. Either you're trolling, you're greatly disconnected from reality
Wait. I'm disconnected? Selling millions of unit (Half life) is amazing success and tens of millions is stellar success by any measure (Baldur's Gate, Call of Duty, Skyrim). But selling hundreds of millions (Minecraft, GTAV)? That's top 10 most popular game of all time.
So according to you, one of the top 5 best-selling game in history is somehow missing a huge part of the market? You can argue a plethora of things, but you can't speculate that GTA V could have done much better by saying "you're trolling"/"no point arguing".
And saying that optimizing the DLC JSON loader could have given them a bigger slice of the pie is incredulous at best.
You're extrapolating your preferences to 6 billion people. It's like watching a designer assume everyone will notice they used soft kerning, with dark grey font color on a fishbone paper background for their website. And that they cleverly aligned the watermark with the menu elements.
mschuster91•5mo ago
The problem is, you don't get rewarded for curiosity, for digging down into problem heaps, or for straying out of line. To the contrary, you'll often enough get punished for not fulfilling your quota.
1vuio0pswjnm7•5mo ago
I bet it opens faster on a Surface Pro
justsid•5mo ago
1vuio0pswjnm7•5mo ago
godelski•5mo ago
But the god damn program is over 2GB in size... like what the fuck... There's no reason for an app I open a few times a year and have zero plugins and ONLY does text editing should even be a gig.
Seriously, get some context before you act high and mighty.
I don't know how anyone can look at Word and think it is anything but the accumulation of bloat and tech debt piling up. With decades of "it's good enough" compounding and shifting the bar lower as time goes on.
versteegen•5mo ago
sintax•5mo ago
fkyoureadthedoc•5mo ago
godelski•5mo ago
Just because people use it doesn't mean they want to use it. We're in a bubble here and most people are pretty tech illiterate. Most people don't even know there are other options.
Besides, it also misses a lot. Like how there's a lot of people that use Google Docs. Probably the only alternative an average person is aware of. But in the scientific/academic community nearly everyone uses LaTeX. They might bemoan and complain but there's a reason they're using it over Word and TeX isn't 2.5GB...
1vuio0pswjnm7•5mo ago
For reading, editing, creating Word documents, the TextMaker Android app seems to work. Size of recent version I tried was 111MB, startup is quick. Paid features are non-essential IMHO.
https://www.softmaker.net/down/tm2024manual_en.pdf
A personal favourite program for me is spitbol, a SNOBOL interpreter written in a portable assembly language^3 called MINIMAL. I'm using a 779k static binary. SNOBOL is referenced here:
1. https://borretti.me/article/you-can-choose-tools-that-make-y...
The Almquist shell is another favourite of mine. It's both the "UI" and the language I use everyday to get stuff done on the computer. Like Microsoft Word makes some HN commenters unhappy, it seems that the UNIX shell makes some "developers" unhappy.^2
But the shell is everywhere and it is not going away.
IME, old software from an era before so-called "tech" companies funded by VC and "ad services", still works and I like it. For example, sed is still the favourite editor for me despite its limitations, and it is close to the shell in terms of ubiquity. Following current trends requires devoting more and more storage, memory and CPU in order to wait for today's programs to compile, start, or "update". As a hobbyist who generally ignores the trends I am experiencing no such resource drains and delays.
For every rare software user complaining about bloat, there is at the same time a "developer", e.g., maybe one writing a Javascript engine for a massive web browser controlled by an advertising company, who is complaining about the UNIX shell.
Developers like to frame software as a popularity contest. The most popular software is declared to have "won". (Not sure what that means about all the other software. Maybe not all software authors are interested in this contest.) To me, ubiquity is more important than "popularity":
2. https://borretti.me//article/shells-are-two-things
"There are 5,635 shell scripts on my humble Ubuntu box."
This makes me happy.
On Linux, I use vim 4.6 from 1997, a 541k static-pie binary. I use ired, bvi and toybox hexedit as hex editors, 62k, 324k and 779k static-pie binaries, respectively. If I dislike something I can change it in the source code. If I find other software I like better I can switch. No closed source and proprietary file formats like MS Word. The most entertaining aspect of the cult of Microsoft is that the company is so protective of software that it tells the public is "obsolete" or otherwise not worth using anymore, old versions of software or minimal versions that have few "features".
https://ftp.nluug.nl/pub/vim/unix/vim-4.6.tar.gz
https://codeload.github.com/radare/ired/zip/refs/heads/maste...
https://codeload.github.com/johnsonjh/bvi-lf/zip/refs/heads/...
https://www.landley.net/toybox/downloads/toybox-0.8.9.tar.gz
https://www.landley.net/toybox/downloads/binaries/latest/toy...
3. The topic of this thread is assembly language. Makes me happy
The appeal of smaller, faster software to me is not that this stuff is so _good_. It is that the alternatives, software like MS Word, is so _bad_.
1vuio0pswjnm7•5mo ago
https://codeload.github.com/blakemcbride/tecoc/zip/refs/head...
Also forgot to mention that TextMaker on Android contains networking code and will try to connect to the internet. This is can be blocked with Netguard app, GrapheneOS, netfilter/pf/etc. on a gateway controlled by the user, or whatever other solution for blocking connections that the user prefers.
AdieuToLogic•5mo ago
It could be worse I suppose...
Some versions of Microsoft Excel had a flight simulator embedded in them[0]!
:-D
0 - https://web.archive.org/web/20210326220319/https://eeggs.com...
saagarjha•5mo ago
tom_•5mo ago
First run since last reboot: 19 seconds
Second run: 2.5 seconds
Third run after sudo purge: 7 seconds
Maybe it's an artefact of where I live, but the verify step always takes ages. First run of anything after a reboot takes an outlandish amount of time. GUI stuff is bad; Unix-type subprocess-heavy stuff is even worse. Judging by watching the Xcode debugger try to attach to my own programs, when they are in this state, this is not obviously something the program itself is doing.
godelski•5mo ago
I went ahead and did another run and it was much faster. About 2 seconds. So things are definitely being cached. I did a trace on it (Instruments) and there's a lot of network activity. Double the time after sudo purge. There's 2 second of network time where the previous run only spent 1 second. Ran a tad faster when I turned the network off, though ended up using more CPU power.
FWIW, looks to be only using 4 of my 8 cores, all of which are performance cores. Also looks like it is fairly serialized as there's not high activation on any 2 cores at the same time. Like I'll see one core spike, drop, and then another core spike. If I'm reading the profiler right then those are belonging to the same subprocesses and just handing over to a different thread.
For comparison, I also ran on ghostty and then opened vim. Ghostty uses the performance cores but very low demand. vim calls the efficiency cores and I don't see anything hit above 25% and anytime there's a "spike" there's 2, appearing across 2 cores. Not to mention that ghostty is 53MB and nvim is more than a magnitude less. Compared to Word's 2.5GB...
I stand by my original statement. It's a fucking text editor and it should be nearly instantaneous. As in <1s cold start.
saagarjha•5mo ago
tengwar2•5mo ago
jmmv•5mo ago
This is exactly why I wrote https://jmmv.dev/2023/09/performance-is-not-big-o.html a few years back. The focus on Big O during interviews is, I think, harmful.
godelski•5mo ago
Those simplifications are harmful when you start thinking about parallel processing. There's things you might want to do that would look silly in serial process. O(2n) can be better than O(n) because you care about the actual functions. Let's say you have a loop and you do y[i] = f(x[i]) + g(x[i]). If f and g are heavy then you may want to split this out into two loops y[i] += f(x[i]) and y[i] += g(x[i]) since these are associative (so non-blocking).
Most of the work was really about I/O. Those were almost always the bottlenecks. Your Big O won't help there. You gotta write things with awareness about where in memory it is and what kind of memory is being used. All about how you break things apart, operate in parallel, and what you can run asynchronously.
Honestly, I think a big problem these days is that we still operate as if a computer has 1 CPU and only one location for memory.
mjevans•5mo ago
Why do they ask about Big O? Because it works as a filter. That's how bad some of the candidates are.
What would I rather they do? Have a non-trivial but obviously business unrelated puzzle that happens to include design flaws and the interviewee is given enough time and latitude to 'fulfill the interface, but make this the best it can be'.
genewitch•5mo ago
i've managed to track down powershell in windows terminal taking forever to fully launch down to "100% gpu usage in the powershell process", but i'd really like to know what it thinks it's doing.
also: 4 seconds to blank document in Word. the splash screen is most of that. notepad++ ~2 seconds. notepad.exe slightly over 1 second before the text content loads. Edge: 2 seconds to page render from startup. Oh and powershell loads instantly if i switch to the "old" terminal, but the old terminal doesn't have tabs, so that's a non-starter. "forever" above means 45-60 seconds.
p_l•5mo ago
tekknik•5mo ago
or put another way, if you care about text editor performance, or are hyper focused on performance in all cases, you miss the point of software development
motorest•5mo ago
How many projects would have anything to benefit from this focus on optimization, though?
There is a reason why the first rule of optimization is "don't do it", and the second (experts only) is "don't do it yet".
lmm•5mo ago
zahlman•5mo ago
codys•5mo ago
They publish doxygen generated documentation for the APIs, available here: https://ffmpeg.org/doxygen/trunk/
zahlman•5mo ago
javier2•5mo ago
astrange•5mo ago
Wowfunhappy•5mo ago
f1shy•5mo ago
1718627440•5mo ago
kaladin-jasnah•5mo ago
ansk•5mo ago
* To be more precise, these are bindings for the libav* libraries that underlie ffmpeg
xxpor•5mo ago
gooob•5mo ago
alfg•5mo ago
dlcarrier•5mo ago
harry8•5mo ago
Ffmpeg runs on a load of server farms for all your favourite streaming services and the bajillion more you’ve never heard of. Saving compute there saves machines and power.
Your point is well taken but there is a distinction that matters some.
kasabali•5mo ago
harry8•5mo ago
I’m in no way defending electron. It’s just not taking back the power and machines saved by ffmpeg. Which is a happy accident that’s nice. Restart your electron hate all you want.
kasabali•5mo ago
I don't know about you, but everyone else sure does. Minimum requirements (even though not told explicitly anymore) has been constantly increasing.
harry8•5mo ago
Apple stopping support for security upgrades is the issue requiring a phone to stop being used, by you or the 2nd hand recipient. Same issue for the various android vendors.
That sure won't change if your phone uses a little less battery decoding movies and your battery use will still be dominated by screen use.
dlcarrier•5mo ago
I've had some instability using PyTorch on my desktop computer, that only appeared if I was using the computer. I just a few minutes ago discovered what the problem was, because while running a calculation I opened FreeTube, a YouTube interface that runs in an Electron instance, and my computer immediately restarted. Apparently 8 cores, 96 MB of cache, 32 GB of system RAM, and 16 GB of VRAM doesn't leave enough unused capacity for one more web browser instance.
I've helped multiple people figure out that their games were getting latency spikes because of the resources used by chat applications running on Electron or similar, which no amount of RAM or processing power seems to fix.
Besides the opertunity cost of the resources that extremely inneficient applications use making the computer much less useful for other tasks, power consumption itself can matter a lot. Sure, using more power on a desktop computer may only cost a fraction of a cent per day, but on laptops, tablets, and phones that don't have user replacable batteries, which is pretty much every one in production, every percent power using increase not only wares the battery the same percentage faster, which proportionally reduces the useful life of the device, but it reduces how long the device is usable between charges, requring topping off and reducing usability and reliability.
Also, running ICQ on a 90's computer with a mechanical hard drive was far more responsive than running Slack or Discord on the fastest computer you can buy today today. I can guaruntee you that switching from an Electron/HTML/CSS/JavaScript/WhateverJavaScriptFramework stack to a C/GTK or similar stack will not only reduce resource consumption by an order of magnitude or two, increase security, and make the codebase simpler and easier to mantain, it will also be much, much more responsive.