[M3devel] STL algorithms? sort/unique?

[Dragiša Durić]

Current heap allocation (thanks to Anthony) is much much faster than it used to be, as each thread has it's own "current page to alloc from". Not like stack alloc, but also not limited as stack alloc.

Your C++ compiler will cull those 60% of C++ standard? I can't wait to see it! :)

--
Divided by a common language

Dragiša Durić
dragisha at m3w.org




On Oct 3, 2012, at 4:39 PM, Jay wrote:

> Growable stack is basically nonsense.
> 
> 
> True that stack allocation has large downside that picking a stack size is impossible. But it is super fast.
> 
> 
> Once we have NT/C backend that doesn't use a thread local, & we have cooperative suspend,  I'd like to try writing an NT driver with Modula-3.. limited stack space there. :)
> (hm...what if we can't wrap the thread entry? Maybe ok.)
> 
> 
> Right, C++ is the answer, once I have my own compiler. :)
> 
> 
>  - Jay (briefly/pocket-sized-computer-aka-phone)
> 
> On Oct 2, 2012, at 12:53 PM, Dragiša Durić <dragisha at m3w.org> wrote:
> 
>> I don't need stack allocated object. 
>> 
>> I don't need to have lot's of big stacks in my multithreaded program. Can you implement growable stack? Is it worth your while?
>> 
>> I need even less a hassle of hand-selecting stack size, for threads where I need stack objects and other threads.
>> 
>> As Anthony said. At this time and age…  
>> 
>> I am sorry to even mention that, but maybe you just need C++? Or C++ without "a bit" of fat? Like..., 60% of language.
>> 
>> I think we just need even better collector that we currently have. One passing Mika's thread test :).
>> 
>> dd
>> 
>> On Sep 30, 2012, at 8:06 AM, Jay K wrote:
>> 
>>> I don't just want UNTRACED OBJECT.
>>> I also want stack allocated objects.
>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20121003/57903ef6/attachment-0002.html>