LINUX.ORG.RU

История изменений

Исправление SZT, (текущая версия) :

Давайте сразу проясним - я не воспринимаю этот тред как научную дискуссию ...

ОК.

Поскольку я числодробилками занимаюсь овер 20 лет, то мои оценки в некотором смысле можно считать экспертными - не в том смысле что я мегагуру, а в том смысле что я в этой области понимаю несколько больше чем какой нить бьюти-блогер;-).

Я тоже не бьюти-блогер и кое-что понимаю в обсуждаемой теме. Многопоточный код мне писать доводилось.

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

Поэтому я не обязан обосновывать каждое свое высказывание, у меня нет целей убедить Вас в чем либо (перейти на плюсы/дать мне денег), я просто делюсь опытом.

Хорошо, я вроде и не заставляю.

Кроме плюсов мэйнстримами являются как минимум ява, шарпы (ну были) и питон.

В области HPC или вообще?

Это все субъективно, а вот объем кода объективен (это число). ПРИ ПРОЧИХ РАВНЫХ тот ЯП лучше на котором код короче.

Да, с этим не поспоришь.

Плюсы большие, никто не мешает на них писать в С-стайле. Там много всего, это их благо и проклятие одновременно. Диалектика;-)

Да, но я б лично предпочел писать под контроллеры на D в режиме better-C (https://dlang.org/spec/betterc.html), чем на крестах.

Потому что это был оптимальный инструмент для решения этих задач с т.з. этих людей.

А может их точка зрения обусловлена не тем, что инструмент реально лучше по всем параметрам всех прочих вариантов, а потому что так принято считать? Может быть нужно провести какое-то объективное сравнение?

А если на ассемблере начать переписывать, переплюнуть можно наверняка!

Нет. Есть понятие теоретического предела производительности - и на него почти удалось выйти.

Нет, не почти. Говорю вам как человек, репортивший баги в багзиллу GCC с ключевым словом «missed-optimisation» Вообще, там таких багов достаточно много, и не только от меня. Сами посмотрите: https://gcc.gnu.org/bugzilla/buglist.cgi?keywords=missed-optimization&res...

Ну и с автовекторизацией все еще очень плохо, всякие интринсики приходится писать самому, не полагаясь на компилятор. Я уж не говорю о всяких полиэдральных моделях оптимизации циклов https://xeno-by.livejournal.com/28122.html - там вообще всё очень сложно, конца и краю этому не видно

С учетом того как хорошо на фортране сделаны некоторые вещи - предмет.

Ну ок, предмет так предмет.

Поскольку Вы ничего не знаете о этих задачах, то Вы и не можете ничего думать. Точнее думать то можете, но Ваше мнение абсолютно нерелевантно.

Ну хорошо, расскажите мне о тех задачах. Или вам лень тратить на меня своё время?

Исправление SZT, :

Давайте сразу проясним - я не воспринимаю этот тред как научную дискуссию ...

ОК.

Поскольку я числодробилками занимаюсь овер 20 лет, то мои оценки в некотором смысле можно считать экспертными - не в том смысле что я мегагуру, а в том смысле что я в этой области понимаю несколько больше чем какой нить бьюти-блогер;-).

Я тоже не бьюти-блогер и кое-что понимаю в обсуждаемой теме. Многопоточный код мне писать доводилось.

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

Поэтому я не обязан обосновывать каждое свое высказывание, у меня нет целей убедить Вас в чем либо (перейти на плюсы/дать мне денег), я просто делюсь опытом.

Хорошо, я вроде и не заставляю.

Кроме плюсов мэйнстримами являются как минимум ява, шарпы (ну были) и питон.

В области HPC или вообще?

Это все субъективно, а вот объем кода объективен (это число). ПРИ ПРОЧИХ РАВНЫХ тот ЯП лучше на котором код короче.

Да, с этим не поспоришь.

Плюсы большие, никто не мешает на них писать в С-стайле. Там много всего, это их благо и проклятие одновременно. Диалектика;-)

Да, но я б лично предпочел писать под контроллеры на D в режиме better-C (https://dlang.org/spec/betterc.html), чем на крестах.

Потому что это был оптимальный инструмент для решения этих задач с т.з. этих людей.

А может их точка зрения обусловлена не тем, что инструмент реально лучше по всем параметрам всех прочих вариантов, а потому что так принято считать? Может быть нужно провести какое-то объективное сравнение?

А если на ассемблере начать переписывать, переплюнуть можно наверняка!

Нет. Есть понятие теоретического предела производительности - и на него почти удалось выйти.

Нет, не почти. Говорю вам как человек, репортивший баги в багзиллу GCC с ключевым словом «missed-optimisation» Вообще, там таких багов достаточно много, и не только от меня. Сами посмотрите: https://gcc.gnu.org/bugzilla/buglist.cgi?keywords=missed-optimization&res...

С учетом того как хорошо на фортране сделаны некоторые вещи - предмет.

Ну ок, предмет так предмет.

Поскольку Вы ничего не знаете о этих задачах, то Вы и не можете ничего думать. Точнее думать то можете, но Ваше мнение абсолютно нерелевантно.

Ну хорошо, расскажите мне о тех задачах. Или вам лень тратить на меня своё время?

Исходная версия SZT, :

Давайте сразу проясним - я не воспринимаю этот тред как научную дискуссию ...

ОК.

Поскольку я числодробилками занимаюсь овер 20 лет, то мои оценки в некотором смысле можно считать экспертными - не в том смысле что я мегагуру, а в том смысле что я в этой области понимаю несколько больше чем какой нить бьюти-блогер;-).

Я тоже не бьюти-блогер и кое-что понимаю в обсуждаемой теме. Многопоточный код мне писать доводилось.

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

Поэтому я не обязан обосновывать каждое свое высказывание, у меня нет целей убедить Вас в чем либо (перейти на плюсы/дать мне денег), я просто делюсь опытом.

Хорошо, я вроде и не заставляю.

Кроме плюсов мэйнстримами являются как минимум ява, шарпы (ну были) и питон.

В области HPC или вообще?

Это все субъективно, а вот объем кода объективен (это число). ПРИ ПРОЧИХ РАВНЫХ тот ЯП лучше на котором код короче.

Да, с этим не поспоришь.

Плюсы большие, никто не мешает на них писать в С-стайле. Там много всего, это их благо и проклятие одновременно. Диалектика;-)

Да, но я б лично предпочел писать под контроллеры на D в режиме better-C (https://dlang.org/spec/betterc.html), чем на крестах.

Потому что это был оптимальный инструмент для решения этих задач с т.з. этих людей.

А может их точка зрения обусловлена не тем, что инструмент реально лучше по всем параметрам всех прочих вариантов, а потому что так принято считать? Может быть нужно провести какое-то объективное сравнение?

А если на ассемблере начать переписывать, переплюнуть можно наверняка!

Нет. Есть понятие теоретического предела производительности - и на него почти удалось выйти.

Нет, не почти. Говорю вам как человек, репортивший баги в багзиллу GCC с тегом missed-optimisation Вообще, там таких багов достаточно много, и не только от меня. Сами посмотрите: https://gcc.gnu.org/bugzilla/buglist.cgi?keywords=missed-optimization&res...

С учетом того как хорошо на фортране сделаны некоторые вещи - предмет.

Ну ок, предмет так предмет.

Поскольку Вы ничего не знаете о этих задачах, то Вы и не можете ничего думать. Точнее думать то можете, но Ваше мнение абсолютно нерелевантно.

Ну хорошо, расскажите мне о тех задачах. Или вам лень тратить на меня своё время?