On Saturday, 8 April 2023 22:01:08 -03 Phil Bouchard wrote:
> It is license-based so I can easily activate a demo license for a few
> months in Linux, MacOS or Windows. Right now it's based on Clang 12 and
> I'll need to update it but for a demo it's good enough.

That's not the point. Since I do C++ in my day job, this would count as work.
I can't accept any licensing terms on behalf of the company other than Open
Source ones. A free-as-in-beer but non-standard licence wouldn't work because
the corporate bureaucracy would need to get involved.

> >> It is 3.6 times faster under Linux so I expect an even greater standard
> >> deviation under Windows.
> >
> > Faster than what? What workloads? Under what conditions? Compared to what
> > other solutions?
>
> Faster than the standard malloc() for consecutive allocations
> specialized for thread-local FIFO containers.

How about other replacement malloc()s? How does it compare to an obstack?

And what's the trade-off? Look for it, because it must be there. For example,
is it thread-safe? How well does it scale over to hundreds of threads? Our
data shows that the typical cloud VM size is under 48 vCPUs, but your work may
not be "typical cloud" and may very well be one of those that use all 240+
logical processors of modern CPUs. In fact, one of my To-Do items for the next
quarter is to deal with scaling an application to 960 logical processors.

> > That isn't to say he's wrong; he does have some valid points. But he says
> > isn't gospel. Heck, what Bjarne says isn't gospel either.
>
> That is why I hope to contribute to help improve C++ from my own
> experience. I seriously believe we need to turn the page on memory bugs
> in 2023 and scale up the framework and design of C++ so we can write
> more complex code at a higher level more easily.

No dispute there. It's the *how* to go about it that is the issue. If it were
easy, it would have been done. Other, memory-safer languages have some other
trade-offs that have kept C++ and even C with their lower-level memory
management relevant.

> Python offers that but its core design is hopeless and is much slower
> than C++ by far. Nonetheless the AI industry chose Python because of that.

A lot of Python AI code is a Python wrapper around C++, C and even assembly
core. NumPy's core vector math is written in direct assembly.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel DCAI Cloud Engineering