Give the demo a try. I compared the CPU usage to the win10 file explorer, and they look identical (both are minuscule); it's super impressive.
264 karma · joined December 10, 2021
I feel the same way. I am not sure what performance comparisons have been made between the two projects, but I stick with vanilla vim (gVim typically) over vanilla nvim due to the responsiveness.
Ultimately, I find the thesis of the paper fundamentally wrong for presuming that OOP is somehow more beneficial than other approaches to dynamic dispatch. Moreover, the use of interfaces in thr paper are more restrictive to code structure, and in turn, are more likely hurt code reuse than help it.
Interfaces are an inherently weaker form of the age old Operation Code and data packet paradigm. Take the Widget interface the paper gives as an example (page 5). This interface has now been set in stone. Any additions that would be useful for the widget interface, say OnClick(), will require a breaking change. This is because all code using the old interface will have to be updated and recompiled to satisfy the new interface requirements (even if a widget won't functionally change from using said new interface). Meanwhile for code using op codes, a new op code value is defined and nothing in the old code is required to change. (This assumes that this old code will perform a no operation for the new opcode, which historically has been the case for systems that use this method).
In fact, Win32 did exactly this opcode and data packet protocol for its message loop to great long term success. They have regularly extended their existing code without breaking backwards compatibility of older versions. The longevity of code in typical OO systems pales in comparison.
[0] https://harmful.cat-v.org/software/OO_programming/why_oo_suc... [1] http://stlport.org/resources/StepanovUSA.html
In principle, I want this to be true. But, in practice, I think products change because the teams that built a product need to justify their continued existence within a corporation. Slack's last few rounds of UI changes for instance, has been a net negative for me, the user. Why can't I split several channels in the same window anymore? Why did they add a thick vertical toolbar that I don't use and can't remove? Not for my benefit, that's for sure.
p.s. Kelley not Kelly is the correct spelling of his name.
I'm not aware of any architecture books recommended by anyone that cares about performance unfortunately. Most high performance software is written iteratively, meaning they aren't assuming a code structure from the start. Andreas Fredriksson, a lead engine programmer at Insomniac Games, has an excellent quote on how he writes high performance software[2]:
> Work backwards from hard constraints and requirements to guide your design. Don’t fall into the trap of designing from a fluffy API frontend before you’ve worked out how the thing will handle a worst case. Don’t be afraid to sketch stuff in while you’re proving out the approach.
> The value is what you learn, never the code. Hack it and then delete the code and implement “clean” or whatever you need. But never start there, it gets in the way of real engineering.
> As an industry we spend millions on APIs, documentation and abstraction wrapping a thing that isn’t very good to start with. Make the thing good first, then worry about fluff.
Casey Muratori also has written blogs about his programming style[3]. (He also runs a great course about performance at computerenhance.com). Abner Coimbre has a great article on how NASA approaches writing software[4]. Of course, there is also Mike Acton's famous CppCon talk about Data-Oriented Design[5].
The standard advice usually boils down to this: focus on the problem you have to solve, and be aware how damaging solving the wrong problem can be. It's a good idea to focus on what data your program receives and focusing on handling worst cases.
Since it is difficult to tell who is worth listening to, I suggest always investigating what actual software the person speaking has written. Those that write real time software or software that must not fail under any condition tend to speak very differently about typical industry practices for good reason.
[0] https://youtu.be/tD5NrevFtbU?si=Jkg6VKBHns32_IU_
[1] https://youtu.be/ZQ5_u8Lgvyk?si=tMuPFxKbrboKrBFr
[2] https://twitter.com/deplinenoise/status/1782133063725826545
[3] https://caseymuratori.com/blog_0015
[4] https://www.codementor.io/@abnercoimbre/a-look-into-nasa-s-c...
[0] https://lemire.me/blog/2021/09/25/new-release-of-the-simdjso...
> I'm not sure why this is particularly needed and it isn't really in the novel...
I know saying this is sacrilegious to some sci-fi fans, but I think that the novel, Dune, could do with improvement. Neither the book nor the movie spend enough time fleshing out the details of their characters, which in my opinion robs both of them their ability to connect more deeply with the audience. The scene where Duke Leto explains to Paul that they will require desert power to rule Arrakis, for instance, did not have to be set such that the characters were alone on an empty cliff above the shoreline. There could have been a city full of culture upon this shoreline with great boat yards and planes over the sea to show the audience the empire that they are leaving behind on Caladan. I want both the novel and the movie to flesh out the details which make the audience engage with the fact that Caladan is a comparative paradise to the harsh, prison-like planet called Arrakis. It would suck to be forced to leave behind all the great work that the Atreides' forefathers put into Caladan. But, ultimately, both the film and the novel fail to fully engage their audience with these facts since they don't flesh out the details about the environment and people that the Atreides rule. At least that is my opinion.
There are a number of things I'd like to change or improve upon if I had the chance to edit Dune (novel or film): the story's allusions to the Cold War fight for oil in the middle east; the poor decision making by the Harkonnens; Dr. Yueh's murder of Duke Leto etc. But I don't want to ramble on too much. My point is that I think the film could have improved upon the novel in a number of places, instead of following the novel to its detriment.
I totally agree with this take, but I think Dennis' directing/writing is full of 'Telling' instead of 'Showing', not that he took "Show Don't Tell" to the extreme. The entire movie is full of instances where the audience is told aspects of the characters/world, but isn't shown them in the first Dune movie:
- We are told the Atreides ruled Caladan, but at no point is the audience shown who the Atreides' subjects are, or how their subjects feel about the Atreides. The only shots the film has on Caladan are beautiful yet empty areas of the Scottish Highlands. Where are the people they rule over? What does their way of life look like? None of this is shown, but it should have been.
- On Arrakis, we are only ever told how strong and powerful the Fremen are from characters like Duncan Idaho. In fact, the only time we get to see the Fremen fight is at the end of the movie when Paul, the child _who has never been in a life or death fight before_, makes a fool of a supposedly strong Fremen fighter! Dennis clearly wants the audience to perceive the Fremen as strong, yet he fails to illustrate their strength on screen. I understand that Dennis wants Paul to be seen as powerful too, but the resulting scene undercuts everything that the movie has told us about the Fremen's fighting ability.
If it isn't already clear, I don't think Dennis Villenueve is a particularly good film maker (though this is not to call him a bad one). He likes to have large empty scenery shots which are almost monochrome. I find that it makes his imagery striking but, ultimately, boring. For instance, his shots in Bladerunner 2049 mostly depict an empty wasteland that, though striking in its scale, doesn't drive one's imagination. The original Bladerunner's shots are so cluttered with detail and color that it fills every location with a unique character. This is why I think Bladerunner inspired so much other media after it; the audience's imagination can't help but linger on the sets and one off characters of the original film.
I hope the education system pushes for more students in under represented groups to partake in advanced offerings instead of getting rid of them. In my ideal, the school system should strive to help all students push their intellectual ability. Moreover, school sports and extracurriculars are great places to push for greater diversity since they tend to lack under represented groups.
Maybe it would be lower relative to other people's rates, but one must imagine that any insurance prices will only ever cost more to the consumer.
[0] https://andrewkelley.me/post/zig-cc-powerful-drop-in-replace...
Personally, I don't see this as a problem. I like implementing an interface in Zig the same way I implement one in C -- I use a function pointer that takes a packet that defines the operation to execute with that packet data. Zig's exhaustive switch statements make these even better to work with.
Here is some pseudocode to illustrate what I mean:
fn doThing(ThingPacket p) switch(p.Opcode) MyInterfaceFunc1_Opcode => return MyInterfaceFunc1(p.Func1Params); MyInterfaceFunc2_Opcode => return MyInterfaceFunc2(p.Func2Param); ... default => error.InvalidOpcode;
Can you cite a source/example for that? I cannot imagine an optimized C program that doesn't blow python with numpy out of the water. Even a poorly written C program is likely to be 2x faster simply because it doesn't have to round trip operations from C to python and back.
Inheritance hierarchies aren't exclusively what he meant though. Interfaces and the whole 'prefer composition over inheritance' style of programming has the same fundamental problem Muratori is getting at: both inherently constrain a program's structure for, what he argues (and I agree with), has no benefit to the program's performance or the programmer's time. In fact, he argues that the constraints imposed by the use of inheritance/interfaces only slow programmers down.
His raw device driver example, in pt2 of their conversation, illustrates the advantage of procedural code over inheritance/interfaces. His API requires users to provide a function pointer that will be called whenever an event is raised. This API user is expected to switch over the enum values that they care to implement. This design is better than an interface that requires its members to implement read(), and write() functions because it is both more performant (no vtable overhead + compilers can make more aggressive optimizations) and more flexible (a new event can be added to the enum without requiring all the old code to be updated if they don't need to handle the new event type).
Is there? I can't think of any examples that come to mind. Most indie devs I know that roll their own engine have no regrets. I am curious who comes to mind that says otherwise publicly?
Eh, I think most C programmers frustrations with UB stem from knowing that the C standard has fundamental flaws and modern compilers abuse that fact for "optimizations" on UB. This paper covers the topic pretty well[0].
I fully support Casey Muratori's viewpoint that undefined behavior should not exist in the standard[1]. Instead, the C standard should enumerate all valid behaviors compliant compilers can implement. This would allow compilers to make unintuitive optimizations for the platforms that need them, but still allow programmers to be certain that their program semantics will not change in different versions of the said compiler.
[0] https://www.complang.tuwien.ac.at/kps2015/proceedings/KPS_20... [1] https://youtu.be/dyI0CwK386E?si=vsqJ8uWHY8xkGmFm
Consider the case of requesting a webpage with hundreds of small images, one should embed all of the images into the single webpage! Requiring each image to be fetched in a different http request is ridiculous. It pains me to look at the network tab of modern websites.
> I still use MSVC 6 (1998) as my IDE because it has better human factors for me than later versions of MSVC.
This is really amusing to me. Does anyone know if the author has ever given more detail on why?
Also stb is a really great library to look at for those starting C development.