The MASM Forum
General => The Soap Box => Topic started by: hutch-- on March 03, 2023, 04:34:28 PM
-
This is why you write assembler code. The same class of people who told you that assembler was unreadable produced this class of crap.
https://www.youtube.com/watch?v=tD5NrevFtbU
-
So "clean" code is 50% slower than using a switch. The reason being, obviously, the overhead of calls to proc, like creating stack frames. Wow, that's revolutionary, but why does he need 10 minutes to explain that?
-
This is why you write assembler code. The same class of people who told you that assembler was unreadable produced this class of crap.
https://www.youtube.com/watch?v=tD5NrevFtbU
:biggrin:
Another example of deteriorating education levels...
Just laziness and not really understanding what's going on under the hood. When I discuss this at my uni, the response is always: time is money....
-
This is why you write assembler code. The same class of people who told you that assembler was unreadable produced this class of crap.
https://www.youtube.com/watch?v=tD5NrevFtbU
:biggrin:
Another example of deteriorating education levels...
Just laziness and not really understanding what's going on under the hood. When I discuss this at my uni, the response is always: time is money....
But with recent record high electricity prices,it also means load bloat slowly and slower execution speed = computer users need to pay bigger electricity bill compared to a few kb asm+pixelshader program that procedurally generate everything, instead of modern tb graphics game take to load
-
In africa people can always pump water from sea to desert using solaric power and then they get moisture and sea salt to sell.
Nothing grow in sand, so why not use it to collect salt.
-
:biggrin:
Polymorphism, I guess this has something to do with "Polly wanna cracka".
Bottom line is with x86 or 64 is that all code is procedural, the rest is packaging. You can in fact package objects in efficient high performance ways so that a single call can put a lot of functionality into an app but wrap it in multiple depths of structures and not providing the compiler/assembler with detailed access to the underlying code and you get the example in the video of serious reductions in performance.
The historical model of procedures in object modules and built into libraries when done properly can be very efficient and produce genuinely fast code and at the lowest level, you can forget theories of having to make each procedure at its smallest in singular functionality forms, if you want to up the speed of an algo and are patient enough, you can directly handle string lengths, trim the fronts off strings, perform any transformations you like and bundle all of it into a single algorithm.
This is not politically correct and that's why you do it, performance over bullsh*t is a winner. There is yet another factor, some code matter in terms of speed, a lot of other code is simply getting the logic right and the trick is to know the difference, having a MessageBox that makes claims to be the world's fastest, even if it was possible, is a waste of time, put your effort into things that matter.
CPUs are mechanical devices and if you can capitalise on understanding what they do, you can tune fast and efficient code. Long ago an old friend from the PB forum coined a phrase to counter OOP programming, HOP was Hardware Oriented Programming.
-
As hutch said, OOP and hardware programming are quite in from different planet.
Working with hardware is difficult, but most efficient for programs to work in special cases, low level code works.
I have made many support apps for industrial purposes, last was for making barcodes for factory production line.
I have done COM based lazer and vax marking software for production lines for 24/7 usage.
If software works in 24/7 enviroment, it can't have any cumulative errors, what leads crashes.
An OOP is very resource hungry for those cases.
Hopefully i see some good comments of making software for industrial enviroments.
-
:biggrin:
This is a classical problem we came from time to time.
"Performance" have same problems that "efficiency". How they are defined? What resources are available? What results are wanted?
Tipically Performance = results / resources, but not so easy, same results and resources can take different value in different cases.
For Hutch, programming skill is a free and unlimited resource, then OOP always will perform worst than procedural, but that is an specific case.
Timo case is more related to "eficacy", to reach wanted results. The program must do what have to do, under some parameters. If OOP is out of parameters then is not even an option, but also is an specific case.
-
It's like playing chess:
Can I make this move?
Yes, of course.
But should I make this move?
-
Not everything about oop is bad
Hutch showed me example of Subclassing a button
So it directly called a proc,instead of use switch/case in wndproc