Date: Mon, 11 Nov 2024 20:55:12 -0800
On Monday 11 November 2024 20:04:33 Pacific Standard Time Phil Bouchard wrote:
> Well performance and power consumption are inversely proportional.
Usually, but not necessarily. In some cases, there may be a trade-off between
time performance and power performance: that is, use more energy to achieve
the same work, but in a shorter time. A simple case for this is when the CPU
is clocked at a higher frequency: 2x the clock usually means more than 2x the
energy consumption. Granted, this is not under the control of the compiler
today, but it could be if we talk about heterogeneous computing and
dispatching to specialised compute devices.
> On another hand, memory management is one topic it needs to worry about.
> Whether:
> - C++ compilers become stricter;
> - C++ compilers finally can make the difference between an iterator and
> a pointer;
> - Usage of external static code analysis tools;
> - Possibility of integrating a garbage collector, memory pools or
> commercial memory managers;
Garbage collectors can make code faster by removing the clean up from the
critical code paths. For short, bursty workloads (like web services) where
performance = time, this is beneficial. No one cares if the web service needs
to spend some more time in the background cleaning up after the request it's
replied to.
That said, yes, those topics are in-scope for C++. Just don't make an
assumption that a choice one way or another will improve performance (for some
definition of "performance") for all cases. In other words, don't generalise.
> So I ultimately think if there would be a way to add implicit function
> parameters and class members then we wouldn't need commercial static
> code analysis tools and we could integrate serious memory managers freely.
That's a bold claim.
> We don't have a lot of options left if we care about the lifetime of C++.
You didn't prefix this with "I think", but I'm assuming it's implied. And I beg
to differ. There's no indication that C++ is dying. And besides, i fit is
replaced by something better, we are better off for it. We shouldn't fight for
C++ for the sake of it. Either it is good at something (hopefully many
somethings), or it gets replaced.
> Well performance and power consumption are inversely proportional.
Usually, but not necessarily. In some cases, there may be a trade-off between
time performance and power performance: that is, use more energy to achieve
the same work, but in a shorter time. A simple case for this is when the CPU
is clocked at a higher frequency: 2x the clock usually means more than 2x the
energy consumption. Granted, this is not under the control of the compiler
today, but it could be if we talk about heterogeneous computing and
dispatching to specialised compute devices.
> On another hand, memory management is one topic it needs to worry about.
> Whether:
> - C++ compilers become stricter;
> - C++ compilers finally can make the difference between an iterator and
> a pointer;
> - Usage of external static code analysis tools;
> - Possibility of integrating a garbage collector, memory pools or
> commercial memory managers;
Garbage collectors can make code faster by removing the clean up from the
critical code paths. For short, bursty workloads (like web services) where
performance = time, this is beneficial. No one cares if the web service needs
to spend some more time in the background cleaning up after the request it's
replied to.
That said, yes, those topics are in-scope for C++. Just don't make an
assumption that a choice one way or another will improve performance (for some
definition of "performance") for all cases. In other words, don't generalise.
> So I ultimately think if there would be a way to add implicit function
> parameters and class members then we wouldn't need commercial static
> code analysis tools and we could integrate serious memory managers freely.
That's a bold claim.
> We don't have a lot of options left if we care about the lifetime of C++.
You didn't prefix this with "I think", but I'm assuming it's implied. And I beg
to differ. There's no indication that C++ is dying. And besides, i fit is
replaced by something better, we are better off for it. We shouldn't fight for
C++ for the sake of it. Either it is good at something (hopefully many
somethings), or it gets replaced.
-- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Principal Engineer - Intel DCAI Platform & System Engineering
Received on 2024-11-12 04:55:19