Здравствуйте, gegMOPO4, Вы писали:
CC>>Почитал жижу чуть дальше. CC>>Мда... Дети, цветы жизни. CC>>Автор там редкостный неадекват.
MOP>Счастливый человек.
Ну у него похоже зуд на С++.
Спать мешает, кушать не даёт.
Несчастный человек.
Впрочем я видимо всё таки погорячился насчёт неадеквата.
В диспуте он себя пока проявил вполне адекватным.
Вот такое вот странное противоречие между постингами и обсуждением.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Это вовсе и не удивительно что на таком синтетическом тесте Лисп выиграл.
Попробуйте сделать более-менее реальную большую структуру данных и более долгоживущую программу.
Re[4]: сборка мусора в lisp против boost::shared_ptr
Здравствуйте, CreatorCray, Вы писали: CC>Впрочем я видимо всё таки погорячился насчёт неадеквата. CC>В диспуте он себя пока проявил вполне адекватным. CC>Вот такое вот странное противоречие между постингами и обсуждением.
Это его zabivator в предыдущем посте (Почему C++ — говно. В 10 пунктов.) вздрочнулосудил неподецки... Вот он и опасаецца тепереча.
Re[4]: сборка мусора в lisp против boost::shared_ptr
Здравствуйте, CreatorCray, Вы писали: CC>Ну у него похоже зуд на С++. CC>Спать мешает, кушать не даёт. CC>Несчастный человек.
Зато есть цель в жизни.
CC>Впрочем я видимо всё таки погорячился насчёт неадеквата. CC>В диспуте он себя пока проявил вполне адекватным. CC>Вот такое вот странное противоречие между постингами и обсуждением.
Хотел было ответить, указать на ошибки и как их избежать, но посмотрел на соседние посты — и понял, что это будет тщетно и неуместно.
Здравствуйте, gegMOPO4, Вы писали:
CC>>Ну у него похоже зуд на С++. CC>>Спать мешает, кушать не даёт. CC>>Несчастный человек. MOP>Зато есть цель в жизни.
У многих есть.
Но вносить в цель жизни обгаживание языка программирования по мне так достаточно сомнительное занятие.
CC>>Вот такое вот странное противоречие между постингами и обсуждением. MOP>Хотел было ответить, указать на ошибки и как их избежать, но посмотрел на соседние посты — и понял, что это будет тщетно и неуместно.
Дык там изначальный посыл в теме флеймогонный.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
А>http://love5an.livejournal.com/365174.html
До чего же некоторые идиотские идеи оказываются долгоживущими! Десять лет назад, когда я ходил на лекцию Дона Бокса, на которой он представлял новую, революционную платформу .NET, он ИМЕННО такой код предложил для доказательства того, что НЕТ лучше, чем С++:
Написал цикл, выделяющий в памяти маленький фрагмент сто тыщ миллионов раз сначала на плюсах, потом на Шарпе, скомпилировал, запустил — и вуля! Шарп выделяет маленькие объекты в сотни раз быстрее!
Ура, все переходим на Шарп — он очень быстрый.
Да здравствует мыло душистое и веревка пушистая.
Re[2]: сборка мусора в lisp против boost::shared_ptr
Здравствуйте, Vamp, Вы писали:
V>Написал цикл, выделяющий в памяти маленький фрагмент сто тыщ миллионов раз сначала на плюсах, потом на Шарпе, скомпилировал, запустил — и вуля! Шарп выделяет маленькие объекты в сотни раз быстрее!
Точно такие же "доказательства" когда то тут приводили шарписты.
Впрочем даже в таком говнотесте их в итоге по скорости обломали
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[3]: сборка мусора в lisp против boost::shared_ptr
CC>Точно такие же "доказательства" когда то тут приводили шарписты.
Не, ну о каких доказательствах речь? Известно, что стандартный new достаточно медленный, к тому же потокобезопасный, то есть с локами. Известно, что если ты будешь стандартным аллокатором аллоцировать сто тыщ мильонов мелких объектов, то будет небыстро.
Ну и что? Возьми любой из специальных аллокаторов, или напиши свой выделяющий объекты в предварительно выделенном огромном куске — в чем трудность-то?
Да здравствует мыло душистое и веревка пушистая.
Re[4]: сборка мусора в lisp против boost::shared_ptr
Здравствуйте, Vamp, Вы писали:
CC>>Точно такие же "доказательства" когда то тут приводили шарписты. V>Не, ну о каких доказательствах речь?
О смешных. Типа "посмотрите на мой говнокод и осознайте какое говно этот С++".
V>Известно,
Из сообщений ТАСС, надо полагать?
V>что стандартный new достаточно медленный
Ты делаешь ту же ошибку что и они.
Что такое "стандартный new" и почему он должен быть медленным? С точки зрения стандарта плз.
V> к тому же потокобезопасный, то есть с локами.
Чтоб быть потокобезопасным не обязательно использовать локи.
V> Известно, что если ты будешь стандартным аллокатором аллоцировать сто тыщ мильонов мелких объектов, то будет небыстро.
Нет стандартного, есть дефолтный из конкретной реализации CRT.
V>Ну и что? Возьми любой из специальных аллокаторов, или напиши свой выделяющий объекты в предварительно выделенном огромном куске — в чем трудность-то?
Дык ни в чём.
Просто они считают что generic аллокатор в поставке конкретной CRT (а как правило это аллокатор, предоставляемый ОС) это альфа, омега и часть С++.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[5]: сборка мусора в lisp против boost::shared_ptr
V>>Известно, CC>Из сообщений ТАСС, надо полагать?
Нет, из многолетней практики.
CC>Что такое "стандартный new" и почему он должен быть медленным? С точки зрения стандарта плз.
"Стандартный" — это такой, какой ты получишь по умолчанию в любой известной мне CRT в любой известной мне ОС.
CC>Чтоб быть потокобезопасным не обязательно использовать локи.
Необязательно. Тем не менее, в реализациях по умолчанию локи есть.
CC>Нет стандартного, есть дефолтный из конкретной реализации CRT.
Это и значит "стандартный". "Стандартный" — это не только тот, что в стандарте С++, это еще и "обычный", "наиболее распространенный", "по умолчанию". Мы все знаем, что детали поведения new в стандарте С++ не оговорены.
CC>Просто они считают что generic аллокатор в поставке конкретной CRT (а как правило это аллокатор, предоставляемый ОС) это альфа, омега и часть С++.
Это их личные половые трудности.
Кто-нибудь может объяснить, почему автор ЖЖ-поста использовал real показатель утилиты time, а не user, и почему так и нужно было делать? Может быть, там на этапе загрузки программы, библиотек и т.п. основная разница вылазит. Интересно, сильно поменяется картина, если к строке сборки g++ добавить -static?
To be is to be the value of a variable
Re[2]: сборка мусора в lisp против boost::shared_ptr
Здравствуйте, wvoquine, Вы писали: W>Кто-нибудь может объяснить, почему автор ЖЖ-поста использовал real показатель утилиты time, а не user, и почему так и нужно было делать? Может быть, там на этапе загрузки программы, библиотек и т.п. основная разница вылазит. Интересно, сильно поменяется картина, если к строке сборки g++ добавить -static?
Проблема автора не в этом, а том, что он заставляет C++ делать много совершенно не нужной бессмысленной работы, эмулируя реализацию на Lisp-е самым неэффективным способом. Этим он лишь показывает своё незнание C++.
Если же убрать всё лишнее, то останется только
int main(int, char**){return 0;}
А ещё лучше — вообще избежать запуска ничего не делающей программы. Мериться тут бессмысленно.
А мне вдруг интересно стало:
Вот, предположим, в программе на lisp мы навыделяли кучу объектов и, не предпринимая более ничего, завершились.
Будет ли GC вообще заниматься чисткой? Вроде же, проехали.
Если на C эту идею обрисовать, то примерно так вышло бы:
int main()
{
int i;
for (i = 0; i < 0x10000; ++ i)
{
malloc(16); //ни к чему жадничать :)
}
return 0; // никаких вам free!
}
