Здравствуйте, Ikemefula, Вы писали:

S>>Решите ли вы не оценивать потери и не вкладываться в распараллеливание, если есть ненулевой шанс того, что конкуренты таки решатся?
I>Я тебе страшное скажу — вводить или не вводить параллельный алгоритм — такие вопросы обычно мусолятся постоянно и конкуренты здесь вообще ни при чем. Ты большей частью даже не знаешь, чем заняты конкуренты, а когда узнаёшь, это всегда два варианта — 1. они опередили 2. они опоздали.
Гуд

I>Чудеса параллельного программирования пока что сильно преувеличены. Большинство задач или плохо параллелятся, или дают такое усложнение, что качество само собой обваливается ниже плинтуса.
Я как бы в курсе, но всё идет именно к распараллеливанию, так как по частоте уже уперлись почти в потолок и для дальнейшего роста придется расти вширь

I>Просто шериданам всегда всё намного лучше известно, чем инженеру который 10 лет выжимает биты всеми возможными и невозможными способами.
Ты наверное по инерции думаешь, что я сейчас кого то чему то учу. Нет, не учу. Исторически сложилось так, что я выразил надежду

Автор: Sheridan
Дата: 29.05.15

, что программисты начнут писать многопоточный код, дабы обеспечить производительность своих продуктов. Следом была выражена позиция

Автор: Vain
Дата: 31.05.15

"программисты не осилят, там думать надо", и я начал программистов защищать

Автор: Sheridan
Дата: 31.05.15

, чай не дураки же они: возникнет такая необходимость — реализуют. Никого я ничему не учил

Здравствуйте, Ikemefula, Вы писали:

I>Никто в своём уме не говорит "я классный футболист-одиночка". Но вот в программировании такое почему то норма.
Я не говорю что я классный программист

Здравствуйте, cures, Вы писали:

C>Да, обычный порошок — он такой, нифига не отстирывает.
C>Можно попробовать платить ему деньги, в том числе и за то, чтобы не было глюков. Или платить — это уже экстремизм?
C>Кодер, кстати, вообще не должен париться с многопоточками, это прорабатывается уровнем выше, а кодер тупо кодит по спецификации.

Но нужен ли тогда вообще кодер? Не превышают ли времЕнные затраты на спецификацию выигрыш от использования кодеров?

M>>Ну пока погроммисты пишут на языках, неспособных хоть что-то внятно делать на этих ядрах (например, С++), то ничего не изменится.

А>А чо там за проблема у С++ с внятностью на ядрах? И какие языки следует выбрать для достижения внятности?

Можно начать с вопроса: Когда там потоки в С++ на уровне языка/стандартных библиотек появились?

M>Можно начать с вопроса: Когда там потоки в С++ на уровне языка/стандартных библиотек появились?

"Когда-то" и Путин сперматозоидом был.
Не уходим от вопроса.
Итак, что там у С++ за траблы с многопоточной невнятностью? И какие языки размалывают его по внятности?

Здравствуйте, Sheridan, Вы писали:

I>>Именно. В силу того, что ты пишешь в своё удовольствие, ты скорее всего проходишь мимо очень важных, но скучных, рутинных вещей, которые напрямую не связаны с результатом, например тестирование, проектирование, майнтенанс, суппорт. Что характерно, именно эти вещи дают наибОльшее количество экспириенса, в т.ч. даже в кодинге.
S>Ты говоришь о процессе разработки вообще, я же говорю только о его части — собственно, программировании.
S>Как, например, процесс саппорта дает опыт в программировании? Да, процесс влияет на результат (выясняем баги, пишем патчи), но сам процесс не дает такого опыта. То есть, опыт программирования появляется при правке багов, найденных при саппорте. Но этот опыт появляется не из за того, что мы саппортим продукт, а из за того, что приходится больше программировать.

Суппорт, майнтенанс учит тебя писать чище. Просто кодинг учит тебя писать быстрее.
Что бы писать чище приходится использовать другие подходы в разработке.
Чистота кодинга это the must для определенных областей в программировании, например в том же многопоточном, асинхронном и тд программировании. Хочешь прокачаться в глубину — нужно учиться писать без ошибок.

S>Это в ваших табелях о рангах какая ступень? Первая? Даже если нулевая — мне от этого ни холодно, ни жарко. Тот же перл не перекрывает мне часть своих возможностей из за этого

Разумеется, любую языковую фичу может попробовать даже новичок. Но это не значит, что тот же новичок понимает в программировании.

I>>Собтсвенно все твои разногласия с местными девелоперами именно отсюда — они уже прошли вот такое 'крещение' тестировщиками, майнтенансом и тд, а ты только пишешь в своё удовольствие.
S>Это зависть? Обида? Непонимание того как программирование может быть хобби?

Это факты. Охотник это не тот, кто лучше стреляет, а тот, кто две недели может ходить по болотам/в грязи/в пыли/в жару/в мороз, что бы сделать один единственный выстрел. Фотограф это человек, который способен месяцы ждать и тренироваться, что бы сделать один единственный кадр.

S>Неужели, если я завтра наймусь программистом куда нибудь, ко мне сменится отношение? Навыки то у меня останутся те же.

Прежде всего отношение к тебе из за твоих взгядов "разработчики дураки"(синдром болельщика).
Пойми одну вещь — команды болельщиков сильны только на трибунах. На поле такие команды сливают худшим из футбольных команд.
Если ты сможешь учиться, то научишься на тех фидбеках, которые тебе обеспечат тестировщики. Если нет, то разумеется, у тебя сохранится этот синдром болельщика.

Здравствуйте, Sheridan, Вы писали:

I>>Я тебе страшное скажу — вводить или не вводить параллельный алгоритм — такие вопросы обычно мусолятся постоянно и конкуренты здесь вообще ни при чем. Ты большей частью даже не знаешь, чем заняты конкуренты, а когда узнаёшь, это всегда два варианта — 1. они опередили 2. они опоздали.
S>Гуд

I>>Чудеса параллельного программирования пока что сильно преувеличены. Большинство задач или плохо параллелятся, или дают такое усложнение, что качество само собой обваливается ниже плинтуса.
S>Я как бы в курсе, но всё идет именно к распараллеливанию, так как по частоте уже уперлись почти в потолок и для дальнейшего роста придется расти вширь

Кроме распараллеливания есть возможность менять алгоритмы и переходить, скажем, на более другой матан и другие вычислительные модели. Например, в одной области клиент отдаёт часть обязанностей серверу, обработка речи. А в другой, наоборот, сервер отдаёт клиенту часть обязанностей, тот же рендеринг.

Здравствуйте, Sheridan, Вы писали:

S>Параллельное усреднение кучи изображений для видео (надо 30 кадров в секунду, имеем 1500 изображений, которые надо свести в эти 30 кадров) при помощи imagemagick и перла, с прогрессбаром тебя устроит?

Неа. Разделяемых данных опять практически нет, а без них это даже не 1% от сложности нормального многопоточного приложения, а скорее 0.01%. Твою задачу можно легко разнести даже по отдельным процессам.

Здравствуйте, Sheridan, Вы писали:

I>>Никто в своём уме не говорит "я классный футболист-одиночка". Но вот в программировании такое почему то норма.
S>Я не говорю что я классный программист

Ты в разных тредах пишешь разные вещи и слишком часто ухитряешься давать советы навроде "на сях быстрее", "надо распараллеливать". И до кучи, у тебя слишком много самых разных характеристик в адрес девелоперов.
Кроме того, ты меряешь в духе "лучше == быстрее", а между тем деньги платят за "лучше == корректнее". В первом случае тебе надо спускаться ажно на ассемблер, во втором надо изучать разные формальные модели, подходы и тд и тд и тд.

Если, скажем, распараллеливание создает проблемы с корректностью, то зачастую это вообще не рассматривается или цена решения вырастает сразу на несколько порядков.

То есть, дело не столько в уровне, сколько в совершенно экзотических ценностях, которые ты исповедуешь. Избавить от таких вот ценностей может только переход в разработку на фуллтайм, что бы ты полностью зависел от этого заработка.
Грубо говоря, как суровый африканский язычник плохо понимаешь, почему тупые католики-православные отказываются поедать своих врагов

Здравствуйте, Vain, Вы писали:

S>>Но, внимание, я ничего не решаю. Я не говорю за других. Я всего лишь сказал, что думаю что программистам рано или поздно придется писать многопоточно и считаю что программисты это потянут.
V>Программисты и так пишут многопоточно. Хоть один два потока приходится синхрить. Речь шла про 100500 ядер нагрузить.

https://msdn.microsoft.com/en-us/library/dd551463(v=vs.140).aspx
https://msdn.microsoft.com/en-us/library/hh750113.aspx
https://msdn.microsoft.com/en-us/library/dd492427.aspx

100500 не знаю, а десятки — легко.

Плюс доработка std::future<> в C++17 до АПИ, аналогичного jQuery Deffered или .Net Task:
http://bartoszmilewski.com/2014/02/26/c17-i-see-a-monad-in-your-future/

когда вместо блокирующего ожидания на примитивах синхронизации получаем роутинг событий, т.е. цепочку асинхронных обработчиков, порождающих других асинхронных обработчиков.

Так же идет обсуждение относительно добавления в C++ аналогов await.
http://blogs.msdn.com/b/vcblog/archive/2014/11/12/resumable-functions-in-c.aspx
http://blogs.msdn.com/b/vcblog/archive/2015/04/29/more-about-resumable-functions-in-c.aspx
http://meetingcpp.com/index.php/br/items/resumable-functions-async-and-await.html
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4134.pdf
https://msdn.microsoft.com/en-us/magazine/jj658968.aspx

Здравствуйте, Sheridan, Вы писали:

_>>Кто что думает? Что будет дальше?

S>Будут наращивать количество ядер (железные инженера) и распараллеливать задачи (погроммисты. Надеюсь.).

Я лет 10 назад покупал четырёхядерный процессор. Intel Core Quad, если мне память не изменяет. В то время мейнстримом были 2 ядра, но 4-ядерные уже были вполне популярны. Сейчас ситуация абсолютно идентична, 90% процессоров для персональных компьютеров 4-ядерные. Похоже это какое то оптимальное число и каких то перспектив по увеличению количества ядер в ближайшие годы я не вижу. При желании можно хоть щас поставить пару процессоров по 16 ядер, ща ещё и с хайпертрэдингом, но кому это надо?

Тут, скорее, прогресс будет идти по специализации процессоров. Сопроцессоры для типичных задач. Например для AES-шифрования в Intel давно есть специальные инструкции. Может быть сделают гибридные процессоры, которые приложение сможет перестраивать под свои нужды (например для видеокодировки).

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, Vain, Вы писали:

S>>>Но, внимание, я ничего не решаю. Я не говорю за других. Я всего лишь сказал, что думаю что программистам рано или поздно придется писать многопоточно и считаю что программисты это потянут.
V>>Программисты и так пишут многопоточно. Хоть один два потока приходится синхрить. Речь шла про 100500 ядер нагрузить.

V>https://msdn.microsoft.com/en-us/library/dd551463(v=vs.140).aspx
V>https://msdn.microsoft.com/en-us/library/hh750113.aspx
V>https://msdn.microsoft.com/en-us/library/dd492427.aspx

V>100500 не знаю, а десятки — легко.

В том то и дело, что нужны более серьезные инструменты, нежели нынешние, для десятка тредов.

vsb>Я лет 10 назад покупал четырёхядерный процессор. Intel Core Quad, если мне память не изменяет. В то время мейнстримом были 2 ядра, но 4-ядерные уже были вполне популярны. Сейчас ситуация абсолютно идентична

Идентична с одним исключением.
10 лет назад на каждом углу орали — вот, щас, когда многоядерность наконец-то стала быдлостандар мейнстримом, производители софта быренько отреагируют на это, и через года 3-4 мы будем скакать на многоядерниках аки Тор-громовержец.
Сейчас говорят — мдаа, не вышел каменный цветок, ну да и в топку эти ядра...

Здравствуйте, Ikemefula, Вы писали:

I>Кроме распараллеливания есть возможность менять алгоритмы и переходить, скажем, на более другой матан и другие вычислительные модели. Например, в одной области клиент отдаёт часть обязанностей серверу, обработка речи. А в другой, наоборот, сервер отдаёт клиенту часть обязанностей, тот же рендеринг.

Согласен, можно и так. Но через несколько итераций все равно путь приведет к многопоточности.

Здравствуйте, petr_t, Вы писали:

_>Неа. Разделяемых данных опять практически нет, а без них это даже не 1% от сложности нормального многопоточного приложения, а скорее 0.01%. Твою задачу можно легко разнести даже по отдельным процессам.

Ну тогда этот черновик посмотри, заодно по твоему ответу пойму что не так сделал, если не так

Здравствуйте, Sheridan, Вы писали:

I>>Кроме распараллеливания есть возможность менять алгоритмы и переходить, скажем, на более другой матан и другие вычислительные модели. Например, в одной области клиент отдаёт часть обязанностей серверу, обработка речи. А в другой, наоборот, сервер отдаёт клиенту часть обязанностей, тот же рендеринг.

S>Согласен, можно и так. Но через несколько итераций все равно путь приведет к многопоточности.

Часто бывает так, что если перекроить приложение, то можно найти более мирный способ увеличить производительность, нежели многопоточность. Например специализированые процессоры и тд.

Здравствуйте, Sheridan, Вы писали:

S>Здравствуйте, Ikemefula, Вы писали:


S>А теперь представь, на тех же условиях, что твоя контора пишет софт, подобие которого пишут еще несколько контор. Решите ли вы не вкладываться в распараллеливание, если есть ненулевой шанс того, что конкуренты таки решатся?

Всё время решаемся. Коммерчески, идея что-то распараллелить довольно дурацкая. Чем-то напоминает мексиканскую дуэль, когда первые трое параллельщиков проигрывают деньги.

А>10 лет назад на каждом углу орали — вот, щас, когда многоядерность наконец-то стала быдлостандар мейнстримом, производители софта быренько отреагируют на это, и через года 3-4 мы будем скакать на многоядерниках аки Тор-громовержец.
А>Сейчас говорят — мдаа, не вышел каменный цветок, ну да и в топку эти ядра...

Проблема не столько в ядрах, столько в том, что софт — включая ОСи — вообще неспособен эти ядра эффективно использовать. Наивный подход часто приводит к проседанию — и ощутимому — в производительности.

Как эту проблему решить правильно — хз. Потому что даже решения типа Grand Central Dispatch и им подобные — это костыли, а не решение.

V>100500 не знаю, а десятки — легко.

100500 уже нереально. С этим (первым?) столкнулся Erlang, которому, казалось бы, сам бог велел быть впереди планеты всей на этом фронте. Ан нет. Банальная синхронизация и менеджмент процессов на 100500 ядер накладывает нехилые проблемы, что приводит к жутким просаживаниям по производительности.

Здравствуйте, Ikemefula, Вы писали:

V>>100500 не знаю, а десятки — легко.

I>В том то и дело, что нужны более серьезные инструменты, нежели нынешние, для десятка тредов.

Тут хорошо бы уточнить, какие задачи подразумеваются. Если посмотреть на процессы, работающие на типичном десктопе, десяток тредов там норма, и понятно, что это ни о чем не говорит.