If you could make a phone that has a couple of thousands time more battery life with the same functionality offered by today's phones you would most probably sell a lot. But I suspect you do not have any clue what you are talking about.
Dysfunctional state of modern software
- Thread starter green.pixel
- Start date
If you could make a phone that has a couple of thousands time more battery life with the same functionality offered by today's phones you would most probably sell a lot. But I suspect you do not have any clue what you are talking about.
Nobody can make that phone right now, there are years of work into the tech we ha e right now. But taking the necessary steps to approach that phone is becoming more and more necessary each day. There just hasn't been enough pressure to tip the industry in that direction just yet, but awareness about this can be what helps build that pressure.
You claimed that it was only software holding the battery life back ("if software was more tight and neat"). Everybody working on phone hardware and OS are working to improve battery life, but it is not an easy problem (like you claimed in the previous post).
Pure software is a large part of it certainly. But multiple layers of it. But I include in software the app, the APIs, the OS services and kernel, low level translation. When talking about hypotheticals like this, one could even include Processor microcode and firmware under a broad blanket of "software abstraction". When you include all that, there is a lot of redundant work and cascading bugs and workarounds to lower level bugs that generate more bugs further down the line. I understand why things are like that. Software and digital tech I'm general has evolved under an unbelievable pace during the last half century. But the industry as a whole has been sweeping problems under the rug and building hacks around it throughout the whole period and maybe time has come when it might be a good idea to start reconsidering this whole mess again.
Why this defensiveness? Non software devs can have lose opinions. I'm not demanding that the industry bend over to please me. I'm just saying there is a point in recognizing modern software is untenably messy.
tuna, what is the problem with pointing that out?
green.pixel
Veteran
Some bizarre variety of Stockholm syndrome.
You are not pointing anything out, you are just complaining about everything. If you would point something out you could say that Linux scheduler X causes is non-optimal and causes high input lag when there is high IO load. Preferably you would also measure it and be able to measure it again when things change. What has been done here is just general complaining that modern software is slow, which I just think is pointless whining.
The OP was not mine, it was from an actual developer. He has more posts, that go into specifics. I've read them, maybe you should too.
I'm just here saying what he points out is fair.
Sadly it is like that. Everything builds upon previous stuff that still needs to keep working. Browser needs to support 100 image, video, and audio formats, multiple script languages, dozens of fonts, thousands of other things. Same for OS. Sadly even the same for games: Old API still needs support, game must support Steam overlays and achievement tracking, loading updates in the background, keep connected to your buddy list... an endless pile of essential things, worth to spend one core just for all this crap they say.
The times of an Atari ST, which booted GUI OS just from ROM, never any updates... they are gone.
If the guy from the OP thinks it is necessary to have low latency text input he is likely wrong, and if he thinks he could write an 'efficient' browser by not relying on any pile of crap, i'd like to see that. He will end up with the same huge pile of bloat, if he ever succeeds to finish.
But if you don't like this (nobody does), then you could use something like Raspberry Pi. Likely the slickest device you can get in modern times? Not sure it if can run a neat OS other than Android, but if so you could write / use just the absolutely necessary software without any extra functionality. No FB of course, so you would not be happy with that either. At some point you would give up and admit there is no escape from all those requirements that modern software has to fulfill.
"I'm sure they could be multiple thousand times faster, if software was more tight and neat."
No, not that much. If i'd have to guess for a total average maybe a factor of 2 or 3 mostly, rarely 10. (pure guessing) But if you take the time to optimize the shit out of everything you never get anything done and finished stuff is outdated already.
There is also another motivation to keep selling new hardware before the old gen is maxed out, but this is not the reason for this inefficiency. The reason is simply growing functionality and necessary compromises - a net effect, not something everybody does wrong by intention.
If you would make a start up about a new computer system, with optimized OS and no bloat, it would be just a matter of time until you sit in the same boat as the others.
You can just run emacs directly in a linux framebuffer/terminal if you want to minimize latency and resources. I program like that sometimes. Otherwise you can run a really minimalistic window manager with no compositing etc. That usually feels really "snappy", but I haven't measured anything.
I was looking for an old pertinent Donald Knuth quote, when I came upon this blog post. It’s pretty good and relevant, and not written while (still) in an upset state.
I’ll contribute this though - back in the olden times algorithmic efficiency was mostly determined by analyzing number of (FL)OPS and time complexity O(n^whatever).
But at least during the last three decades, the art of writing efficient code has increasingly dealt with the memory hierarchy and data management. As CPUs have increased in performance, the latency, bandwidth and sizes of various stages in the memory hierarchy impose ever harder limits, and complexities springing from assumptions about OS/apps/threads.
And that is messy.
I’ll contribute this though - back in the olden times algorithmic efficiency was mostly determined by analyzing number of (FL)OPS and time complexity O(n^whatever).
But at least during the last three decades, the art of writing efficient code has increasingly dealt with the memory hierarchy and data management. As CPUs have increased in performance, the latency, bandwidth and sizes of various stages in the memory hierarchy impose ever harder limits, and complexities springing from assumptions about OS/apps/threads.
And that is messy.
Last edited:
Well we could also talk about C and C++ which are slower than Jonathan Blow JAI programming language at compiling by at least an order of magnituve (if not two)...
Runtime performance is unknown at this time, however if he's still using LLVM back-end there's no reason it wouldn't match C/C++.
We are using solutions for long gone hardware instead of current hardware..
I'll never understand why MS didn't clean/sanitize Windows 64 bits, it was a great opportunity to only keep Windows 32 bits compatibility through and emulator...
Runtime performance is unknown at this time, however if he's still using LLVM back-end there's no reason it wouldn't match C/C++.
We are using solutions for long gone hardware instead of current hardware..
I'll never understand why MS didn't clean/sanitize Windows 64 bits, it was a great opportunity to only keep Windows 32 bits compatibility through and emulator...
as a software developer myself i feel this thread is going in the wrong direction.
Oh, software is by large dysfunctional nowdays.
I'd say software is poorly QA'd, badly evolved, overly simplistic, inadaptable and fails inacceptably often in unacceptable manners
Performance is IMO one of the lesser problems.
It's true that often performance is an issue as well.
But this lack of performance can also be coming together with some of the issues mentioned above. In which case it is also not itself a problem, but a symptom
Oh, software is by large dysfunctional nowdays.
I'd say software is poorly QA'd, badly evolved, overly simplistic, inadaptable and fails inacceptably often in unacceptable manners
Performance is IMO one of the lesser problems.
It's true that often performance is an issue as well.
But this lack of performance can also be coming together with some of the issues mentioned above. In which case it is also not itself a problem, but a symptom
Last edited:
Unlike Blow's compiler, C and C++ compilers can actually be used and benchmarked. But it would be interesting to see his language/documentation/debugger.
green.pixel
Veteran
Of bad business practices?
They want as fast as possible turnover disregarding everything else in the process, including people
I've thought a lot about it the recent days. Conclusion: We always realize we did something wrong when it's already too late. :|
Maybe, but that's unlikely the reason. More the opposite: We still use x86 from the 70s because of backwards compatibility.
There is hardware that does not allow for inefficient coding, e.g. GPUs. No dynamic memory alloc, no lazy containers, nothing. You constantly need to build every tiny thing from scratch. But as a result the productivity is close to zero.
If there is a solution to this, then maybe another programming language. I have no idea how this could look like.
Or maybe AI becomes the better future coder, or at least optimizer. Let AI solve all our problems
Reminds me of a computer program that gained a lot of hype in the early 80's
The Last One - so called because it would be the last human programmed software
By September 1977, David had a logic-solving system which, if it didn't 'understand', asked questions of the user until it had sufficient knowledge to be able to represent the logic mathematically. The system appeared to 'pause' while the logic was developed. On one occasion the problem was so complex that the system 'paused' for three weeks. Sensibly, David had built some sort of trace into the program so he was able to check periodically and make sure it hadn't got stuck in a loop. Once the system's grasp of the logic was complete it then went ahead and turned this into a running program. The next year or so was spent 'tweaking' the system. Redundant code was removed, error trapping included and the system put through its paces on a real project.
By this time David's businesses, which he'd all but ignored, crashed leaving him destitute. The receiver took away his beloved computers
If you want to read the whole story
http://www.tebbo.com/presshere/html/wf8104.htm
