[Cin] a bit ot: performance vs clean programming (yt, 22 min)

[Andrew Randrianasulu]

чт, 2 мар. 2023 г., 23:07 Rob Prowel <rprowel at 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 :)


>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cinelerra-gg.org/pipermail/cin/attachments/20230303/c2750e33/attachment.htm>