From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us2-ob3-1.mailhostbox.com (us2-ob3-1.mailhostbox.com [208.91.199.217]) by sourceware.org (Postfix) with ESMTPS id 5865A3858C52 for ; Mon, 28 Mar 2022 01:11:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 5865A3858C52 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=soulstudios.co.nz Authentication-Results: sourceware.org; spf=none smtp.mailfrom=soulstudios.co.nz Received: from [192.168.90.100] (ip103-24-137-28.satlan.co.nz [103.24.137.28]) (Authenticated sender: matt@soulstudios.co.nz) by us2.outbound.mailhostbox.com (Postfix) with ESMTPA id 1DAEFDA92E for ; Mon, 28 Mar 2022 01:11:04 +0000 (GMT) Message-ID: Date: Mon, 28 Mar 2022 14:11:01 +1300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 To: libstdc++@gcc.gnu.org Content-Language: en-US From: Soul Studios Subject: Request for comment from LEWG Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Score: 0 X-CMAE-Analysis: v=2.4 cv=Gap0ISbL c=1 sm=1 tr=0 ts=62410b29 a=XGn/WN3kvo70F+EHsYVJeg==:117 a=XGn/WN3kvo70F+EHsYVJeg==:17 a=IkcTkHD0fZMA:10 a=NEAV23lmAAAA:8 a=b4LDLZbEAAAA:8 a=8n3XebF7nv2uivp_1YYA:9 a=QEXdDO2ut3YA:10 a=N90BZEdSFgYA:10 a=20T61YgZp4ItGotXEy2O:22 X-Spam-Status: No, score=-1163.8 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libstdc++@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libstdc++ mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2022 01:11:10 -0000 Hi all, was hoping to hear back from Jonathan but haven't so far, so just posting here for comment too - this is Matt Bentley. std::hive (previously: colony) has had a preliminary meeting under LEWG - there were a couple of questions raised by the chairs based on the concern that the secondary option (memory_use) in the 'hive_priority' template parameter might not end up being implemented by implementors, which then would get frozen into ABI. They recommended I contact yourselves, amongst others. If someone could get back to me on the following before april 5th (the next hive lewg meeting) that'd be appreciated: a). Would libstdc++ be more likely to use the reference implementation (https://github.com/mattreecebentley/plf_hive, which has the memory_use implemented) or write it's own? The reference is under a zLib license, which is compatible with GPL, but as far as I know I could 'grant' a version to libstdc++ under the GPL, if this were a problem (the original would retain it's zlib license). b). If libstdc++ were to roll it's own implementation, would the memory_use priority be likely to be implemented? In terms of the reference implementation, this option merely changes the skipfield type from unsigned short to unsigned char - which reduces skipfield memory use while limiting maximum block capacities, which in turn limits performance above ~500 elements. There are more memory-saving designs possible, which are described in the 'Design Decisions' section of the paper (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p0447r19.html), but to date I have not tried these, have only indicated that they are possible. Thanks in advance- Matt