Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Коллеги, объясните мне, что здесь происходит ? Какие реаллокации ? Линейный однонаправленный список в С/C++ на базе ссылочной реализации переворачивается без какого бы то ни было выделения памяти.
PD>Или я что-то не понял ?

Не,товарищи утверждают следующее
1. Версия с реаллокацей крута аки Чак Норрис, даже если фрагментирует все адресное пространтство
2. Реверс на месте невозможный рокет саенс, его можно только зазубрить, иначе нереально

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Однако построенный на них компилятор шарпа работает в разы быстрее нативного.

Ты забыл упомянуть, что он не производит никакой оптимизации, в отличие от нативного.

Здравствуйте, Pavel Dvorkin, Вы писали:

НС>>Однако построенный на них компилятор шарпа работает в разы быстрее нативного.

PD>Ты забыл упомянуть, что он не производит никакой оптимизации, в отличие от нативного.

Ты попутал Джыт и компилятор. Здесь речь про компилятор — cs.exe. Раньше он был на плюсах. Сейчас на шарпе. Выхлоп(il) у него не хуже плюсового, т.е. с оптимизациями все сильно, при этом работает намного быстрее.

Здравствуйте, Ikemefula, Вы писали:

I>Ты попутал Джыт и компилятор. Здесь речь про компилятор — cs.exe. Раньше он был на плюсах. Сейчас на шарпе. Выхлоп(il) у него не хуже плюсового, т.е. с оптимизациями все сильно, при этом работает намного быстрее.

Я не попутал, я просто считал, что cs делает перевод на IL без оптимизации, а оптимизирует JIT в применении к таргет платформе. Мне это тут несколько лет назад упорно доказывали, подчеркивая именно преимущество дотнета в плане последнего. Если сейчас иначе, спасибо за информацию. На C# я в последнее время практически не пишу.

То есть, если я тебя правильно понял, результирующий IL сильно отличается для Debug и Release ? И можно теперь просто так дебажить Release в студии без того, чтобы аттачиться к процессу, и видеть при этом реальный ассемблерный код "настоящего" Release ? Иными словами, JIT уже не оптимизирует, а просто транслирует IL в коды ?

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Я не попутал, я просто считал, что cs делает перевод на IL без оптимизации, а оптимизирует JIT в применении к таргет платформе. Мне это тут несколько лет назад упорно доказывали, подчеркивая именно преимущество дотнета в плане последнего. Если сейчас иначе, спасибо за информацию. На C# я в последнее время практически не пишу.

Оптимизации кое какие делаются даже при компиляции в il. Насколкьо круто сделана эта часть,я не в курсе, выхлоп у обоих версий компилера по моему одинаковый.

PD>То есть, если я тебя правильно понял, результирующий IL сильно отличается для Debug и Release ? И можно теперь просто так дебажить Release в студии без того, чтобы аттачиться к процессу, и видеть при этом реальный ассемблерный код "настоящего" Release ? Иными словами, JIT уже не оптимизирует, а просто транслирует IL в коды ?

Отличается. Что бы дебажить релиз и видеть IL надо ставить мульку, которая декомпилит, здесь ничего не изменилось. Джыт по прежнему оптимизирует, в новой версии обещают даже оптимизацию хвостовой рекурсии.

Здравствуйте, Ikemefula, Вы писали:

Тогда я не понял.

Вот это ты писал чуть выше

I>Здесь речь про компилятор — cs.exe. Раньше он был на плюсах. Сейчас на шарпе. Выхлоп(il) у него не хуже плюсового, т.е. с оптимизациями все сильно, при этом работает намного быстрее

А это сейчас.

I>Оптимизации кое какие делаются даже при компиляции в il. Насколкьо круто сделана эта часть,я не в курсе, выхлоп у обоих версий компилера по моему одинаковый.

Так кое-какие или же не хуже плюсового ? И что за 2 версии компилятора ? Или ты имел в виду Debug и Release ? Но тогда о какой оптимизации может идти речь, если выхлоп одинаковый ?

Здравствуйте, Pavel Dvorkin, Вы писали:

I>>Оптимизации кое какие делаются даже при компиляции в il. Насколкьо круто сделана эта часть,я не в курсе, выхлоп у обоих версий компилера по моему одинаковый.

PD>Так кое-какие или же не хуже плюсового ? И что за 2 версии компилятора ? Или ты имел в виду Debug и Release ? Но тогда о какой оптимизации может идти речь, если выхлоп одинаковый ?

Две версии — старая, cs.exe, на С++, и новая, cs.exe, на C#. Новая выходит в следующем году.

Здравствуйте, Ikemefula, Вы писали:

I>>>Оптимизации кое какие делаются даже при компиляции в il. Насколкьо круто сделана эта часть,я не в курсе, выхлоп у обоих версий компилера по моему одинаковый.

PD>>Так кое-какие или же не хуже плюсового ? И что за 2 версии компилятора ? Или ты имел в виду Debug и Release ? Но тогда о какой оптимизации может идти речь, если выхлоп одинаковый ?

I>Две версии — старая, cs.exe, на С++, и новая, cs.exe, на C#. Новая выходит в следующем году.

Из 2013 студии Preview ? То есть она оптимизирует C# сама ?

Здравствуйте, Pavel Dvorkin, Вы писали:

I>>Две версии — старая, cs.exe, на С++, и новая, cs.exe, на C#. Новая выходит в следующем году.

PD>Из 2013 студии Preview ? То есть она оптимизирует C# сама ?

Примерно так. Оптимизации будут примерно те же, что и раньше:
1 часть в комплайл тайм, cs.exe (компилятор C# -> IL)
2 часть в рантайме джытом

Разница только в том, что cs.exe переписали с C++ на C#

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Ты забыл упомянуть, что он не производит никакой оптимизации, в отличие от нативного.

Он производит как минимум не меньше оптимизаций, чем нативная версия (на самом деле несколько больше, но подробности пока NDA).

Здравствуйте, Ikemefula, Вы писали:

I>Две версии — старая, cs.exe, на С++, и новая, cs.exe, на C#.

csc.exe

I> Новая выходит в следующем году.

Ой не факт. Ну то есть 2014 студия скорее всего будет в следующем году, но вот будет ли там Розлин — я бы пока особо не рассчитывал.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Из 2013 студии Preview ?

Даже в 2013 RTM компилятор старый, абсолютно идентичный тому, что в 2012. Если хочешь посмотреть новый — http://www.nuget.org/packages/Roslyn

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Или я что-то не понял ?

Некоторые считают, что вменяемые в целом программисты могу ниасилить эту задачу.

Здравствуйте, Ikemefula, Вы писали:


I>То есть, вся твоя мега идея "VirtualAlloc" заключается в том, что есть два хипа — для малых и больших объектов. Один управляется либой, второй — виндой.

Слушай, почитай, как виндовые кучи работают и как сишные Мои идеи тут вообще не при чём.
В целом, раз ты не в состоянии корректно общаться -- учись сам...

I>Ты так и не смог показать, где и чем тебе помогает VirtualAlloc
Ну я постепенно понял, что тебе я ничего показать не смогу. Засим закругляю безнадёжные попытки.

I>Я показал тебе самый минимальный случай фрагментации — всего два куска. Меньше просто не бывает. Если VirtualAlloc не может разрулить этот самый простой случай, значит, что он тебе ничем помочь в принципе не может.

Тем не менее, программы под виндой рабтают и проблем, вроде описанного тобой ужоса не имеют Чудо, как оно есть, только и всего.

I>Ты помоему так и не понял, что такое адресное пространство.
Зато ты не понял, почему работают нормальные программы под виндой и не падают по ООМ из-за фрагментации АП, в отличии от твоих поделей

Здравствуйте, Erop, Вы писали:

I>>То есть, вся твоя мега идея "VirtualAlloc" заключается в том, что есть два хипа — для малых и больших объектов. Один управляется либой, второй — виндой.

E>Слушай, почитай, как виндовые кучи работают и как сишные Мои идеи тут вообще не при чём.

Уже давно почитал и тебе советую.

I>>Ты так и не смог показать, где и чем тебе помогает VirtualAlloc
E>Ну я постепенно понял, что тебе я ничего показать не смогу. Засим закругляю безнадёжные попытки.

Конечно не сможешь, потому что VirtualAlloc к дефрагментации АП никакого отношения не имеет, вообще.

I>>Я показал тебе самый минимальный случай фрагментации — всего два куска. Меньше просто не бывает. Если VirtualAlloc не может разрулить этот самый простой случай, значит, что он тебе ничем помочь в принципе не может.

E>Тем не менее, программы под виндой рабтают и проблем, вроде описанного тобой ужоса не имеют Чудо, как оно есть, только и всего.

Работают, и при этом винда НЕ умеет делать дефрагментацию АП внутри процесса, это умеет делать только GC.

I>>Ты помоему так и не понял, что такое адресное пространство.
E>Зато ты не понял, почему работают нормальные программы под виндой и не падают по ООМ из-за фрагментации АП, в отличии от твоих поделей

Мои — НЕ падают, при том что жрут вагон памяти.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Даже в 2013 RTM компилятор старый, абсолютно идентичный тому, что в 2012. Если хочешь посмотреть новый — http://www.nuget.org/packages/Roslyn

Им планируется заменить старый ? Когда ? Или он просто будет как еще один ?

Вообще-то я, конечно, согласен — никаких причин нет, мешающих сделать оптимизирующий компилятор с C#, нет. Насчет качества оптимизации — посмотрим. C++ компилятор MS доводила два десятка лет. А есть еще ICC...

Здравствуйте, Erop, Вы писали:

E>Зато ты не понял, почему работают нормальные программы под виндой и не падают по ООМ из-за фрагментации АП

Ещё как падают. Многие программы на 32-битной Винде падают именно из-за фрагментации АП, хотя свободной памяти достаточно. Из известных таких программ могу назвать браузеры Chrome и Firefox.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Им планируется заменить старый ?

Да.

PD> Когда ?

Скоро

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Не важно сколько их влезет в память. Даже один крупный пересоздаваемый список способен со временем фрагментировать весь доступный спейс.

Не факт. Периодически или же при невозможности найти подходящий непрерывный кусок памяти менеджер хипа занимается поиском и склейкой прилегающих пустых областей. При этом сами страницы упорядочиваются в иерархии по размерам по основанию двойки, т.е. склейка довольна дешева, две склеенные страницы образуют новую.

В общем, если будешь добавлять по 1-му символу в сишный вектор, то ничего военного не произойдет. Никакой дефрагментации. Освобождаемые предыдущие блоки памяти будут представлять собой непрерывный кусок незанятого места.

Здравствуйте, Erop, Вы писали:

I>>В который раз говорю — не затраты на переаллокации, а скорость потребления адресного пространства.

E>Оценки какие-то будут?..

E>ну, например, как ты думаешь, если вот тупо взять и написать на плюсах std::vector<char> и начать в него добавлять по одному, миллион символов добавить удостся?..

А ты этим что хотел доказать?

millioncharsvector.cpp

#if !defined(_IOSTREAM_) && !defined(_STLP_IOSTREAM) && !defined(__STD_IOSTREAM__) && !defined(_CPP_IOSTREAM) && !defined(_GLIBCXX_IOSTREAM)
    #include <iostream>
#endif

#if !defined(_VECTOR_) && !defined(_STLP_VECTOR) && !defined(__STD_VECTOR__) && !defined(_CPP_VECTOR) && !defined(_GLIBCXX_VECTOR)
    #include <vector>
#endif

#if !defined(_EXCEPTION_) && !defined(__EXCEPTION__) && !defined(_STLP_EXCEPTION) && !defined(__STD_EXCEPTION)
    #include <exception>
#endif

#if !defined(_STDEXCEPT_) && !defined(_STLP_STDEXCEPT) && !defined(__STD_STDEXCEPT) && !defined(_CPP_STDEXCEPT) && !defined(_GLIBCXX_STDEXCEPT)
    #include <stdexcept>
#endif

#ifndef WIN32_LEAN_AND_MEAN
    #define WIN32_LEAN_AND_MEAN
#endif

#ifndef STRICT
    #define STRICT
#endif

#if !defined(_WINDOWS_)
    #include <windows.h>
#endif



int main(int argc, char* argv[])
   {
    try{
        const int maxI = 1024*1024*1024;
        std::vector<char> v;
        for(int i=0; i!=maxI; ++i)
           {
            if (i && i%1024 == 0) std::cout<<"i = "<<i<<"\n";
            char ch = ' ' + (char)(i%64);
            //v.append(1, ch);
            v.push_back(ch);
           }
        std::cout<<"Char at random position: '"<<v[GetTickCount()%maxI]<<"'\n";

       }
    catch( const std::exception &e )
       {
        std::cout<<"Error: "<<e.what()<<"\n";
       }
    catch( ... )
       {
        std::cout<<"Error: unknown\n";
       }
    
    return 0;
   }

Результат

...
i = 689594368
i = 689595392
Error: bad allocation