Date: Mon, 1 Sep 2025 05:33:22 +0000
> You want to have your cake and eat it too: have fast and cross-platform basic algorithms. You usually can't have both.
But that's precisely what I want to solve.
I can provide multiple implementations.
If I can test what is the target platform, I can pick the best implementation. If you don't have the hardware you get the "generic but at least it works" implementation, but if you do you can get the better version for your hardware.
You would still end up with a cross-platform library, from a user's perspective it still works everywhere, but it is internally built with non-portable components. And that is fine because you can just swap those components.
But if I have to go to every single compiler vendor to figure out how to do this test, it becomes much harder.
-----Original Message-----
From: Std-Discussion <std-discussion-bounces_at_lists.isocpp.org> On Behalf Of Thiago Macieira via Std-Discussion
Sent: Monday, September 1, 2025 01:37
To: std-discussion_at_[hidden]
Cc: Thiago Macieira <thiago_at_macieira.org>
Subject: Re: [std-discussion] Architecture specific library extensions
On Sunday, 31 August 2025 04:40:00 Pacific Daylight Time Tiago Freire via Std- Discussion wrote:
> Now imagine that a systems implementer comes along and sees 2
> different AES libraries, one runs everywhere but is painfully slow,
> the other is blazingly fast but only runs on 1 or 2 systems. A system
> engineer couldn't care less if your code is portable, what they care
> about is that they have millions of requests per second that they have
> to respond to and has to figure out how many servers they have to buy.
> They don't have a to support a zoo of different systems, they only
> have to support one that they buy in bulk and the less they have to buy the better.
>
> Until of course the day they have to support a different system, and
> now their software doesn't run on it and it might take years to
> re-write the whole thing and that is if they even bother to sink that
> cost instead of giving up on the effort.
>
> How many times I have seen this?
>
> If I can take advantage of the hardware, and provide my users a better
> experience to convince them to keep using it, why shouldn't I be
> allowed to do it?
You're forgetting that the reason the faster implementation of AES can exist is that it is using information about the hardware that is not cross-platform in the first place. It's both the presence of specialised instructions (which may do all of the AES or a portion of it) and details on how to use everything else in the hardware.
You want to have your cake and eat it too: have fast and cross-platform basic algorithms. You usually can't have both.
> What standard, other than THE C++ standard, should define this
> identification?
NO standard, because it isn't common at all.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Principal Engineer - Intel Platform & System Engineering
But that's precisely what I want to solve.
I can provide multiple implementations.
If I can test what is the target platform, I can pick the best implementation. If you don't have the hardware you get the "generic but at least it works" implementation, but if you do you can get the better version for your hardware.
You would still end up with a cross-platform library, from a user's perspective it still works everywhere, but it is internally built with non-portable components. And that is fine because you can just swap those components.
But if I have to go to every single compiler vendor to figure out how to do this test, it becomes much harder.
-----Original Message-----
From: Std-Discussion <std-discussion-bounces_at_lists.isocpp.org> On Behalf Of Thiago Macieira via Std-Discussion
Sent: Monday, September 1, 2025 01:37
To: std-discussion_at_[hidden]
Cc: Thiago Macieira <thiago_at_macieira.org>
Subject: Re: [std-discussion] Architecture specific library extensions
On Sunday, 31 August 2025 04:40:00 Pacific Daylight Time Tiago Freire via Std- Discussion wrote:
> Now imagine that a systems implementer comes along and sees 2
> different AES libraries, one runs everywhere but is painfully slow,
> the other is blazingly fast but only runs on 1 or 2 systems. A system
> engineer couldn't care less if your code is portable, what they care
> about is that they have millions of requests per second that they have
> to respond to and has to figure out how many servers they have to buy.
> They don't have a to support a zoo of different systems, they only
> have to support one that they buy in bulk and the less they have to buy the better.
>
> Until of course the day they have to support a different system, and
> now their software doesn't run on it and it might take years to
> re-write the whole thing and that is if they even bother to sink that
> cost instead of giving up on the effort.
>
> How many times I have seen this?
>
> If I can take advantage of the hardware, and provide my users a better
> experience to convince them to keep using it, why shouldn't I be
> allowed to do it?
You're forgetting that the reason the faster implementation of AES can exist is that it is using information about the hardware that is not cross-platform in the first place. It's both the presence of specialised instructions (which may do all of the AES or a portion of it) and details on how to use everything else in the hardware.
You want to have your cake and eat it too: have fast and cross-platform basic algorithms. You usually can't have both.
> What standard, other than THE C++ standard, should define this
> identification?
NO standard, because it isn't common at all.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Principal Engineer - Intel Platform & System Engineering
Received on 2025-09-01 05:33:26