On 03/04/14 11:48 PM, Nathan Myers wrote:
Perhaps the best thing is to wait a month (or two or three) until DST
is more of a reality and then see how we feel.
Are you thinking we should also wait before converting the current uses
of ~[T] to VecT? Doing the migration gives us the
Needing to use a header seriously hurts the performance. The new
vector is 7x faster at pushing elements when space isn't reserved
compared to the old one, all due to leaving off the length/capacity
header. The overhead would be less if it stored the capacity inside
*and* outside the vector,
On 04/04/14 10:51 AM, Manu Thambi wrote:
Needing to use a header seriously hurts the performance. The new
vector is 7x faster at pushing elements when space isn't reserved
compared to the old one, all due to leaving off the length/capacity
header. The overhead would be less if it stored the
On 04/04/14 01:50 PM, Manu Thambi wrote:
As Nathan mentioned, the capacity is stored at a negative offset to the
pointer to the heap.
Storing at a negative index removes the cost at indexing, but not
elsewhere. It still consumes more memory and makes `push` slower,
especially since it has to
On 04/04/2014 02:51 PM, Daniel Micay wrote:
Storing at a negative index removes the cost at indexing, but not
elsewhere. It still consumes more memory and makes `push` slower,
especially since it has to do more than more offset based on alignment
with at least one overflow check.
In the
On 04/04/14 04:12 PM, Manu Thambi wrote:
On 04/04/2014 02:51 PM, Daniel Micay wrote:
Storing at a negative index removes the cost at indexing, but not
elsewhere. It still consumes more memory and makes `push` slower,
especially since it has to do more than more offset based on alignment
Most of your comments below do not apply to a properly implemented
negative index scheme.
So, it seems clear to me, that I haven't been able to get it across to you.
I guess we can both agree that spending more time on this thread is
unproductive, especially
since the real question is whether
On Wed, Apr 2, 2014 at 9:21 PM, Daniel Micay danielmi...@gmail.com wrote:
I used a sentinel value in my fix along with providing a guarantee that
`free` is never called on zero-size allocation. That's the end of any
no-op `VecT` - `~[T]` conversions since it will need to free a zero
size
On 03/04/14 17:15, comex wrote:
You're talking about allocators designed around the limitation of an
API. The design no longer needs to make the same compromises if you're
going to know the size. The difference between no cache miss and a cache
miss is not insignificant...
I explained why I
On 03/04/14 02:15 AM, comex wrote:
On Wed, Apr 2, 2014 at 9:21 PM, Daniel Micay danielmi...@gmail.com wrote:
I used a sentinel value in my fix along with providing a guarantee that
`free` is never called on zero-size allocation. That's the end of any
no-op `VecT` - `~[T]` conversions since it
On Wed, Apr 02, 2014 at 09:21:56PM -0400, Daniel Micay wrote:
...A distinct `~[T]` and `VecT` will make the language more
painful to use...
This is precisely the matter of debate, isn't it? I personally see two
sides to this, which is why I was suggesting that maybe we should wait
until we can
On 03/04/14 10:22, Niko Matsakis wrote:
On Wed, Apr 02, 2014 at 04:03:37PM -0400, Daniel Micay wrote:
I have no sane proposal to fix this beyond passing a size to free.
I don't believe there is a problem with just not using null to
represent such pointers (for example, 1 would suffice). This
On 03/04/14 01:22 PM, Ziad Hatahet wrote:
Would it be useful to look at what other languages are doing? For
instance, slices in Go are appendable, so perhaps it would be worth
looking at code bases written in Go to see how they deal with slices, or
how often they append to slices returned from
On Thu, Apr 3, 2014 at 11:09 AM, Daniel Micay danielmi...@gmail.com wrote:
Go doesn't have an equivalent to what `~[T]` will be.
Which was my point. From what I understand, Go's slices are analogous to
Rust's VecT in that they are growable. So I was suggesting perusing
existing Go code bases
Perhaps the best thing is to wait a month (or two or three) until DST
is more of a reality and then see how we feel.
Are you thinking we should also wait before converting the current uses
of ~[T] to VecT? Doing the migration gives us the performance[1] and
zero-length-zero-alloc benefits,
I've noticed recently that there seems to be a bit of confusion about the fate
of ~[T] with an impending implementation of DST on the horizon. This has been
accompanied with a number of pull requests to completely remove many uses of
~[T] throughout the standard distribution. I'd like to take some
On 02/04/14 11:35 AM, Alex Crichton wrote:
I've noticed recently that there seems to be a bit of confusion about the fate
of ~[T] with an impending implementation of DST on the horizon. This has been
accompanied with a number of pull requests to completely remove many uses of
~[T] throughout
On 4/2/14 9:25 AM, Daniel Micay wrote:
On 02/04/14 11:35 AM, Alex Crichton wrote:
I've noticed recently that there seems to be a bit of confusion about the fate
of ~[T] with an impending implementation of DST on the horizon. This has been
accompanied with a number of pull requests to completely
On 02/04/14 02:28 PM, Patrick Walton wrote:
On 4/2/14 9:25 AM, Daniel Micay wrote:
On 02/04/14 11:35 AM, Alex Crichton wrote:
I've noticed recently that there seems to be a bit of confusion about
the fate
of ~[T] with an impending implementation of DST on the horizon. This
has been
On Wed, Apr 2, 2014 at 12:25 PM, Daniel Micay danielmi...@gmail.com wrote:
Without a size parameter to `free`, an allocator needs to track the size
of allocations manually. It increases the memory overhead, along with
adding bookkeeping overhead.
Not by very much... If a chunk's header is
Passing the size to free is currently in a C++14 proposal [1]. It's pretty
useful (makes free no slower, might make it faster) and in most code, the
size is available on free. I'm not sure it would should be mandatory, but
it's definitely useful.
[1]
On 02/04/14 03:18 PM, Clark Gaebel wrote:
Passing the size to free is currently in a C++14 proposal [1]. It's
pretty useful (makes free no slower, might make it faster) and in most
code, the size is available on free. I'm not sure it would should be
mandatory, but it's definitely useful.
On 02/04/14 03:13 PM, comex wrote:
On Wed, Apr 2, 2014 at 12:25 PM, Daniel Micay danielmi...@gmail.com wrote:
Without a size parameter to `free`, an allocator needs to track the size
of allocations manually. It increases the memory overhead, along with
adding bookkeeping overhead.
Not by
On 02/04/14 03:13 PM, comex wrote:
On Wed, Apr 2, 2014 at 12:25 PM, Daniel Micay danielmi...@gmail.com wrote:
But is that really worth hanging language features on, one
way or the other?
This also isn't the only optimization lost here. Zero-size allocations
will need to be clamped to one if
At the moment, Rust is completely broken in this regard. The following
expression evaluates to None:
Some(~())
Ouch, this is a disaster.
Is there a bug filed for this?
Anyway, I don't get your argument about size to free having anything to do with
fixing it (although I agree that size to
Clamping `malloc(0)` to `malloc(1)` means that allocations of 0-size
types will no longer be free, which is sad. It's very useful to be able
to have meet the requirement of having a trait object and avoid any
memory allocation if there's no state.
The sentinel does work, but adds a branch to
Personally, I'm strongly against doing using ~[] as return values from
library functions.
Imagine we were in world were we only had VecT and were adding a new
type OwnedSliceT that was (pointer, length) like ~[T]. For how many
library functions would we say it is sensible to throw away the
On 4/2/14 2:51 PM, Huon Wilson wrote:
Specifically, I don't see any concrete positives to doing this for
library functions other than lets keep using ~[T] and ~[T] [T]
having the same in-memory representation (covered below).
Under any scheme I can think of, there are negatives:
1. without
On 03/04/14 08:54, Patrick Walton wrote:
On 4/2/14 2:51 PM, Huon Wilson wrote:
Specifically, I don't see any concrete positives to doing this for
library functions other than lets keep using ~[T] and ~[T] [T]
having the same in-memory representation (covered below).
Under any scheme I can
On Wed, Apr 02, 2014 at 04:03:37PM -0400, Daniel Micay wrote:
I have no sane proposal to fix this beyond passing a size to free.
I don't believe there is a problem with just not using null to
represent such pointers (for example, 1 would suffice). This does
impose some additional burdens on
On 02/04/14 07:22 PM, Niko Matsakis wrote:
On Wed, Apr 02, 2014 at 04:03:37PM -0400, Daniel Micay wrote:
I have no sane proposal to fix this beyond passing a size to free.
I don't believe there is a problem with just not using null to
represent such pointers (for example, 1 would suffice).
On Apr 2, 2014, at 8:35 AM, Alex Crichton a...@crichton.co wrote:
As a concrete example, I'll take the read_to_end() method on io's Reader
trait.
This type must use a VecT internally to read data into the vector, but it
will
return a ~[T] because the contents are conceptually frozen after
On Apr 2, 2014, at 3:01 PM, Huon Wilson dbau...@gmail.com wrote:
On 03/04/14 08:54, Patrick Walton wrote:
What about strings? Should we be using `StrBuf` as well?
I don't see why not. The same arguments apply.
I agree. I was actually quite surprised to see that the type was named StrBuf,
33 matches
Mail list logo
