Hacker News new | ask | show | jobs
by oldmanjay 3993 days ago
I think you're incorrect and remembering performance that never existed based on shortcomings you glossed over at the time because you have that all too human bias of believing that things were better when you were younger.
2 comments

There is so many low hanging fruit in software design that is simply there because of legacy design trade-offs and the cost associated with replacing those - we could gain huge performance gains over night if we for eg. eliminated reliance on hardware memory protection and context switching from kernel space to user space by using languages that can prove memory safety in software.

Then imagine how much performance you could get out of OS level VMs that understand the processes at VM level (ie. can access code in some IR that they can analyze easily, recompile it on the fly, etc.) there is already stuff like this in specialized markets (eg. kernel level GC for JVM) but it's still fairly specific.

Then there's all the shitty legacy abstraction layers in things like filesystems - ZFS is a perfect example of what kind of gains you can get for free if you just rethink the design decisions behind current stack and see what applies and what doesn't.

If the benefit of rewriting these systems ever overcomes the cost - we have huge potential areas for performance gains, modern systems are very far from being performance efficient, they are efficient based on various other factors (development cost, compatibility, etc.)

I wish Linux would just merge a ZFS implementation into the kernel already.

I also wish ZFS would grow an encryption layer (one that isn't based on Sunacle's implementation, since Sunacle doesn't want to share that one thus no one can use it).

I understand what you're saying, but do you really think most of a modern Android (to take the theme to its Javaesque extreme) stack is the most efficient way to accomplish processing?

Compare that to some of the code people ran through 6502-derivatives.

Abstraction may be more efficient in terms of programmer time, and performance efficiency may be high enough so as to be immaterial, but the two shouldn't be conflated.

> do you really think most of a modern Android (to take the theme to its Javaesque extreme) stack is the most efficient way to accomplish processing?

Reminds me of a version of this image[1] which has a discussion superimposed over it that says, "but if he had a big enough pile of ladders he could get over the wall!" and someone responds, "welcome to Android optimization." I think we see something similar with Javascript performance.

[1] http://i.imgur.com/AWG7LqR.jpg

Ha! That's the first non- https://interfacelift.com/ image I've put as my background for a while.

The older I get, the more I start seeing over-complexity in stacks as a security risk as well. I feel like there's a fundamental maximum to the number of levels of abstraction one can keep in one's head "enough" to avoid creating layer interaction bugs. Stack overflow, indeed. :)