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.