MarsHardcoreoptimal java experience
AlmightySnoo đąđźđ±đșđŠI know the guy meant it as a joke but in my team I see the damage âacademicâ OOP/UML courses do to a programmer. In a library thatâs supposed to be high-performance code in C++ and does stuff like solving certain PDEs and performing heavy Monte-Carlo simulations, the guys with OOP/UML background tend to abuse dynamic polymorphism and write a lot of bad code with lots of indirections and many of them arenât aware of the fact that virtual methods and
dynamic_castâs have a price and an especially ugly one if you use them at every step of your iterative algorithm. Like the guy in the meme I certainly wouldnât want to have someone in my team who was molded by Java and UML diagrams.
Depends on the requirements. Writing the code in a natural and readable way should be number one.
Then you benchmark and find out what actually takes time; and then optimize from there.
At least thats my approach when working with mostly functional languages. No need obsess over the performance of something thats ran only a dozen times per second.
I do hate over engineered abstractions though. But not for performance reasons.
RyanYou need to me careful about benchmarking to find performance problems after the fact. You can get stuck in a local maxima where there is no particular cost center buts itâs all just slow.
If performance specifically is a goal there should probably at least be a theory of how it will be achieved and then that can be refined with benchmarks and profiling.
Writing the code in a natural and readable way should be number one.
I mean, even there it depends what youâre doing. A small matrix multiplication library should be fast even if it makes the code uglier. For most coders youâre probably right, though.
Even then you can take some effort to make easier to parse for humans.
Oh, absolutely. Itâs just the second most important thing.
You can add tons of explanatory comments with zero performance cost.
Also in programming in general (so, outside stuff like being a Quant) the fraction of the code made which has high performance as the top priority is miniscule (and I say this having actually designed high-performance software systems for a living) - as explained earlier by @ForegoneConclusion, you donât optimize upfront, you optimized when you figure out itâs actually needed.
Thinking about it, if youâre designing your own small matrix multiplication library (i.e. reinventing the wheel) youâre probably failing at a software design level: as long as the licensing is compatible, itâs usually better to get something that already exists, is performance oriented and has been in use for decades than making your own (almost certainly inferior and with fresh new bugs) thing.
Thinking about it, if youâre designing your own small matrix multiplication library (i.e. reinventing the wheel)
I mentioned this example because a fundamental improvement was actually made with the help of AI recently. 4x4 in specific was improved noticeably IIRC, and if you know a bit about matrix multiplication, that ripples out to large matrix algorithms.
PS: Not a personal critical
I would not actually try this unless I had a reason to think I could do better, but I come from a maths background and do have a tendency to worry about efficiency unnecessarily.
I think in most cases (matrix multiplication being probably the biggest exception) there is a way to write an algorithm thatâs easy to read, especially with comments where needed, and still approaches the problem the best way. Whether itâs worth the time trying to build that is another question.
In my experience we all go through a stage at the Designed-Developer level of, having discovered things like Design Patterns, overengineering the design of the software to the point of making it near unmaintainable (for others or for ourselves 6 months down the line).
The next stage is to discover the joys of KISS and, like you described, refraining from premature optimization.
I think many academic courses are stuck with old OOP theories from the 90s, while the rest of the industry have learned from its failures long time ago and moved on with more refined OOP practices. Turns out inheritance is one of the worst ways to achieve OOP.
I think a lot of academic oop adds inheritance for the heck of it. Like theyâre more interested in creating a tree of life for programming than they are in creating a maintainable understandable program.
einsteinx2Thatâs the problem, a lot of CS professors never worked in the industry or did anything outside academia so they never learned those lessonsâŠor the last time they did work was back in the 90s lol.
Doesnât help that most universities donât seem to offer âsoftware engineeringâ degrees and so everyone takes âcomputer scienceâ even if they donât want to be a computer scientist.
zbecker@einsteinx2 @magic_lobster_party
This is most definitely my experience with a lot of CS professors unfortunately.
The Design Patterns book itself (for many an OO-Bible) spends the first 70 something pages going all about general good OO programming advice, including (repeatedly emphasised) that OO design should favour delegation over inheritance.
Personally for me (who started programming professionally in the 90s), that first part of the book is at least as important the rest of it.
However a lot of people seemed to have learn Patterns as fad (popularized by oh-so-many people who never read a proper book about it and seem to be at the end of a long chinese-whispers chain on what those things are all about), rather than as a set of tools to use if and when itâs appropriate.
(Ditto for Agile, where so many seem to have learned loose practices from it as recipes, without understanding their actual purpose and applicability)
Iâll stop ranting now ;)
I fully agree about the damage done at universities. I also fully agree about the teaching professors being out of the game too long or never having been at a level which would be worth teaching to other people. A term which I heard from William Kenned first is âmechanical sympathyâ. IMHO this is the big missing thing in modern CS education. (Ok, add to that the missing parts about proper OOP, proper functional programming and literally anything taught to CS grads but relational/automata theory and mathematics (summary: mathematics) :-P). In the end I wouldnât trust anyone who cannot write Assembler, C and knows about Compiler Construction to write useful low level code or even tackle C++/Rust.
OOP/UML courses
Luckily, i had only one, and the crack who code-golfes in assembler did the work of us three.
Thatâs wild that shared ptr is so inefficient. I thought everyone was moving towards those because they were universally better. No one mentions the performance hit.
Atomic instructions are quite slow and if they run a lot⊠Rust has two types of reference counted pointer for that reason. One that has atomic reference counting for multithreaded code and one non-atomic for single threaded. Reference counting is usually overkill in the first place and can be a sign that your code doesnât have proper ownership.
I have been writing code professionally for 6ish years now and have no idea what you said