чт, 2 мар. 2023 г., 23:07 Rob Prowel <rprowel@comcast.net>:
On 3/2/23 08:02, Andrew Randrianasulu via Cin wrote:
> https://m.youtube.com/watch?v=tD5NrevFtbU
>
> well, I guess in cinelerra case even just time to initially type in all
> that code was relevant :)
>
> but I found it quite heartwarming how someone finally noticed how
> nicely-looking code may perform ....suboptimally.
>
> So, I wish all programmers to find right balance between nice features and
> nice performance :)
>
>

I guess the presenter has never heard of stuff like

premature optimization
inline, or static inline
code reuse vs brute force tradeoffs
supportability (writing code for others, not for yourself)


He kind of misrepresents some things, but I don't blame him, per-se.  I
just don't think he has the software engineering sophistication to
understand when different paradigms are called for.

Much of my work is in the embedded systems domain, and I started coding
on machines that had barely 4Kbytes of RAM so I'm no stranger to code
optimization.  I just think some things here are taken out of context to
prove a moderately weak point.

yet they have *some* point.

I think for example this diff to ffmpeg's opencl tonemap filter IS table-driven, yet I have no idea how much difference it will make in image quality ...

https://gist.github.com/sharpbai/5710e4bd06c35ce144e2945f1a9a7bb8#file-colorspace_common-cl

but because Karol Herbst was nice enough to fix rusticl on 32-bit hosts I can try this patch oneday :)