> On 8/6/24 14:53, ma...@mohawksoft.com wrote:
>> I call BS on that whole paragraph. Rust is OK, but ANYTHING you can
>> write
>> in Rust can be written to be faster in C/C++.
>
> Both are compiled languages, frequently using related compilers. Both
> are going to approach as-fast-as-possible. Theo
On Tue, 6 Aug 2024 16:31:29 -0700
Kent Borg wrote:
> C/C++ compilers are more mature, so there are better optimizers for
> C/C++ programmers. This is an advantage for C. Though, not always:
> sometimes the machine code will simply be as fast as it possible, and
> sometimes Rust will be that fa
> On Tue, 6 Aug 2024 18:12:25 -0400
> ma...@mohawksoft.com wrote:
>
>> Without getting into too much detail, their SVC server product had a
>> real-time polling process that maintained timers on various
>> processes, if the processing took too long, the system would
>> "fail-over" to the other node
On 8/6/24 14:53, ma...@mohawksoft.com wrote:
I call BS on that whole paragraph. Rust is OK, but ANYTHING you can write
in Rust can be written to be faster in C/C++.
Both are compiled languages, frequently using related compilers. Both
are going to approach as-fast-as-possible. Theoretically.
On Tue, 6 Aug 2024 18:12:25 -0400
ma...@mohawksoft.com wrote:
> Without getting into too much detail, their SVC server product had a
> real-time polling process that maintained timers on various
> processes, if the processing took too long, the system would
> "fail-over" to the other node. They we
>> - virtual machines impose a penalty of 1% or more -- worse when
>>not optimally configured
That's not even the half of it. I've done a few deep dives in VM
performance and one of the more insidious problems is scheduling multiple
CPUs for a VM. I was having a discussion with another engin
> On Tue, 6 Aug 2024 00:31:39 -0400
> Bill Bogstad wrote:
> The Rust language is an example of people doing exactly this. It's
> good, not perfect, but much better than C. And when optimized well, it
> can perform on par with or better than C.
I call BS on that whole paragraph. Rust is OK, but A
On 2024-08-06 13:03, Dan Ritter wrote:
Daniel M Gessel wrote:
On 2024-08-06 11:47, Dan Ritter wrote:
Daniel M Gessel wrote:
On 2024-08-06 00:31, Bill Bogstad wrote:
We would have a whole lot fewer moles to whack if we changed our tools.
In some cases a 5% performance hit is huge - offeri
Daniel M Gessel wrote:
>
>
> On 2024-08-06 11:47, Dan Ritter wrote:
> > Daniel M Gessel wrote:
> > > On 2024-08-06 00:31, Bill Bogstad wrote:
> > > > We would have a whole lot fewer moles to whack if we changed our tools.
> > > In some cases a 5% performance hit is huge - offering up "our progra
On 2024-08-06 11:47, Dan Ritter wrote:
Daniel M Gessel wrote:
On 2024-08-06 00:31, Bill Bogstad wrote:
We would have a whole lot fewer moles to whack if we changed our tools.
In some cases a 5% performance hit is huge - offering up "our programmers
make mistakes" as a justification is a non
Daniel M Gessel wrote:
> On 2024-08-06 00:31, Bill Bogstad wrote:
> > We would have a whole lot fewer moles to whack if we changed our tools.
>
> In some cases a 5% performance hit is huge - offering up "our programmers
> make mistakes" as a justification is a non-starter.
Remember that:
- virt
On 2024-08-06 00:31, Bill Bogstad wrote:
We would have a whole lot fewer moles to whack if we changed our tools.
In some cases a 5% performance hit is huge - offering up "our
programmers make mistakes" as a justification is a non-starter.
But enabling checks on security critical systems make
On Tue, 6 Aug 2024 00:31:39 -0400
Bill Bogstad wrote:
> Did I say that I wanted perfection? In text that you removed, I
No. Kent was suggesting that. I'm sorry that I conflated your and their
arguments. Because you and I are in vehement agreement.
> programs by something like 5-10%. Does an
13 matches
Mail list logo
