Каманин-то нет, а вот всякое вышестоящее начальство — запросто. Кстати, цитата этому никак не противоречит — оценка у всех одинаковая, но очерёдность всё-таки как-то определили. Думаю (правда, доказать не могу — нужно мемуары читать), что без влияния всяких партийных шишек тут не обошлось.
По мне так почти идеальная клавиатура у некоторых ноутов DEXP (типа Athena T105). Правда, про сами ноуты не знаю, и как-то не очень доверяю. А ещё лучше была бы стандартная клавиатура без цифрового блока. Но таких, по-моему, вообще нет.
Слово «actual», мне кажется, как бы намекает, что ошибки и раньше называли багами. А этот был первым настоящим.
Ракета Ariane 5: ущерб в 8,5 млрд долларов
Сами же пишете, что 8.5 млрд. — это вся программа, а конкретная ракета существенно дешевле. Вот если бы из-за этого бага закрыли всю программу, тогда да.
Слышал ещё версию, что свою роль сыграло происхождение — Гагарин из рабочей семьи, а Титов из интеллигенции. Но, скорее всего, выбирали по сочетанию всех факторов. И тут, конечно, Гагарин был идеальным первым космонавтом. Ужасно жаль, что ни ему, ни Титову так и не довелось больше слетать.
Всё это изящно поедается на бегу. В левой руке вы держите блюдо с рыбой, салфетку, нож и вилку (естественно, старого итальянского серебра), бокал с вином и корзину с фруктами, а в правой автомат, из которого отстреливаетесь от окончательно охреневшего противника.
Очень интересно, спасибо. Как я понимаю, отвязаться от кресла и поплавать в невесомости ему тоже не разрешили? Где-то читал, что Гагарин уж очень упрашивал Королёва разрешить ему, но, увы, решили перестраховаться (вполне понятное дело). С Титовым, видно, то же самое произошло.
Получить значение очередного блока памяти — это просто инкремент.
Инкремент чего? Хотя бы в двух словах. А то я никак не могу себе представить выделение памяти одним инкрементом (даже без GC).
Нет, GC непотокобезопасный, неинкрементальный, и вообще очень тупой. Однако, это не относится к теме. Я на различных бенчмарках гонял реализацию на malloc, и на gc_alloc, и тормоза были (как показал мне gprof) именно на вызовах malloc.
То есть вы сравнили потоконебезопасный GC с malloc'ом, который, не исключено, бОльшую часть времени тратит именно на блокировку. Не очень справедливо. Можно и malloc сделать игрушечный, который будет настоящий обгонять.
Т.к. у меня GC и так простейший и тупейший, ну ok, я бы сделал, чтобы все потоки ждали, пока GC отработает, сам бы GC работает в один поток.
И стал бы он у вас, скорее всего, ещё медленнее malloc'а.
Я не знаю, что такое виртуальное наследование. Я знаю, что для поддержки виртуальных вызовов используется механизм virtual tables. Так вот проблема в том, что у экземпляра класса, который наследуется от N других классов, будет N ссылок на virtual table. В Java есть свои сложности в реализации invokeinterface, но они решаются, причём без загаживания объекта списком vtableptr.
А вот за это спасибо. Правда, пришлось самому искать, как это в Java реализовано, но нашёл. В общем, это полностью отдано на откуп JVM, и вполне может быть реализовано как на C++. Но, например, в Orcale'овской реализации сделано так: указатель на инстанцию объекта (включая, видимо, и this) — это, на самом деле, пара указателей: собственно указатель на данные, и указатель на описание класса (в котором есть указатели на методы). Поэтому JVM, имея такой указатель, может скастовать его к любому классу-предку или интерфейсу. Таким образом, увеличивается вдвое указатель, но уменьшается память под данные объекта. Жалко, что такое нельзя сделать для C++, т.к. иначе, видимо, поломается ABI старых C-шных либ.
Можно в определённых средах, которые требуют особой упаковки библиотек. Не только VS, ещё и clang так может, если правильно собирать модули. Проблема в том, что в системе 100500+ имеющихся библиотек, которые уже упакованы в DLL или so.
Ну тут, увы, непреодолимый недостаток бинарного кода. Тут байт-код, конечно, выигрывает (если JVM, конечно, поддерживает такой инлайнинг).
1. Если вы аллоцируете много объектов (а сложное приложение аллоцирует много объектов), то в C++ запускается malloc, работающий сравнительно медленно. В GC аллокатор — это просто инкремент одного значения.
И какого же? А разве GC не должен искать блок подходящего размера? Откуда он возьмёт сам указатель на выделяемый блок памяти?
Что касается дальнейшего описания — вы точно сделали настоящий, потокобезопасный GC? Потому что сравнивать потокобезопасный malloc и игрушечный GC без потокобезопасности как-то странно.
2. Если у вас сложный граф объектов, то в C++ придётся использовать smart pointers. Это дополнительный расход памяти и дополнительные расходы на инкремент/декремент счётчиков. Да, в GC есть write barriers, но они не пишут в память, т.е. они быстрее (и локальнее по памяти).
Может быть, имеются в виду shared pointers? Потому что в smart никаких счётчиков нет, ибо на один объект может быть только один указатель.
3. GC (особенно перемещающий) делает ваши данные в памяти более локальными. В C++ есть серьёзные проблемы с дефрагментацией кэша, с которой отчаянно пытается бороться malloc. Привет, CPU cache!
А как НЕперемещающий GC может сделать данные более локальными?
4. При использовании множественного наследования в C++ получается два негативных эффекта: увеличивается размер заголовка каждого экземпляра такого класса, появляется оверхед на операцию == в некоторых случаях. В Java такой проблемы нет, т.к. множественное наследование возможно только на интерфейсах, и поэтому оно реализуется гораздо эффективнее.
При множественном наследовании нет никакого оверхеда. Данные объектов идут один за другим в памяти (возможно, с выравниванием). Вы не путаете с виртуальным наследованием?
5. В C++ нет возможности заинлайнить функцию из одного модуля в функцию из другого (если только не используется clang и модули не распространяются в виде биткода). Я так понимаю, основная масса моего /usr/lib — это всё-таки не биткод LLVM.
Можно как минимум в Visual Studio 2012 (и позже). Но, естественно, только если транслируются исходники модулей — из dll ничего заинлайнить нельзя. Про gcc не в курсе.
> Так вот, количество установок программы было ограничено тремя инсталляциями. Каждый раз при установке ПО в специальный файл на диске добавлялся маркер. Как только количество маркеров достигало трех, программу больше нельзя было устанавливать. Для того, чтобы владельцы дискеты ничего не могли изменить, разработчики просто убирали переключатель защиты от перезаписи.
А как тогда добавлялся маркер, если диск был защищён от записи?
> Условно, если вдруг все люди разом захотят самоубиться, это будет естественным отбором?
Найдутся те, которые не захотят — вот и отбор.
> Или вдруг две или больше стран решат поиграть в ядерную войнушку, и уничтожат тем самым большую часть популяции, это тоже будет естественным отбором?
Тут, конечно, поинтересней, но почему бы и нет? Раз такое затеяли, значит, недостаточно приспособленные. Добро пожаловать к динозаврам. Другие, пусть и потупей и попроще, займут наше место.
Я не специалист по биологии, но думаю, что относятся. Из Википедии: «Естественный отбор — основной эволюционный процесс, в результате действия которого в популяции увеличивается число особей, обладающих максимальной приспособленностью (наиболее благоприятными признаками), в то время, как количество особей с неблагоприятными признаками уменьшается». Ключевое слово — «в популяции». Т.е. рассматривается не просто отдельная особь, а вся популяция целиком. И тут родители и медицина очень даже влияют на успешность/приспособленность особи.
Против этого есть своеобразная игра. Когда несколько человек собираются вместе пообщаться, они кладут все свои мобилы в общую кучу в центр стола. Кто первый не выдерживает и берёт свой гаджет, тот платит за всех. Говорят, помогает.
Слово «actual», мне кажется, как бы намекает, что ошибки и раньше называли багами. А этот был первым настоящим.
Сами же пишете, что 8.5 млрд. — это вся программа, а конкретная ракета существенно дешевле. Вот если бы из-за этого бага закрыли всю программу, тогда да.
Инкремент чего? Хотя бы в двух словах. А то я никак не могу себе представить выделение памяти одним инкрементом (даже без GC).
То есть вы сравнили потоконебезопасный GC с malloc'ом, который, не исключено, бОльшую часть времени тратит именно на блокировку. Не очень справедливо. Можно и malloc сделать игрушечный, который будет настоящий обгонять.
И стал бы он у вас, скорее всего, ещё медленнее malloc'а.
А вот за это спасибо. Правда, пришлось самому искать, как это в Java реализовано, но нашёл. В общем, это полностью отдано на откуп JVM, и вполне может быть реализовано как на C++. Но, например, в Orcale'овской реализации сделано так: указатель на инстанцию объекта (включая, видимо, и this) — это, на самом деле, пара указателей: собственно указатель на данные, и указатель на описание класса (в котором есть указатели на методы). Поэтому JVM, имея такой указатель, может скастовать его к любому классу-предку или интерфейсу. Таким образом, увеличивается вдвое указатель, но уменьшается память под данные объекта. Жалко, что такое нельзя сделать для C++, т.к. иначе, видимо, поломается ABI старых C-шных либ.
Ну тут, увы, непреодолимый недостаток бинарного кода. Тут байт-код, конечно, выигрывает (если JVM, конечно, поддерживает такой инлайнинг).
И какого же? А разве GC не должен искать блок подходящего размера? Откуда он возьмёт сам указатель на выделяемый блок памяти?
Что касается дальнейшего описания — вы точно сделали настоящий, потокобезопасный GC? Потому что сравнивать потокобезопасный malloc и игрушечный GC без потокобезопасности как-то странно.
Может быть, имеются в виду shared pointers? Потому что в smart никаких счётчиков нет, ибо на один объект может быть только один указатель.
А как НЕперемещающий GC может сделать данные более локальными?
При множественном наследовании нет никакого оверхеда. Данные объектов идут один за другим в памяти (возможно, с выравниванием). Вы не путаете с виртуальным наследованием?
Можно как минимум в Visual Studio 2012 (и позже). Но, естественно, только если транслируются исходники модулей — из dll ничего заинлайнить нельзя. Про gcc не в курсе.
А как тогда добавлялся маркер, если диск был защищён от записи?
Найдутся те, которые не захотят — вот и отбор.
> Или вдруг две или больше стран решат поиграть в ядерную войнушку, и уничтожат тем самым большую часть популяции, это тоже будет естественным отбором?
Тут, конечно, поинтересней, но почему бы и нет? Раз такое затеяли, значит, недостаточно приспособленные. Добро пожаловать к динозаврам. Другие, пусть и потупей и попроще, займут наше место.