David Rowley writes:
> On Fri, 19 Jan 2024 at 01:07, Andy Fan wrote:
>> I find the following code in DiscreteKnapsack is weird.
>>
>>
>> for (i = 0; i <= max_weight; ++i)
>> {
>> values[i] = 0;
>>
>> ** memory allocation here, and the num_items bit is removed
On Thu, 18 Jan 2024 at 16:24, David Rowley wrote:
> On Thu, 18 Jan 2024 at 15:22, Richard Guo wrote:
> > Do you think we can use 'memcpy(a, b, BITMAPSET_SIZE(b->nwords))'
> > directly in the new bms_replace_members() instead of copying the
> > bitmapwords one by one, like:
> >
> > - i = 0;
> >
On Fri, 19 Jan 2024 at 01:07, Andy Fan wrote:
> I find the following code in DiscreteKnapsack is weird.
>
>
> for (i = 0; i <= max_weight; ++i)
> {
> values[i] = 0;
>
> ** memory allocation here, and the num_items bit is removed later **
>
> sets[i]
Hi,
David Rowley writes:
> Given that the code original code was written in a very deliberate way
> to avoid reallocations, I now think that we should maintain that.
>
> I've attached a patch which adds bms_replace_members(). It's basically
> like bms_copy() but attempts to reuse the member
Hi,
David Rowley writes:
> On Thu, 18 Jan 2024 at 14:58, Andy Fan wrote:
>> I want to know if "user just want to zero out the flags in bitmapset
>> but keeping the memory allocation" is a valid requirement. Commit
>> 00b41463c makes it is hard IIUC.
>
> Looking at your patch, I see:
>
> +/*
On Thu, 18 Jan 2024 at 14:58, Andy Fan wrote:
> I want to know if "user just want to zero out the flags in bitmapset
> but keeping the memory allocation" is a valid requirement. Commit
> 00b41463c makes it is hard IIUC.
Looking at your patch, I see:
+/*
+ * does this break commit
Thanks for having a look at this again.
On Thu, 18 Jan 2024 at 15:22, Richard Guo wrote:
> Do you think we can use 'memcpy(a, b, BITMAPSET_SIZE(b->nwords))'
> directly in the new bms_replace_members() instead of copying the
> bitmapwords one by one, like:
>
> - i = 0;
> - do
> - {
> -
On Thu, Jan 18, 2024 at 8:35 AM David Rowley wrote:
> The functions's header comment mentions "The bitmapsets are all
> pre-initialized with an unused high bit so that memory allocation is
> done only once.".
Ah, I neglected to notice this when reviewing the v1 patch. I guess
it's implemented
Hi,
David Rowley writes:
> On Tue, 16 Jan 2024 at 16:32, David Rowley wrote:
>>
>>
>> Now that 00b41463c changed Bitmapset to have NULL be the only valid
>> representation of an empty set, this code no longer makes sense. We
>> may as well just bms_free() the original set and bms_copy() in
On Tue, 16 Jan 2024 at 16:32, David Rowley wrote:
>
> While working on [1], I noticed some strange code in
> DiscreteKnapsack() which seems to be aiming to copy the Bitmapset.
>
> It's not that obvious at a casual glance, but:
>
> sets[j] = bms_del_members(sets[j], sets[j]);
>
> this is aiming to
On Tue, Jan 16, 2024 at 11:32 AM David Rowley wrote:
> While working on [1], I noticed some strange code in
> DiscreteKnapsack() which seems to be aiming to copy the Bitmapset.
>
> It's not that obvious at a casual glance, but:
>
> sets[j] = bms_del_members(sets[j], sets[j]);
>
> this is aiming
While working on [1], I noticed some strange code in
DiscreteKnapsack() which seems to be aiming to copy the Bitmapset.
It's not that obvious at a casual glance, but:
sets[j] = bms_del_members(sets[j], sets[j]);
this is aiming to zero all the words in the set by passing the same
set in both
12 matches
Mail list logo
