Topic: realloc() for C++
Author: Victor Dyachenko <victor.dyachenko@gmail.com>
Date: Wed, 1 Feb 2017 03:10:12 -0800 (PST)
Raw View
------=_Part_2720_551258283.1485947412838
Content-Type: multipart/alternative;
boundary="----=_Part_2721_1584982127.1485947412838"
------=_Part_2721_1584982127.1485947412838
Content-Type: text/plain; charset=UTF-8
I propose to extend C++ allocators with part of realloc()'s functionality.
Proposal:
https://github.com/2underscores-vic/articles/blob/master/realloc4cpp/realloc4cpp.md
What do you think?
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f37542be-461b-462f-8836-8962a5a21b1f%40isocpp.org.
------=_Part_2721_1584982127.1485947412838
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I propose to extend C++ allocators with part of realloc()&=
#39;s functionality.<br><br>Proposal: https://github.com/2underscores-vic/a=
rticles/blob/master/realloc4cpp/realloc4cpp.md<br><br>What do you think?<br=
></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/f37542be-461b-462f-8836-8962a5a21b1f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f37542be-461b-462f-8836-8962a5a21b1f=
%40isocpp.org</a>.<br />
------=_Part_2721_1584982127.1485947412838--
------=_Part_2720_551258283.1485947412838--
.
Author: Fabio Fracassi <f.fracassi@gmx.net>
Date: Wed, 1 Feb 2017 18:52:44 +0100
Raw View
On 01/02/2017 12:10, Victor Dyachenko wrote:
> I propose to extend C++ allocators with part of realloc()'s functionality.
>
> Proposal:
> https://github.com/2underscores-vic/articles/blob/master/realloc4cpp/realloc4cpp.md
>
> What do you think?
There has been a proposal in that direction in 2006.
(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2045.html,
especially the section Growth factor and memory handshake)
The reason that it was not adopted back then is that this interface was
not implementable with all system allocators (esp. the common default
libc malloc implementations). The sentiment then was that C had to
standardize the memory handshake first, before C++ can mandate it.
AFAIK the situation has not changed in that regard.
This said, I still think your proposal has merit, since a conforming
implementation is allowed to always fail to honor the request for
extension, it is implementable on all platforms, and when using a
compatible system allocator (like e.g. tcmalloc, jemalloc) all
facilities could profit.
You should look at n2045 and integrate the preferred/minimal requested
size functionality IMO.
best regards
Fabio
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/62ba30af-5e2c-8563-27ee-29eb90adfd30%40gmx.net.
.
Author: Victor Dyachenko <victor.dyachenko@gmail.com>
Date: Fri, 3 Feb 2017 00:27:18 -0800 (PST)
Raw View
------=_Part_461_1220711452.1486110438256
Content-Type: multipart/alternative;
boundary="----=_Part_462_1772851476.1486110438256"
------=_Part_462_1772851476.1486110438256
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Hello, Fabio. Thanks for review.
On Wednesday, February 1, 2017 at 8:52:47 PM UTC+3, Fabio Fracassi wrote:
>
> On 01/02/2017 12:10, Victor Dyachenko wrote:=20
> > I propose to extend C++ allocators with part of realloc()'s=20
> functionality.=20
> >=20
> > Proposal:=20
> >=20
> https://github.com/2underscores-vic/articles/blob/master/realloc4cpp/real=
loc4cpp.md=20
> >=20
> > What do you think?=20
>
> There has been a proposal in that direction in 2006.=20
> (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2045.html,=20
> especially the section Growth factor and memory handshake)=20
>
> The reason that it was not adopted back then is that this interface was=
=20
> not implementable with all system allocators (esp. the common default=20
> libc malloc implementations).
=D0=9C=D1=83 interface is not required to be implemented (but can be) by al=
l=20
allocators. Allocators can just ignore this extension. And there are many=
=20
custom allocators and scenarios which can benefit. For example,=20
arena-allocators where deallocate() is effectively no-op and vector just=20
loses memory on resize.
=20
> The sentiment then was that C had to=20
> standardize the memory handshake first, before C++ can mandate it.=20
>
It is again not the case now. And my proposal is attempt to break the=20
vicious circle:
1) C++ can't resize allocated memory because system allocators written in C=
=20
can offer only realloc() which is inappropriate
2) System allocator writers don't offer anything for C++ because C++ anyway=
=20
can't use this stuff and C is happy with realloc().
Again, my interface can be used right now with custom allocators and, in=20
the future, with system allocators which can implement it.
=20
> AFAIK the situation has not changed in that regard.=20
>
> This said, I still think your proposal has merit, since a conforming=20
> implementation is allowed to always fail to honor the request for=20
> extension, it is implementable on all platforms, and when using a=20
> compatible system allocator (like e.g. tcmalloc, jemalloc) all=20
> facilities could profit.=20
>
> You should look at n2045 and integrate the preferred/minimal requested=20
> size functionality IMO.=20
>
As I understand, this functionality is supposed to be used like this. If=20
I'm a container writer, I have some "grow strategy" and I need to insert N=
=20
elements. The "grow strategy" tells me that I should request memory for M=
=20
elements in this case, where M > N. Then M is a preffered size, N -=20
minimal. The allocator is free to extend the memory by any Q value, where N=
=20
<=3D Q <=3D M.
Did I get it correctly?
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/0508b4c2-1d46-4e8a-987d-1e4dffcb4c3c%40isocpp.or=
g.
------=_Part_462_1772851476.1486110438256
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hello, Fabio. Thanks for review.<br><br>On Wednesday, Febr=
uary 1, 2017 at 8:52:47 PM UTC+3, Fabio Fracassi wrote:<blockquote class=3D=
"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc s=
olid;padding-left: 1ex;">On 01/02/2017 12:10, Victor Dyachenko wrote:
<br>> I propose to extend C++ allocators with part of realloc()'s fu=
nctionality.
<br>>
<br>> Proposal:=20
<br>> <a href=3D"https://github.com/2underscores-vic/articles/blob/maste=
r/realloc4cpp/realloc4cpp.md" target=3D"_blank" rel=3D"nofollow" onmousedow=
n=3D"this.href=3D'https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.=
com%2F2underscores-vic%2Farticles%2Fblob%2Fmaster%2Frealloc4cpp%2Frealloc4c=
pp.md\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNG7DU4Y614ErGk5FBCFVdxE2jkZoQ&=
#39;;return true;" onclick=3D"this.href=3D'https://www.google.com/url?q=
\x3dhttps%3A%2F%2Fgithub.com%2F2underscores-vic%2Farticles%2Fblob%2Fmaster%=
2Frealloc4cpp%2Frealloc4cpp.md\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNG7DU=
4Y614ErGk5FBCFVdxE2jkZoQ';return true;">https://github.com/<wbr>2unders=
cores-vic/articles/<wbr>blob/master/realloc4cpp/<wbr>realloc4cpp.md</a>
<br>>
<br>> What do you think?
<br>
<br>There has been a proposal in that direction in 2006.=20
<br>(<a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n20=
45.html" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'=
;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22=
%2Fwg21%2Fdocs%2Fpapers%2F2006%2Fn2045.html\x26sa\x3dD\x26sntz\x3d1\x26usg\=
x3dAFQjCNEfWAs6CKq4vbvCOnP3NhprzBNEQQ';return true;" onclick=3D"this.hr=
ef=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjt=
c1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2006%2Fn2045.html\x26sa\x3dD\x26sntz\x3d=
1\x26usg\x3dAFQjCNEfWAs6CKq4vbvCOnP3NhprzBNEQQ';return true;">http://ww=
w.open-std.org/jtc1/<wbr>sc22/wg21/docs/papers/2006/<wbr>n2045.html</a>,=20
<br>especially the section Growth factor and memory handshake)
<br>
<br>The reason that it was not adopted back then is that this interface was=
=20
<br>not implementable with all system allocators (esp. the common default=
=20
<br>libc malloc implementations).</blockquote><div>=D0=9C=D1=83 interface i=
s not required to be implemented (but can be) by all allocators. Allocators=
can just ignore this extension. And there are many custom allocators and s=
cenarios which can benefit. For example, arena-allocators where deallocate(=
) is effectively no-op and vector just loses memory on resize.<br>=C2=A0</d=
iv><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;"> The sentiment then was tha=
t C had to=20
<br>standardize the memory handshake first, before C++ can mandate it.
<br></blockquote><div>It is again not the case now. And my proposal is atte=
mpt to break the vicious circle:<br><br>1) C++ can't resize allocated m=
emory because system allocators written in C can offer only realloc() which=
is inappropriate<br>2) System allocator writers don't offer anything f=
or C++ because C++ anyway can't use this stuff and C is happy with real=
loc().<br><br>Again, my interface can be used right now with custom allocat=
ors and, in the future, with system allocators which can implement it.<br>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">AFAIK the situatio=
n has not changed in that regard.
<br>
<br>This said, I still think your proposal has merit, since a conforming=20
<br>implementation is allowed to always fail to honor the request for=20
<br>extension, it is implementable on all platforms, and when using a=20
<br>compatible system allocator (like e.g. tcmalloc, jemalloc) all=20
<br>facilities could profit.
<br>
<br>You should look at n2045 and integrate the preferred/minimal requested=
=20
<br>size functionality IMO.
<br></blockquote><div>As I understand, this functionality is supposed to be=
used like this. If I'm a container writer, I have some "grow stra=
tegy" and I need to insert N elements. The "grow strategy" t=
ells me that I should request memory for M elements in this case, where M &=
gt; N. Then M is a preffered size, N - minimal. The allocator is free to ex=
tend the memory by any Q value, where N <=3D Q <=3D M.<br>Did I get i=
t correctly?<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/0508b4c2-1d46-4e8a-987d-1e4dffcb4c3c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/0508b4c2-1d46-4e8a-987d-1e4dffcb4c3c=
%40isocpp.org</a>.<br />
------=_Part_462_1772851476.1486110438256--
------=_Part_461_1220711452.1486110438256--
.
Author: Fabio Fracassi <f.fracassi@gmx.net>
Date: Fri, 3 Feb 2017 11:36:15 +0100
Raw View
This is a multi-part message in MIME format.
--------------F389A6E10C561CA4AEB90800
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Hello Victor,
On 03/02/2017 09:27, Victor Dyachenko wrote:
> Hello, Fabio. Thanks for review.
>
> On Wednesday, February 1, 2017 at 8:52:47 PM UTC+3, Fabio Fracassi wrote:
>
> On 01/02/2017 12:10, Victor Dyachenko wrote:
> > I propose to extend C++ allocators with part of realloc()'s
> functionality.
> >
> > Proposal:
> >
> https://github.com/2underscores-vic/articles/blob/master/realloc4cpp/=
realloc4cpp.md
> <https://github.com/2underscores-vic/articles/blob/master/realloc4cpp=
/realloc4cpp.md>
>
> >
> > What do you think?
>
> There has been a proposal in that direction in 2006.
> (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2045.html
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2045.html>,
> especially the section Growth factor and memory handshake)
>
> The reason that it was not adopted back then is that this
> interface was
> not implementable with all system allocators (esp. the common default
> libc malloc implementations).
>
> =D0=9C=D1=83 interface is not required to be implemented (but can be) by =
all=20
> allocators. Allocators can just ignore this extension. And there are=20
> many custom allocators and scenarios which can benefit. For example,=20
> arena-allocators where deallocate() is effectively no-op and vector=20
> just loses memory on resize.
Yes.
>
> The sentiment then was that C had to
> standardize the memory handshake first, before C++ can mandate it.
>
> It is again not the case now. And my proposal is attempt to break the=20
> vicious circle:
>
> 1) C++ can't resize allocated memory because system allocators written=20
> in C can offer only realloc() which is inappropriate
> 2) System allocator writers don't offer anything for C++ because C++=20
> anyway can't use this stuff and C is happy with realloc().
>
> Again, my interface can be used right now with custom allocators and,=20
> in the future, with system allocators which can implement it.
Yes, I realized, and I think that is a very good point.
I think now the next step would be to get some numbers on how much=20
benefit we can expect from this feature.
Small benchmarks help a bit. A prototype implementation where you update=20
std::vector to use this interface and benchmark a few real applications=20
will be much more convincing.
(Bloomberg made some rather extensive benchmarks of Allocation=20
strategies. I do not know how well those apply here, but maybe you can=20
use them as a starting point=20
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0089r0.pdf)
Note: Going to such length to prove the worth of a feature is not an=20
absolute requirement, but it definitely makes your proposal stronger.=20
(And IIRC some people were not convinced that n2045 would gain much=20
performance)
>
>
> You should look at n2045 and integrate the preferred/minimal
> requested
> size functionality IMO.
>
> As I understand, this functionality is supposed to be used like this.=20
> If I'm a container writer, I have some "grow strategy" and I need to=20
> insert N elements. The "grow strategy" tells me that I should request=20
> memory for M elements in this case, where M > N. Then M is a preffered=20
> size, N - minimal. The allocator is free to extend the memory by any Q=20
> value, where N <=3D Q <=3D M.
> Did I get it correctly?
Yes, that is also my understanding.
You might want also consider if Q is allowed to be bigger than M.
Do you intent to submit this Paper for the next Meeting? (The deadline=20
is Monday).
Are you able to go to a meeting to present it in Person?
Best regards
Fabio
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/4818b5ce-4ff9-fdb3-fff0-40a0fea75bf2%40gmx.net.
--------------F389A6E10C561CA4AEB90800
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<p>Hello Victor,<br>
</p>
<br>
<div class=3D"moz-cite-prefix">On 03/02/2017 09:27, Victor Dyachenko
wrote:<br>
</div>
<blockquote
cite=3D"mid:0508b4c2-1d46-4e8a-987d-1e4dffcb4c3c@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">Hello, Fabio. Thanks for review.<br>
<br>
On Wednesday, February 1, 2017 at 8:52:47 PM UTC+3, Fabio
Fracassi wrote:
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On
01/02/2017 12:10, Victor Dyachenko wrote:
<br>
> I propose to extend C++ allocators with part of
realloc()'s functionality.
<br>
>
<br>
> Proposal: <br>
> <a moz-do-not-send=3D"true"
href=3D"https://github.com/2underscores-vic/articles/blob/master/realloc4cp=
p/realloc4cpp.md"
target=3D"_blank" rel=3D"nofollow"
onmousedown=3D"this.href=3D'https://www.google.com/url?q\x3dhttps%3A%2F%2Fg=
ithub.com%2F2underscores-vic%2Farticles%2Fblob%2Fmaster%2Frealloc4cpp%2Frea=
lloc4cpp.md\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNG7DU4Y614ErGk5FBCFVdxE2=
jkZoQ';return
true;"
onclick=3D"this.href=3D'https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithu=
b.com%2F2underscores-vic%2Farticles%2Fblob%2Fmaster%2Frealloc4cpp%2Frealloc=
4cpp.md\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNG7DU4Y614ErGk5FBCFVdxE2jkZo=
Q';return
true;">https://github.com/<wbr>2underscores-vic/articles/<wbr>b=
lob/master/realloc4cpp/<wbr>realloc4cpp.md</a>
<br>
>
<br>
> What do you think?
<br>
<br>
There has been a proposal in that direction in 2006. <br>
(<a moz-do-not-send=3D"true"
href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2045.html"
target=3D"_blank" rel=3D"nofollow"
onmousedown=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww=
..open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2006%2Fn2045.html\x26s=
a\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEfWAs6CKq4vbvCOnP3NhprzBNEQQ';return
true;"
onclick=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.ope=
n-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2006%2Fn2045.html\x26sa\x3=
dD\x26sntz\x3d1\x26usg\x3dAFQjCNEfWAs6CKq4vbvCOnP3NhprzBNEQQ';return
true;">http://www.open-std.org/jtc1/<wbr>sc22/wg21/docs/papers/=
2006/<wbr>n2045.html</a>,
<br>
especially the section Growth factor and memory handshake)
<br>
<br>
The reason that it was not adopted back then is that this
interface was <br>
not implementable with all system allocators (esp. the common
default <br>
libc malloc implementations).</blockquote>
<div>=D0=9C=D1=83 interface is not required to be implemented (but =
can be)
by all allocators. Allocators can just ignore this extension.
And there are many custom allocators and scenarios which can
benefit. For example, arena-allocators where deallocate() is
effectively no-op and vector just loses memory on resize.<br>
</div>
</div>
</blockquote>
=C2=A0Yes.
<blockquote
cite=3D"mid:0508b4c2-1d46-4e8a-987d-1e4dffcb4c3c@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"> The
sentiment then was that C had to <br>
standardize the memory handshake first, before C++ can mandate
it.
<br>
</blockquote>
<div>It is again not the case now. And my proposal is attempt to
break the vicious circle:<br>
<br>
1) C++ can't resize allocated memory because system allocators
written in C can offer only realloc() which is inappropriate<br>
2) System allocator writers don't offer anything for C++
because C++ anyway can't use this stuff and C is happy with
realloc().<br>
<br>
Again, my interface can be used right now with custom
allocators and, in the future, with system allocators which
can implement it.<br>
</div>
</div>
</blockquote>
Yes, I realized, and I think that is a very good point. <br>
<br>
I think now the next step would be to get some numbers on how much
benefit we can expect from this feature.<br>
Small benchmarks help a bit. A prototype implementation where you
update std::vector to use this interface and benchmark a few real
applications will be much more convincing. <br>
(Bloomberg made some rather extensive benchmarks of Allocation
strategies. I do not know how well those apply here, but maybe you
can use them as a starting point
<a class=3D"moz-txt-link-freetext" href=3D"http://www.open-std.org/jtc1=
/sc22/wg21/docs/papers/2015/p0089r0.pdf">http://www.open-std.org/jtc1/sc22/=
wg21/docs/papers/2015/p0089r0.pdf</a>)<br>
<br>
Note: Going to such length to prove the worth of a feature is not an
absolute requirement, but it definitely makes your proposal
stronger. (And IIRC some people were not convinced that n2045 would
gain much performance)<br>
<br>
<blockquote
cite=3D"mid:0508b4c2-1d46-4e8a-987d-1e4dffcb4c3c@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<div>=C2=A0<br>
</div>
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>
You should look at n2045 and integrate the preferred/minimal
requested <br>
size functionality IMO.
<br>
</blockquote>
<div>As I understand, this functionality is supposed to be used
like this. If I'm a container writer, I have some "grow
strategy" and I need to insert N elements. The "grow strategy"
tells me that I should request memory for M elements in this
case, where M > N. Then M is a preffered size, N - minimal.
The allocator is free to extend the memory by any Q value,
where N <=3D Q <=3D M.<br>
Did I get it correctly?<br>
</div>
</div>
</blockquote>
Yes, that is also my understanding. <br>
You might want also consider if Q is allowed to be bigger than M. <br>
<br>
Do you intent to submit this Paper for the next Meeting? (The
deadline is Monday).<br>
Are you able to go to a meeting to present it in Person?<br>
<br>
Best regards<br>
<br>
Fabio<br>
<br>
<br>
</body>
</html>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/4818b5ce-4ff9-fdb3-fff0-40a0fea75bf2%=
40gmx.net?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com=
/a/isocpp.org/d/msgid/std-proposals/4818b5ce-4ff9-fdb3-fff0-40a0fea75bf2%40=
gmx.net</a>.<br />
--------------F389A6E10C561CA4AEB90800--
.
Author: Victor Dyachenko <victor.dyachenko@gmail.com>
Date: Fri, 3 Feb 2017 03:24:04 -0800 (PST)
Raw View
------=_Part_511_312776785.1486121044177
Content-Type: multipart/alternative;
boundary="----=_Part_512_918152215.1486121044177"
------=_Part_512_918152215.1486121044177
Content-Type: text/plain; charset=UTF-8
On Friday, February 3, 2017 at 1:36:19 PM UTC+3, Fabio Fracassi wrote:
> I think now the next step would be to get some numbers on how much benefit
> we can expect from this feature.
> Small benchmarks help a bit. A prototype implementation where you update
> std::vector to use this interface and benchmark a few real applications
> will be much more convincing.
> (Bloomberg made some rather extensive benchmarks of Allocation strategies.
> I do not know how well those apply here, but maybe you can use them as a
> starting point
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0089r0.pdf)
>
> Note: Going to such length to prove the worth of a feature is not an
> absolute requirement, but it definitely makes your proposal stronger. (And
> IIRC some people were not convinced that n2045 would gain much performance)
>
Undoubtedly! Will try to find some time to create benchmarks.
> You should look at n2045 and integrate the preferred/minimal requested
>
>> size functionality IMO.
>>
> As I understand, this functionality is supposed to be used like this. If
> I'm a container writer, I have some "grow strategy" and I need to insert N
> elements. The "grow strategy" tells me that I should request memory for M
> elements in this case, where M > N. Then M is a preffered size, N -
> minimal. The allocator is free to extend the memory by any Q value, where N
> <= Q <= M.
> Did I get it correctly?
>
> Yes, that is also my understanding.
> You might want also consider if Q is allowed to be bigger than M.
>
Sure. In the OP allocator is allowed to adjust/align requested size. Thanks
for the correction.
Will add an additional chapter with the alternative design - an additional
optional parameter for minimal size.
> Do you intent to submit this Paper for the next Meeting? (The deadline is
> Monday).
> Are you able to go to a meeting to present it in Person?
>
No, I'm unable to attend the meetings. And I'm not going to submit the
paper for the next meeting - too little time. Aim to the next one.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/73346b9e-a432-4d35-b1b9-53a743a9d256%40isocpp.org.
------=_Part_512_918152215.1486121044177
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, February 3, 2017 at 1:36:19 PM UTC+3, Fabio Fra=
cassi wrote: <br><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div bgcolor=
=3D"#FFFFFF" text=3D"#000000"><p>
</p>I think now the next step would be to get some numbers on how much
benefit we can expect from this feature.<br>
Small benchmarks help a bit. A prototype implementation where you
update std::vector to use this interface and benchmark a few real
applications will be much more convincing. <br>
(Bloomberg made some rather extensive benchmarks of Allocation
strategies. I do not know how well those apply here, but maybe you
can use them as a starting point
<a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p008=
9r0.pdf" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'=
;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22=
%2Fwg21%2Fdocs%2Fpapers%2F2015%2Fp0089r0.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg=
\x3dAFQjCNEZUYmi5t20YNpFPDBmlpKX_q1qLQ';return true;" onclick=3D"this.h=
ref=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fj=
tc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2015%2Fp0089r0.pdf\x26sa\x3dD\x26sntz\x=
3d1\x26usg\x3dAFQjCNEZUYmi5t20YNpFPDBmlpKX_q1qLQ';return true;">http://=
www.open-std.org/jtc1/<wbr>sc22/wg21/docs/papers/2015/<wbr>p0089r0.pdf</a>)=
<br>
<br>
Note: Going to such length to prove the worth of a feature is not an
absolute requirement, but it definitely makes your proposal
stronger. (And IIRC some people were not convinced that n2045 would
gain much performance)<br>
</div></blockquote><div>Undoubtedly! Will try to find some time to crea=
te benchmarks.<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">=
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
<blockquote type=3D"cite">
<div dir=3D"ltr">You should look at n2045 and integrate the preferred=
/minimal
requested <br><blockquote class=3D"gmail_quote" style=3D"margin:0=
;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
size functionality IMO.
<br>
</blockquote>
<div>As I understand, this functionality is supposed to be used
like this. If I'm a container writer, I have some "grow
strategy" and I need to insert N elements. The "grow st=
rategy"
tells me that I should request memory for M elements in this
case, where M > N. Then M is a preffered size, N - minimal.
The allocator is free to extend the memory by any Q value,
where N <=3D Q <=3D M.<br>
Did I get it correctly?<br>
</div>
</div>
</blockquote>
Yes, that is also my understanding. <br>
You might want also consider if Q is allowed to be bigger than M. <br><=
/div></blockquote><div>Sure. In the OP allocator is allowed to adjust/align=
requested size. Thanks for the correction.<br>Will add an additional chapt=
er with the alternative design - an additional optional parameter for minim=
al size.<br>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><d=
iv bgcolor=3D"#FFFFFF" text=3D"#000000">
Do you intent to submit this Paper for the next Meeting? (The
deadline is Monday).<br>
Are you able to go to a meeting to present it in Person?<br></div></blo=
ckquote><div>=C2=A0No, I'm unable to attend the meetings. And I'm n=
ot going to submit the paper for the next meeting - too little time. Aim to=
the next one.<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/73346b9e-a432-4d35-b1b9-53a743a9d256%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/73346b9e-a432-4d35-b1b9-53a743a9d256=
%40isocpp.org</a>.<br />
------=_Part_512_918152215.1486121044177--
------=_Part_511_312776785.1486121044177--
.