Честно говоря мутный тест, что на сайте D, что у них. Не ясно, включена ли во время инициализация runtime'а, не ясно что за контейнеры в версии U++ (как у них с многопоточностью, насколько «жадные» массивы), не ясно какая операция больше всего тормозит (может файловый ввод, а может поиск по map). И, в добавок, он двухлетней давности.
В целом Согласен на счёт GC, но иногда он в плюс, например он позволяет организовать дешёвые срезы массивов, это, на сколько я знаю, одна из основных причин, почему GC нельзя из D выпилить по-простому. А указатели в D тоже голые.
Когда я читаю про D, мне в нём всё почти нарвится. Но вот, я скачал DMD, плагин VisualD, создал проект HelloWord, запускаю:
Сначала он инициализирует чего-то там, секунд 5-10 (экран пуст), когда появляется заветная строчка, смотрю в менеджер программ: эта хрень отожрала 20 Mb! Не знаю чего они там понаделали, у D1 проблем не было, helloWorld памяти ел ~1Mb (приемлимо) и запускался мгновенно.
Ничего не мешает, но с попытка определить самые удачные моменты для запуска GC это тот ещё геморой, сомневаюсь что на уровне приложения можно подобрать эти моменты существенно лучше чем на уовне GC.
Вот с чем согласен, так это с ненужностью в C++ GC. Его наличие создаёт больше проблем чем решает. Если он будет, половина кода будет написана с его использованием, а половина – без. Разобраться в этом бараке будет ещё сложнее.
Собственно, главный плюс GC: он позволяет не следить за временем жизни объекта (только если единственный ресурс объекта – память). Ещё, если GC перемещающий, он автоматически борется с фрагментацией памяти. Минусы: непредсказуемые запуски GC, Перерасход памяти, сложность при взаимодействии с не GC кодом (читай с функциями на C), проблемы с концепцией деструкторов.
В общём, называйте меня закостенелым старпёром, но я предпочту старое доброе ручное управление памятью, без непредсказуемых запусков GC.
Наращивание количества ядер это, всё же костыль (хотя и не самый плохой). Некоторые принципиально важные алгоритмы не распаралеливаются (такие как бинарный поиск например).
Т.е. они могут выпустить хоть 16-ти ядерный процессор, поиск в базе данных быстрее от этого не станет.
И, возвращаясь к оценке «в 3 раза», это для такого-же количества ядер или удвоенного?
Что имеется в виду? Любопытно.
Сначала он инициализирует чего-то там, секунд 5-10 (экран пуст), когда появляется заветная строчка, смотрю в менеджер программ: эта хрень отожрала 20 Mb! Не знаю чего они там понаделали, у D1 проблем не было, helloWorld памяти ел ~1Mb (приемлимо) и запускался мгновенно.
Т.е., пока С++.
Собственно, главный плюс GC: он позволяет не следить за временем жизни объекта (только если единственный ресурс объекта – память). Ещё, если GC перемещающий, он автоматически борется с фрагментацией памяти. Минусы: непредсказуемые запуски GC, Перерасход памяти, сложность при взаимодействии с не GC кодом (читай с функциями на C), проблемы с концепцией деструкторов.
В общём, называйте меня закостенелым старпёром, но я предпочту старое доброе ручное управление памятью, без непредсказуемых запусков GC.
Про распараллеливание бинарного поиска, ниже, подробно написал mihaild. Об адекватности распараллеливания нетрудно догадаться самому.
То это не поможет. Почитайте про бинарный поиск что-ли.
То, что некоторые алгоритмы не распараллеливаются не говорит об их важности, но о старпёрском подходе к разработке или криворуком программисте.
То, что человек переходит на личности говорит о том, что у него кончились аргументы.
Т.е. они могут выпустить хоть 16-ти ядерный процессор, поиск в базе данных быстрее от этого не станет.
И, возвращаясь к оценке «в 3 раза», это для такого-же количества ядер или удвоенного?