Спасибо за дельный комментарий. Ссылки на исходники находятся в конце статьи в разделе "Ресурсы". Настроек компиляции действительно пробовал мало. Но -march=native пробовал и разницы не заметил. Предварительно почитал рекомендации МЦСТ. Из описанных там опций компиляции увидел смысл только в двухфазной компиляции с профилем. У прочих настроек не увидел пользы для моего кода. Компилировал двумя способами: 1) g++ -Ox -march=native main.cpp -o main; 2) cmake --build . Файл CmakeLists.txt можете найти в исходниках. g++ давал мизерный (десятые доли процента), но стабильный плюс со всеми режимами оптимизации. Так что ошибка измерений исключена. Допускаю, что мог напутать с lcc/gcc. Тут мои познания достаточно скромные. А версию LLVM я указал не случайно. Путь к этой самой LLVM прописан в cmake-файле.
8С вряд ли пропишется в каком-нибудь офисе. Это скорее ЦП для серверов. 2С3 для офисов больше подходит. У него и однопоточая производительность значительно выше, раза в два - три.
Во-первых, Эльбрус 8С и Haswell практически одногодки. И с тех пор Эльбрусы прошли ещё два поколения. И по производительности они тоже хорошо прибавили. Во-вторых, Celeron G1820 не так уж и слаб в однопотоке. А тесты проводились как раз в однопотоке. Современные топовые ЦП, может, раза в три-четыре быстрее. Хотя с тем, что Эльбрусы сильно не дотягивают по производительности до современных топовых ЦП, спорить не стану.
И да и нет. Да, потому что реально крутая схема получения эффективного кода. Нет, потому что это надо делать в рантайме и JIT отнимает ресурсы у приложения, которое компилирует. Поищите на Ютубе доклад разработчиков JVM для E2K - ребят из ЮниПРО. Они подробно описали все сложности. Для языка Rast, например, доступен компилятор LLVM, который обладает преимуществами JIT, но может себе позволить долгий процесс компиляции, потому что offline. Для С++ вроде тоже такой вариант доступен. Как я понял, именно о нём и писал выше redf1sh. По сравнению с обычной компиляцией на С++ (через j++) java на Эльбрус 8С действительно очень сильно смотрится. Это я уже успел потестить.
Доступ к переменной parameters защищает модификатор private. Immutable был бы всё-ещё нужен, если бы нужно было отдавать всю мапу во вне, и тем самым давать возможность вносить изменения в неё вне класса Configuration. А в данном примере внести изменения в мапу можно только через setValue(). Так что immutable тут избыточен. Единственный профит, который тут даёт immutable, это барьер от соблазна ещё как-то модифицировать parameters в этом же классе, кроме как через setValue(). Если сделать метод getValue() synchronized, то и volatile можно будет убрать. Кстати, такой вариант мне кажется более правильным, т.к. к моменту входа в метод setValue()мы уже намерены внести изменения и рассчитываем, что другие потоки будут видеть их.
Насчёт компенсирования тупости ИИ скоростью размножения в категорически не соглашусь! Такое впечатление возникает только у нубов. Любой средний игрок развивается быстрее чем "невозможжный" ИИ. Ещё, кстати есть полезная функция - запись игры. Можно поставить компа себе в команду и потом на повторе разобрать детально его развитие.
Самое полезное назначение delete - это удаление артиллерии, крестьян, шахт при включённых опциях захвата. Когда играют равные противники захват шахты меняет ситуацию с ног на голову. Тот, у кого захватили шахту, вынужден срочно готовиться к атаке, пока противник не расплодил вторую ницию.
Ценность человеческого глаза и монитора, просто не сопоставима. Поэтому 11 пункт отпадает по принципу: на водке пропил, на спичках не сэкономишь. А вот 10-й сгодится, если у вас отключили электричество на пол дня, а вам край надо работать сейчас.
А это как раз для тех, кто из мира Delphi хочет перейти в мир Java. И вот вам реальный кейс. Я единственный java-разработчик конторе, где достаточно динамично меняется ПО. Остальные пишут на Delphi.
Требуется перевести старые проекты с Delphi на Java. Объём работы большой. Все разработчики постоянно загружены текущей работой, то есть пишут фичи для старых проектов, которые через год-два должны отправиться в мусорку.
Как бы вы решили эту задачу? На год перейти на разработку новых систем на Java всем отделом и пусть весь мир подождёт? К тому же параллельно нужно переучить разработчиков с Delphi на Java.
А вот моё решение. Писать все новые фичи на Java и встраивать в уже имеющиеся системы на Delphi. Начинаю пока в одиночку, постепенно подключая остальных разработчиков.
Я на каждом языке, который начинаю изучать, пишу задачу вычисления простых чисел (алгоритм по определению). Чистой воды числодробилка получается. Так вот, сравнение скорости с другими языками:
Java: Delphi -> 2: 1 (Intel), 6: 1 (AMD Vishera)
Java: C# -> 1: 1.25 (Intel), 1.75: 1 (AMD Vishera)
Обратите внимание на разницу при смене архитектуры. Не видел, чтобы кто-то сравнивал скорость одного кода на нескольких разных машинах, а это важно. Тестят всё на эталоне. JIT даёт огромное преимущество в сравнении с заточенным под одну архитектуру нативным кодом.
"… глазами учёного" и этим всё сказано. Вывод был предсказуем. Конечно это не языки виноваты, C++ и Pascal — языки для программистов, а не для учёных. Учёным лучше выбрать язык попроще и время на науку тратить, а не изучать ЯП по многу лет.
Здесь хотя бы мне отписался человек, который смотрел моё задание. Обычно приходится иметь дело с рекрутерами, которые ничего не могут объяснить. Так что даже приятно было читать такой ответ (хоть и с отказом) после пары общений с рекрутерами.
Я, кстати, тоже учился ещё на спектруме. Написал программу для решения уравнений методом дискриминанта. Тогда понял, что памяти впритык и начал изучать assembler.
Сейчас конечно гораздо проще учиться, но этого недостаточно для того, чтобы сразу стать мидлом, вот в чём проблема. Опыт работы ничем не заменишь.
...PGO попробую в ближайшее время. Допишу в статью, если будет толк.
Спасибо за дельный комментарий.
Ссылки на исходники находятся в конце статьи в разделе "Ресурсы".
Настроек компиляции действительно пробовал мало. Но -march=native пробовал и разницы не заметил. Предварительно почитал рекомендации МЦСТ. Из описанных там опций компиляции увидел смысл только в двухфазной компиляции с профилем. У прочих настроек не увидел пользы для моего кода. Компилировал двумя способами: 1) g++ -Ox -march=native main.cpp -o main; 2) cmake --build . Файл CmakeLists.txt можете найти в исходниках. g++ давал мизерный (десятые доли процента), но стабильный плюс со всеми режимами оптимизации. Так что ошибка измерений исключена.
Допускаю, что мог напутать с lcc/gcc. Тут мои познания достаточно скромные. А версию LLVM я указал не случайно. Путь к этой самой LLVM прописан в cmake-файле.
8С вряд ли пропишется в каком-нибудь офисе. Это скорее ЦП для серверов. 2С3 для офисов больше подходит. У него и однопоточая производительность значительно выше, раза в два - три.
Во-первых, Эльбрус 8С и Haswell практически одногодки. И с тех пор Эльбрусы прошли ещё два поколения. И по производительности они тоже хорошо прибавили. Во-вторых, Celeron G1820 не так уж и слаб в однопотоке. А тесты проводились как раз в однопотоке. Современные топовые ЦП, может, раза в три-четыре быстрее.
Хотя с тем, что Эльбрусы сильно не дотягивают по производительности до современных топовых ЦП, спорить не стану.
И да и нет. Да, потому что реально крутая схема получения эффективного кода. Нет, потому что это надо делать в рантайме и JIT отнимает ресурсы у приложения, которое компилирует. Поищите на Ютубе доклад разработчиков JVM для E2K - ребят из ЮниПРО. Они подробно описали все сложности.
Для языка Rast, например, доступен компилятор LLVM, который обладает преимуществами JIT, но может себе позволить долгий процесс компиляции, потому что offline. Для С++ вроде тоже такой вариант доступен. Как я понял, именно о нём и писал выше redf1sh.
По сравнению с обычной компиляцией на С++ (через j++) java на Эльбрус 8С действительно очень сильно смотрится. Это я уже успел потестить.
Доступ к переменной
parametersзащищает модификаторprivate. Immutable был бы всё-ещё нужен, если бы нужно было отдавать всю мапу во вне, и тем самым давать возможность вносить изменения в неё вне класса Configuration. А в данном примере внести изменения в мапу можно только черезsetValue(). Так что immutable тут избыточен. Единственный профит, который тут даёт immutable, это барьер от соблазна ещё как-то модифицироватьparametersв этом же классе, кроме как черезsetValue().Если сделать метод
getValue() synchronized, то и volatile можно будет убрать. Кстати, такой вариант мне кажется более правильным, т.к. к моменту входа в методsetValue()мы уже намерены внести изменения и рассчитываем, что другие потоки будут видеть их.Насчёт компенсирования тупости ИИ скоростью размножения в категорически не соглашусь! Такое впечатление возникает только у нубов. Любой средний игрок развивается быстрее чем "невозможжный" ИИ.
Ещё, кстати есть полезная функция - запись игры. Можно поставить компа себе в команду и потом на повторе разобрать детально его развитие.
Самое полезное назначение delete - это удаление артиллерии, крестьян, шахт при включённых опциях захвата. Когда играют равные противники захват шахты меняет ситуацию с ног на голову. Тот, у кого захватили шахту, вынужден срочно готовиться к атаке, пока противник не расплодил вторую ницию.
Требуется перевести старые проекты с Delphi на Java. Объём работы большой. Все разработчики постоянно загружены текущей работой, то есть пишут фичи для старых проектов, которые через год-два должны отправиться в мусорку.
Как бы вы решили эту задачу? На год перейти на разработку новых систем на Java всем отделом и пусть весь мир подождёт? К тому же параллельно нужно переучить разработчиков с Delphi на Java.
А вот моё решение. Писать все новые фичи на Java и встраивать в уже имеющиеся системы на Delphi. Начинаю пока в одиночку, постепенно подключая остальных разработчиков.
Java: Delphi -> 2: 1 (Intel), 6: 1 (AMD Vishera)
Java: C# -> 1: 1.25 (Intel), 1.75: 1 (AMD Vishera)
Обратите внимание на разницу при смене архитектуры. Не видел, чтобы кто-то сравнивал скорость одного кода на нескольких разных машинах, а это важно. Тестят всё на эталоне. JIT даёт огромное преимущество в сравнении с заточенным под одну архитектуру нативным кодом.
Сейчас конечно гораздо проще учиться, но этого недостаточно для того, чтобы сразу стать мидлом, вот в чём проблема. Опыт работы ничем не заменишь.