On 5/2/14, Malthe Borch wrote:
> On 2 May 2014 00:06, Tony Arcieri wrote:
>> This sounds like the exact same painful failure mode as Ruby (transcoding
>> blowing up at completely unexpected times) with even more complexity,
>> making
>> it even harder to debug.
>
> Here is a concrete example of w
The encoding / glob. code in .NET works well , the strings use of
code-points is poor choice and both C# and Java suffer heavily for it
when doing IO.
Ropes / chords/ chains etc belong at a higher level not the lowest level
type.
Ben
On Fri, May 2, 2014 at 8:03 AM, John Downey wrote:
> I h
While i like auto magic eg you could let region analysis work out the
pointer type , borrowed pointers etc ,however you need to be very careful
. C# uses ref but autoboxing is a major issue , you dont know when the
struct is boxed ( there are some places besides the obvious virt call ) and
then y
He said IMHO ..
An explicit "new" is a huge indicator of what is going on ... most people
are familiar enough with stack allocation early adopters are not 9-5
developers..
Ben
On Tue, Nov 19, 2013 at 11:41 AM, Kevin Ballard wrote:
> Is that really why, or are you just guessing? I'm assuming
>
>
>
>
> In terms of the stack size check , as has been mentioned you can do
>> more with some analysis , each method gives an indication of worst
>> cases stack growth , these can then be added together to reduces checks
>> by 80% and hence significantly reduce the performance impact .
>>
>
>
>
> The big issue here then is really that rust tasks can be pre-empted, and
> therefore you can't guarantee that *any* function is free from blocking
> (which means you can't assign it a large stack, since it may go to sleep
> while holding it). IMO co-operative tasks (by default) is worth conside
On Tue, Oct 29, 2013 at 7:08 PM, Niko Matsakis wrote:
> If I understand correctly, what you are proposing is to offer fixed
> size stacks and to use a guard page to check for stack overflow (vs a
> stack preamble)?
>
> My two thoughts are:
>
> 1. I do think segmented stacks offer several tangible
Simon 1 thing you may want to test is 10-20 senders to 1 reciever.
Multiple senders have completely diffirent behaviour and can create a lot
of contention around locks / interlocked calls . Also checks what happens
to CPU when the receiver blocks for 100ms disk accesses every 100ms.
Disruptor as
Note pre fetch and non temporal instructions really help with this..
I'm not deeply familiar with Disruptor, but I believe that it uses bounded
>> queues. My general feeling thus far is that, as the general 'go-to' channel
>> type, people should not be using bounded queues that block the sender wh
Hi Simon ,
You may want to test the througput of tasks first to set a base line.
Disruptor is faster but normally runs in a tight loop ( or a yield loop) so
pretty much tying up a core ( even when yielding it will run again very
soon , its the fact that its always running which makes it very fas
object
with some more data which allows precise determination).
Why cant rust do precise marking , is it pointers to internal objects
rather than offsets ? All good modern GCs are precise/copying so not
having it is a big issue .
Ben Kloosterman
On Fri, Oct 25, 2013 at 2:39 AM, David
11 matches
Mail list logo
