Посмотрел я на бенчмарки и приуныл. Самый мощный на сегодня 4-ядерник 4790K уделывает аналогичный i7 четырехлетней давности аж на целых 25%.
На 25%, Карл! За 4 года и 2 новых техпроцесса/архитектуры. Раньше такой результат за 1 год считался провалом. Похоже, прирост производительности уже совсем закончился.
Кто что думает? Что будет дальше?
Здравствуйте, petr_t, Вы писали:
_>Кто что думает? Что будет дальше?
Будут наращивать количество ядер (железные инженера) и распараллеливать задачи (погроммисты. Надеюсь.).
В железе, емнип, уже практически к физическим пределам подошли, еще лет 10 назад толщина диэлектрика в транзисторах составляла 5-7 атомов, чего уж теперь...
Здравствуйте, petr_t, Вы писали:
_>Посмотрел я на бенчмарки и приуныл. Самый мощный на сегодня 4-ядерник 4790K уделывает аналогичный i7 четырехлетней давности аж на целых 25%. _>На 25%, Карл! За 4 года и 2 новых техпроцесса/архитектуры. Раньше такой результат за 1 год считался провалом. Похоже, прирост производительности уже совсем закончился. _>Кто что думает? Что будет дальше?
Есть законы физики — Ома, Кирхгофа, и т.д. — это глобальные (для всех эпох) понятия. Разряд молнии был задолго до того, как человечество стало применять электричество. Эти законы — объективны.
Закон Мура — это не глобальный, не объективный закон. Это только локальный (субъективный) закон. Его действие актуально только на время становления микропроцессорной/компьютерной техники. Теперь, когда вся эта техника уже прошла этап становления, данный закон просто умер. Это не хорошо и не плохо — это просто объективная реальность. Очевидно ведь, что до изобретения микросхем, говорить о действии закона Мура — бессмысленно. Теперь, когда данный стек технологических решений сформировался, рост стал минимален, данный закон потерял актуальность.
P.S. Аналогично, как человек бурно развивается и растёт в первие годы своей жизни, так и новая технология, появившись, развивается стремительно.
Однако, когда та же технология вступает в зрелый период развития, темпы роста значительно снижаются.
_>Уже давно наращивают. А толку? Число задач, где это дает реальный бенефит, можно пересчитать на пальцах одной руки.
А какие задачи требуют высокой прозводительности проца и при этом не дают себя бенефитно раскидывать по ядрам?
"Больше 100кмч можно ехать на автобане в любом ряду кроме правого крайнего" (c) pik
"В германии земля в частной собственности" (c) pik
"Закрывать школы, при нулевой смертности среди детей и подростков, это верх глупости" (c) Abalak
Здравствуйте, petr_t, Вы писали:
S>>Будут наращивать количество ядер (железные инженера)
_>Уже давно наращивают. А толку? Число задач, где это дает реальный бенефит, можно пересчитать на пальцах одной руки.
Фигурное цитирование в действии.
Я там еще про программистов писал.
Здравствуйте, Аноним931, Вы писали:
А>А какие задачи требуют высокой прозводительности проца и при этом не дают себя бенефитно раскидывать по ядрам?
Minecraft
На жабе писан, между прочим.
Здравствуйте, petr_t, Вы писали:
_>Посмотрел я на бенчмарки и приуныл. Самый мощный на сегодня 4-ядерник 4790K уделывает аналогичный i7 четырехлетней давности аж на целых 25%.
А ты сравнивал TDP на аналогичных задачах? А загруженность проца? А ты мерял производительность на СВОИХ задачах?
_>Кто что думает?
Думаю, вам, мой юный друг , предстоит ещё много понять о работе CPU. Для начала хотя бы то, что ни один бенчмарк НЕ ЯВЛЯЕТСЯ ОБЪЕКТИВНЫМ. Тупо показывает "попугаев в удаве". Поэтому говорить о преимуществе одного ЦПУ над другим (особенно в контексте покупки под своё железо) — некорректно.
Даже если вы увидете, что некий i7 обгоняет некий i3 на конкретном тесте в фотошопе, этот "выйгрыш" всё ещё обусловлен кучей факторов:
1. Насколько быстрые у них диски? А у вас? А есть ли смысл с вашими (допустим, медленными) дисками покупать мощный ЦПУ, который всё равно будет упираться в медленный I/O?
2. Как заточена система? Какого размера кэши? Сколько задач крутится параллельно?
Ну набрал i7 много попугаев, задавив другой ЦПУ на вещественных вычислениях. А сколько их у вас? Вы кодируете видео? Предсказываете погоду? Другими словами, их "усреднённый" бенч вообще ничего не говорит о том, какое преимущество получит проц именно на вашем железе и с вашими задачами. Может, там 4-канальный обмен с памятью, дающий вам сразу 200% прироста!
_> Что будет дальше?
ОЧЕНЬ надеюсь, что они сдвинут свои жирные, жадные задницы и займутся наконец оптическими вычислениями! Интерференция и всё такое. Даже, смешно сказать, оптоволокно — и то существует лет 15, но вот кабели — на тебе медь, развлекайся! А то, что всю эту тряхомудию из LPT/USB/HDMI/DP/Ethernet можно было заменить элементарной оптикой с ОДНИМ стандартом — не, "rocket science", как говорят в Решётах.
Здравствуйте, petr_t, Вы писали:
_>Самый мощный на сегодня 4-ядерник 4790K уделывает аналогичный i7 четырехлетней давности аж на целых 25%.
Ещё забыл: мой четырёхядерник/восьмикорошник 5-летней давности практически ПРОСТАИВАЕТ — раз в сто лет кто-то напряжёт одно из 8 ядер до 100% — на том и кончили. Есть ли смысл переживать, что сегодня кто-то быстрее "только" на 25%, когда мне и эти ресурсы ДЕВАТЬ НЕКУДА? Вот и думай...
Здравствуйте, btn1, Вы писали:
B>ОЧЕНЬ надеюсь, что они сдвинут свои жирные, жадные задницы и займутся наконец оптическими вычислениями! Интерференция и всё такое. Даже, смешно сказать, оптоволокно — и то существует лет 15, но вот кабели — на тебе медь, развлекайся! А то, что всю эту тряхомудию из LPT/USB/HDMI/DP/Ethernet можно было заменить элементарной оптикой с ОДНИМ стандартом — не, "rocket science", как говорят в Решётах.
Вот именно — заменим USB на оптику и будем каждый раз приваривать флешку "лазерным паяльником"... вот будет щассте...
Здравствуйте, petr_t, Вы писали:
_>Посмотрел я на бенчмарки и приуныл. Самый мощный на сегодня 4-ядерник 4790K уделывает аналогичный i7 четырехлетней давности аж на целых 25%. _>На 25%, Карл! За 4 года и 2 новых техпроцесса/архитектуры. Раньше такой результат за 1 год считался провалом. Похоже, прирост производительности уже совсем закончился. _>Кто что думает? Что будет дальше?
И увеличение числа ядер дальше четырёх на даёт прироста производительности на пользовательских задачах. Все, кому нужна производительность, переписывают свои алгоритмы под GPU. Тем более, что графические ускорители уже могут многое из того, что недавно было уделом процессоров общего назначения, а CUDA поддерживает С++11.
Здравствуйте, petr_t, Вы писали:
_>Посмотрел я на бенчмарки и приуныл. Самый мощный на сегодня 4-ядерник 4790K уделывает аналогичный i7 четырехлетней давности аж на целых 25%. _>На 25%, Карл! За 4 года и 2 новых техпроцесса/архитектуры. Раньше такой результат за 1 год считался провалом. Похоже, прирост производительности уже совсем закончился. _>Кто что думает? Что будет дальше?
Как я помню, этот эмпирический закон говорит только о количестве транзисторов. О производительности/стоимости/энергопотреблении в нём ничего не сказано.
Здравствуйте, AlexGin, Вы писали:
AG>Закон Мура — это не глобальный, не объективный закон. Это только локальный (субъективный) закон. Его действие актуально только на время становления микропроцессорной/компьютерной техники. Теперь, когда вся эта техника уже прошла этап становления, данный закон просто умер. Это не хорошо и не плохо — это просто объективная реальность. Очевидно ведь, что до изобретения микросхем, говорить о действии закона Мура — бессмысленно. Теперь, когда данный стек технологических решений сформировался, рост стал минимален, данный закон потерял актуальность. AG>P.S. Аналогично, как человек бурно развивается и растёт в первие годы своей жизни, так и новая технология, появившись, развивается стремительно. AG>Однако, когда та же технология вступает в зрелый период развития, темпы роста значительно снижаются.
Если «аналогично», значит закон вполне может оказаться объективным.
Здравствуйте, 0BD11A0D, Вы писали:
BDA>Здравствуйте, AlexGin, Вы писали:
AG>>P.S. Аналогично, как человек бурно развивается и растёт в первие годы своей жизни, так и новая технология, появившись, развивается стремительно. AG>>Однако, когда та же технология вступает в зрелый период развития, темпы роста значительно снижаются.
BDA>Если «аналогично», значит закон вполне может оказаться объективным.
Тогда, пожалуйста, уважаемый 0BD11A0D, расскажите мне и остальным коллегам, как закон Мура работал на протяжении последния двух тысяч лет...
Ведь если это объективный закон, то его действие не зависит — ни от самого человека, ни от творений человеческих рук.
Здравствуйте, AlexGin, Вы писали:
AG>>>P.S. Аналогично, как человек бурно развивается и растёт в первие годы своей жизни, так и новая технология, появившись, развивается стремительно. AG>>>Однако, когда та же технология вступает в зрелый период развития, темпы роста значительно снижаются.
BDA>>Если «аналогично», значит закон вполне может оказаться объективным. AG>Тогда, пожалуйста, уважаемый 0BD11A0D, расскажите мне и остальным коллегам, как закон Мура работал на протяжении последния двух тысяч лет... AG>Ведь если это объективный закон, то его действие не зависит — ни от самого человека, ни от творений человеческих рук.
Тогда, пожалуйста, уважаемый AlexGin, расскажите мне и остальным коллегам, что вы имели в виду, проведя аналогию между бурным (в данном случае, экспоненциальным) ростом числа транзисторов и бурным ростом человека в первые годы жизни. Если это не пустая аналогия, а объективный закон, последние две тысячи лет он работал в каждом поколении. Кроме того, бывают объективные законы, объектом которых служит человек (я не имею в виду уголовный кодекс). Действие этих объективных законов зависит от человека хотя бы в том смысле, что без человека законам не на чем себя проявлять.
Здравствуйте, btn1, Вы писали:
B>ОЧЕНЬ надеюсь, что они сдвинут свои жирные, жадные задницы и займутся наконец оптическими вычислениями! Интерференция и всё такое. Даже, смешно сказать, оптоволокно — и то существует лет 15, но вот кабели — на тебе медь, развлекайся! А то, что всю эту тряхомудию из LPT/USB/HDMI/DP/Ethernet можно было заменить элементарной оптикой с ОДНИМ стандартом — не, "rocket science", как говорят в Решётах.
Коммерческие системы на оптоволокне уже более 40 лет делают, а сам принцип был еще в 1934 году запатентован. Но тут такое дело, что оптические технологии хороши для передачи сигналов на большие расстояния, но для компьютера они видимо опоздали родиться. Оптические процессоры уже делали в конце 80-х — начале 90-х, но что-то они заглохли, да и сам посуди, сейчас CPU содержит более миллиарда транзисторов, что-то подобное на оптике не создать, преимущество оптики в скорости распространения света сомнительны, в лучшем случае это десяток процентов ускорения.
Кстати, от оптики, например, оптических аудиокабелей наоборот отказываются.
Здравствуйте, Sheridan, Вы писали: S>Будут наращивать количество ядер (железные инженера) и распараллеливать задачи (погроммисты. Надеюсь.).
Так не увеличивают же, как был i7-860 (Q3'09) с четырьмя ядрами и восемью нитями, так оно и осталось на десктопах. Про что, собственно, ТС и написал.
Главная причина, наверное, в том, что основной двигатель развития домашних компьютеров — игры — перешли на ускорение с помощью GPU, но и там уже несколько лет просматривается застой. И тенденция сильно урезать 64-битные вычисления, не нужные для игрушек. Даже последнее поколение Титанов это не обошло стороной.
S>В железе, емнип, уже практически к физическим пределам подошли, еще лет 10 назад толщина диэлектрика в транзисторах составляла 5-7 атомов, чего уж теперь...
Ну как чего, уходить от плоской модели, например, никто не мешает через сотню атомов сделать ещё десяток-другой таких же плоскостей. Да и выкинуть "видеокарту" из чипа процессора, не место ей в топовых камнях, там юзер себе нормальную видюху всё равно возьмёт. Ещё вариант — не лочить в тех же десктопных Скайлейках SSE-512. В общем, кушаем классическое поведение монополиста.
Здравствуйте, petr_t, Вы писали:
_>Посмотрел я на бенчмарки и приуныл. Самый мощный на сегодня 4-ядерник 4790K уделывает аналогичный i7 четырехлетней давности аж на целых 25%. _>На 25%, Карл! За 4 года и 2 новых техпроцесса/архитектуры. Раньше такой результат за 1 год считался провалом. Похоже, прирост производительности уже совсем закончился. _>Кто что думает? Что будет дальше?
Читал когда-то статью, если не путаю, то гонка частот в CPU закончилась в 2003 году, а гонка ядер в 2009. Но к GPU это не относится, так как процессоры видеокарт имеют отличающуюся от процессоров общего назначения архитектуру больше подходящую для распараллеливания. Опять же многие хвалят Intel, но новым стандартом стала архитектура amd64 и не спроста, так как она совместима с x86.
Иными словами не стоит ждать каких-то революционных изменений в железе, когда несколько десятков лет используются старые принципы и все на них подсели. Между тем очень большой интерес вызывают программы, которые и являются сутью ремесла программистов. Здесь даже на текущем железе огромное количество работы.
Ну, а дальше будут рекламные компании. Уже сейчас видно, что цены на комплектующие высоки даже в долларовом исчислении, тогда как рост показателей вычислительной мощи оставляет желать лучшего. Так же существует ряд коммерческих программ требующих дорогих компьютеров, и далеко не всегда обоснованно. Создаётся впечатление, что от версии к версии они становятся хуже.
В любом случае предел насыщения ещё не достигнут. Можно взять самую лучшую материнскую плату, процессоры, огромное количество оперативной памяти, самые быстрые видеокарты и так далее. При падении спроса просто снижать цену, и так в течении многих лет обновляя весь парк компьютеров.
Здравствуйте, velkin, Вы писали:
V>Читал когда-то статью, если не путаю, то гонка частот в CPU закончилась в 2003 году, а гонка ядер в 2009.
А почему закончилась гонка ядер? Не потому ли, что фактически остался один производитель?
V>Но к GPU это не относится
Ага, там их пока всё ещё два
V>Опять же многие хвалят Intel, но новым стандартом стала архитектура amd64
Но производительные процессоры с этой архитектурой выпускает таки Intel
V>Иными словами не стоит ждать каких-то революционных изменений в железе, когда несколько десятков лет используются старые принципы и все на них подсели.
Точно, во всём виноват фон-Нейман!
V>Между тем очень большой интерес вызывают программы, которые и являются сутью ремесла программистов. Здесь даже на текущем железе огромное количество работы.
Про это будут другие топики
V>Также существует ряд коммерческих программ, требующих дорогих компьютеров, и далеко не всегда обоснованно.
Надо признать, что если эти программы покупать не на рутрекере, то сколь угодно дорогие компьютеры для них покупаются на сдачу.
V>Создаётся впечатление, что от версии к версии они становятся хуже.
Всё верно, чтобы продолжать зарабатывать на них деньги, надо выпускать новые версии. А поскольку большинство пользователей вполне устраивают старые, а то и свободные аналоги, надо привлекать креативных десигнеров, которые будут думать о чём угодно, только не об улучшении программы и не об удобстве пользователей.
V>Можно взять самую лучшую материнскую плату, процессоры, огромное количество оперативной памяти, самые быстрые видеокарты и так далее.
Так некоторые делают, например та же Apple в десктопы ставит пару ксеонов и немало памяти. Получается дорого, покупают не все.
V>При падении спроса просто снижать цену, и так в течении многих лет обновляя весь парк компьютеров.
Или повышать цену, всё зависит от разных характеристик спроса, и не нам учить маркетологов коммерции
Здравствуйте, petr_t, Вы писали:
_>Посмотрел я на бенчмарки и приуныл. Самый мощный на сегодня 4-ядерник 4790K уделывает аналогичный i7 четырехлетней давности аж на целых 25%. _>На 25%, Карл! За 4 года и 2 новых техпроцесса/архитектуры. Раньше такой результат за 1 год считался провалом. Похоже, прирост производительности уже совсем закончился. _>Кто что думает? Что будет дальше?
Как раз про ядра и GPU писали выше. GPU еще есть куда гнаться, есть куча задач, которые элементарно распараллеливаются.
Как пример (если не ошибаюсь) — пиксельные и вершинные шейдеры.
Здравствуйте, omgOnoz, Вы писали:
O>Как пример (если не ошибаюсь) — пиксельные и вершинные шейдеры.
Не очень удачный пример, если Вы имеете в виду применение именно для графики. В этом GPU, несомненно, хороши, но это не удивительно, так как именно для этого они изначально и разрабатывались.
Есть куча других, вычислительных примеров, которые неплохо распараллеливаются, хотя бы то же Фурье для перемножения больших чисел, использующееся на mersenne.org. Но тут сразу появляются тонкости: не все йогурты GPU одинаково полезны, так как нужны 64-битные (дабловые) операции, которые в большинстве пользовательских карточек сильно порезаны (производительность на порядок хуже, чем у флотов, которые для этой задачи непригодны).
Но есть много задач, которые в варианте CUDA/OpenCl параллелятся очень плохо, а вот в обычном многоядерном варианте, где каждое ядро может независимо выполнять свои операции, параллелятся лучше. Но увы, большим количеством процессорных ядер производители домашнего пользователя не балуют. Возможно, спрос невелик, а с тех, кому такое надо, можно содрать много денег, продав им ксеоны.
Здравствуйте, petr_t, Вы писали:
_>Посмотрел я на бенчмарки и приуныл. Самый мощный на сегодня 4-ядерник 4790K уделывает аналогичный i7 четырехлетней давности аж на целых 25%. _>На 25%, Карл! За 4 года и 2 новых техпроцесса/архитектуры. Раньше такой результат за 1 год считался провалом. Похоже, прирост производительности уже совсем закончился. _>Кто что думает? Что будет дальше?
я вот буквально на днях собрал себе новую рабочую станцию на базе i7-5960X. Дык вот по скорости компиляции большого софта получается примерно в 2 раза быстрее, чем на i7-980X трехлетней давности. Так что все в порядке... Ну за исключением того, что редиски из интела "забыли" упоминуть, что 5960X слишком горяч для воздушного охлаждения и надо докупать жидкостное.
Здравствуйте, petr_t, Вы писали:
_>Толстолис, например
Это не задача, а программа. Как и упоминаемый дальше софт.
Задача выполнения многомегабайтных последовательных жабаскриптов, наверное, такая, но она искусственная.
Но если открыто много вкладок, и в каждой крутятся скрипты, то хром легко раскидается.
Или вот антивирусы, например Кошмарский, вполне могут сами разложиться по ядрам и отожрать их все
Здравствуйте, btn1, Вы писали:
B>Ещё забыл: мой четырёхядерник/восьмикорошник 5-летней давности практически ПРОСТАИВАЕТ — раз в сто лет кто-то напряжёт одно из 8 ядер до 100% — на том и кончили. Есть ли смысл переживать, что сегодня кто-то быстрее "только" на 25%, когда мне и эти ресурсы ДЕВАТЬ НЕКУДА? Вот и думай...
Похоже, ты и сам практически весь день простаиваешь. Иначе понял бы, что лаги/их отсутствие и 100% загрузка никак не связаны.
Здравствуйте, btn1, Вы писали:
B>1. Насколько быстрые у них диски? А у вас? А есть ли смысл с вашими (допустим, медленными) дисками покупать мощный ЦПУ, который всё равно будет упираться в медленный I/O?
Спасибо, Генерал Ясен Пень. Я уже давно купил быстрый SSD.
Здравствуйте, cures, Вы писали:
C>Здравствуйте, velkin, Вы писали:
V>>Читал когда-то статью, если не путаю, то гонка частот в CPU закончилась в 2003 году, а гонка ядер в 2009. C>А почему закончилась гонка ядер? Не потому ли, что фактически остался один производитель?
В наше время уже очень много производителей процессоров. Вот я, например, могу воспользоваться компьютером на GNU/Linux с архитектурой arm, ia64, sparc и для меня ничего не изменится, а пользователи Windows жёстко завязаны на x86 и amd64. Причём производители ПО уже начали разрывать их на части устраивая принудительные блокировки. Если посмотреть на рейтинги, то для многих и операционная система осталась только одна, а не только производитель процессора. Монополии нет, но есть сильное доминирующее влияние.
V>>Но к GPU это не относится C>Ага, там их пока всё ещё два
GeForce GTX TITAN Z
Графический процессор: 2 x NVIDIA GeForce GTX TITAN Z
Число универсальных процессоров: 5760
Понятное дело два GPU, да и в принципе можно ещё объединять до нескольких видеокарт, но суть в том, что количество ядер GPU превосходит CPU на три порядка. А всё потому, что архитектура изначально рассчитана на массивно параллельные вычисления.
V>>Опять же многие хвалят Intel, но новым стандартом стала архитектура amd64 C>Но производительные процессоры с этой архитектурой выпускает таки Intel
Для x86 и amd64 фактически два производителя Intel и AMD.
Здравствуйте, omgOnoz, Вы писали:
O>Как раз про ядра и GPU писали выше. GPU еще есть куда гнаться, есть куча задач, которые элементарно распараллеливаются.
GPU тоже близки к насыщению, судя по темпам прироста скорости.
Здравствуйте, cures, Вы писали:
C>Здравствуйте, bazis1, Вы писали:
B>> по скорости компиляции большого софта получается примерно в 2 раза быстрее, чем на i7-980X трехлетней давности.
C>В новом компе новые жёсткие диски на рейде? Или даже SSD?
4 интеловских SSD в RAID0. Что обидно, 2ГБ/с не получается, т.к. все упирается в ограничение PCI Express и выходит только 1.5. Я ожидал какой-то неземной скорости, как на видюхе от самсунга, но по ощущениям все просто быстро-шустро, но на ZOMG!!!111! не тянет. Большой проект в студии как открывался порядка 10 секунд, так и открывается. C>А может большой софт (или хотя бы его хидера) стал влазить в большое ОЗУ?
В скомпилированном виде проект занимает 19ГБ. Озу на старой машине — 24ГБ, так что влезало и раньше.
Я сомневаюсь, что дело в SSD или ОЗУ, т.к. загрузка процессора всегда около 100%. Если бы узким местом было бы что-то другое, CPU грузился бы меньше.
Здравствуйте, bazis1, Вы писали:
B>4 интеловских SSD в RAID0. Что обидно, 2ГБ/с не получается, т.к. все упирается в ограничение PCI Express и выходит только 1.5. Я ожидал какой-то неземной скорости
На самом деле, скорость SSD сильно падает на файлах небольшого размера. Так что неземной скорости в любом случае не будет.
B> Большой проект в студии как открывался порядка 10 секунд, так и открывается.
Вот в этом и проблема Какое железо ни покупай, даже открытие вкладки в браузере лагает достаточно сильно, чтобы это раздражало. Не говоря уже о студии с ее тормозами.
Здравствуйте, petr_t, Вы писали:
_>На 25%, Карл! За 4 года и 2 новых техпроцесса/архитектуры. Раньше такой результат за 1 год считался провалом. Похоже, прирост производительности уже совсем закончился.
Вообще то закон Мура касается не производительности, а количества транзисторов на кристалле или размера транзистора. А также энергоэффективности вроде производительности на ватт. Количество транзисторов по прежнему неплохо растет, в мобильных устройствах тоже производительность растет, не убивая батарейку. Да и производительность, например GPU — растет черти как по прежнему. В игрушках уже идет практически фотореализм.
А что все — это наращивание тактовой частоты все. Уперлись в невозможность охлаждения, узкое место в охлаждении. Но производительность можно поднимать, например, за счет параллелизма. Вот только тяжело это, охрененно. Потому большинство программ по существу параллелизм не использует, для производительности важна в основном тактовая частота, а также кеш.
Так что пока далеко не завершено действие этого закона.
Тут такая неприятность. 95% транзисторов процессора занимаются работой с памятью (в основном кеши разные), а не вычислениями. Таким образом количество ядер увеличить можно довольно легко, но им придется обрабатывать те же данные (причем так, чтобы одна строка кеша не переходила постоянно с одного ядра на другое), т.к. кешей на другие данные не хватит, а много быстрых ядер без данных в кеше работать будут совсем не быстро. И таких задач очень мало. Поэтому многоядерные процессоры бывают двух довольно специфических видов: GPGPU, где данные читаются их соседних ячеек глобальной памяти всеми ядрами одновременно в небольшую локальную память, и там их обрабатывают (кеши практически отсутствуют), либо большие компьютеры, у которых много ядер и ровно столько же каналов памяти (опять же кеши отсутствуют), которые также предназначены для весьма специфических задач.
Так что серьезного роста количества ядер в процессорах для решения широкого круга задач в ближайшее время не предвидится (без серьезного прорыва в какой-либо технологии, связанной с работой CPU). Нужно либо найти способ увеличить кеши на той же площади кристалла, либо научиться работать без них.
DR> Тем более, что графические ускорители уже могут многое из того, что недавно было уделом процессоров общего назначения,
Что именно, интересно? По моему опыту как были большим симдом, так большим симдом и остались. DR> а CUDA поддерживает С++11.
Только если ты на нем будешь писать как привык на обычном проце писать, то и работать будет медленнее, чем на обычном проце. + Не забывай, что там заметный прирост начинается только если у тебя достаточно дорогая видюха.
Здравствуйте, elmal, Вы писали:
E>Да и производительность, например GPU — растет черти как по прежнему.
Не заметно. Правило "подожди год-два и купи в 2 раза больше производительности за те же деньги" уже не действует.
E>В игрушках уже идет практически фотореализм.
Покажи мне хоть одну игрушку, в которой колеса и ландшафт не "квадратные".
Здравствуйте, Michael7, Вы писали:
M>Коммерческие системы на оптоволокне уже более 40 лет делают, а сам принцип был еще в 1934 году запатентован.
А уж колесо ...
M>Оптические процессоры уже делали в конце 80-х — начале 90-х, но что-то они заглохли
Там где делали, там ничего не глохнет. Оптические свитчи и роутеры никуда не пропали и продолжают развиваться.
M>да и сам посуди, сейчас CPU содержит более миллиарда транзисторов, что-то подобное на оптике не создать,
Почему?
M> преимущество оптики в скорости распространения света сомнительны, в лучшем случае это десяток процентов ускорения.
Дело не в скорости распространения сигнала в идеальных условиях, дело в отсутствии емкости и индуктивности оптических цепей. Что позволяет поднять частоты минимум на пару порядков.
M>Кстати, от оптики, например, оптических аудиокабелей наоборот отказываются.
Потому что для передачи мизерного аудиопотока преимущества оптики не нужны.
Здравствуйте, 0BD11A0D, Вы писали:
BDA>Здравствуйте, AlexGin, Вы писали:
AG>>>>P.S. Аналогично, как человек бурно развивается и растёт в первие годы своей жизни, так и новая технология, появившись, развивается стремительно. AG>>>>Однако, когда та же технология вступает в зрелый период развития, темпы роста значительно снижаются.
BDA>>>Если «аналогично», значит закон вполне может оказаться объективным. AG>>Тогда, пожалуйста, уважаемый 0BD11A0D, расскажите мне и остальным коллегам, как закон Мура работал на протяжении последния двух тысяч лет... AG>>Ведь если это объективный закон, то его действие не зависит — ни от самого человека, ни от творений человеческих рук.
BDA>Тогда, пожалуйста, уважаемый AlexGin, расскажите мне и остальным коллегам, что вы имели в виду, проведя аналогию между бурным (в данном случае, экспоненциальным) ростом числа транзисторов и бурным ростом человека в первые годы жизни. Если это не пустая аналогия, а объективный закон, последние две тысячи лет он работал в каждом поколении. Кроме того, бывают объективные законы, объектом которых служит человек (я не имею в виду уголовный кодекс). Действие этих объективных законов зависит от человека хотя бы в том смысле, что без человека законам не на чем себя проявлять.
В данном случае ИМХО аналогия такая — как человек растёт, появившись на свет в первые годы жизни, так и технология — в первые два-три десятилетия развивается очень бурно. Вот собственно и весь смысл. Будет другая технология — например био-компьютерная, когда компьютерные чипы будут вживлять в тело человека, она также сначала будет развиваться очень быстро. Ну а потом (когда на человеке живого места не останется) , ее развитие также затормозится.
Что же касается объективных законов, то сложно однозначно сказать — относится ли к ним закон Мура. На мой взгляд всё-таки не относится.
При этом, даже если и выявится, что закон Мура работает и сегодня, я вряд-ли соглашусь с тем, что этот закон объективен и глобален.
Не следует забывать, что его сформулировал один из основателей компании Intel. И сформулировал его — прежде всего в маркетинговых целях.
Так, если завтра компания Intel разориться — что будет?
Я уже и не говорю, что будет, если завтра (не дай Бог) на Землю упадёт громадный метиорит или грянет термоядерная война.
Здравствуйте, petr_t, Вы писали:
_>Не заметно. Правило "подожди год-два и купи в 2 раза больше производительности за те же деньги" уже не действует.
В долларах действует . Правда игрушки идут все более и более требовательные. Купишь видеокарту на которой все летает, через 2 года приходится думать о новой, уже на максимальных настройках идет не все.
_>Покажи мне хоть одну игрушку, в которой колеса и ландшафт не "квадратные".
The Last of Us. Heavy Rain. GTA 5. Assassin's Creed Unity. Alien Isolation. Crysis. Гонки, вроде Gram Turismo 6 и тому подобное — кроме мелких недочетов, по отдельным скриншотам хрен отличишь из игры это идет, или реальность. Кадры из игрушки — авиасимулятора черти какой давности на Украине выдавали за реальные фотографии, и в это верят даже программисты, не говоря уже об обывателях, далеких от ИТ. Мебель, кухни, интерьеры в квартирах в каталогах уже давно не реальные фотки, а тупо рендер, и фиг заметишь. Я затрудняюсь сказать в каком именно году графика подскочила до приемлемого уровня, но практически фотореализм был уже на консолях уровня PS3, на некоторых игрушках, некоторые я привел. С тех пор графическая мощь шагнула далеко вперед.
Здравствуйте, Аноним931, Вы писали:
_>>Уже давно наращивают. А толку? Число задач, где это дает реальный бенефит, можно пересчитать на пальцах одной руки.
А>А какие задачи требуют высокой прозводительности проца и при этом не дают себя бенефитно раскидывать по ядрам?
Распаралеливаются алгоритмы, которые имеют слабую зависимость по данным между итерациями/фазами. Идеально распараллеливаются алгоритмы, которые вообще не имеют такой зависимости, например рендеринг — здесь спокойно работают тысячи ядер в самой обычной настольной видеокарте. Конечно, эти ядра и близко не равносильны одному обычному из той же линейки х86.
Плохо распараллеливаются алгоритмы у которых сильная зависимость по данным, например поиск в глубину на графе, итерационные численные методы, скажем, с последовательным уточнением и тд.
Кроме того, эффект от распараллеливания разный и сложность алгоритма разная. В параллельных алгоритмах возникает, например, проблема балансировки нагрузки на процессоры и вообще управление вычислениями.
Разница не так уж и велика на деле. Не забываем при этом, что Crysis это довольно старая игра, с тех пор во многих играх получше сделано освещение, где нужно добавили размытости и тому подобное. Если у тебя не 100 процентное зрение, если не сидеть перед экраном и высматривать пиксели — далеко не сразу определишь рендер это или реальная фотка. Принципиально картинка лучше уже не будет в плане ландшафта. Пока еще в мало каких играх лица людей выглядят достаточно фотореалистично, пока чаще всего хорошо видно, что это не живой актер.
Здравствуйте, elmal, Вы писали:
E>Разница не так уж и велика на деле.
Чтобы разница не бросалась в глаза, надо иметь какие-то совсем жуткие проблемы со зрением.
К тому же ты подобрал картинку, где крызис выглядит достойнее всего.
Здравствуйте, Ночной Смотрящий, Вы писали:
M>>Оптические процессоры уже делали в конце 80-х — начале 90-х, но что-то они заглохли
НС>Там где делали, там ничего не глохнет. Оптические свитчи и роутеры никуда не пропали и продолжают развиваться.
А какое отношение они имеют к процессору?
M>>да и сам посуди, сейчас CPU содержит более миллиарда транзисторов, что-то подобное на оптике не создать,
НС>Почему?
Размеры излучателей, сложность их создания, это не вафлю выпечь.
M>> преимущество оптики в скорости распространения света сомнительны, в лучшем случае это десяток процентов ускорения.
НС>Дело не в скорости распространения сигнала в идеальных условиях, дело в отсутствии емкости и индуктивности оптических цепей. Что позволяет поднять частоты минимум на пару порядков.
Перспективы, конечно есть. Но уж больно там все непросто, если конкурировать с обычными процессорами. Начиная с того, что и тепловой шум будет мешать и потери на двойное преобразование (электричество-оптика-электричество).
На мой взгляд, раньше, чем действительно полностью исчерпаются возможности обычной полупроводниковой техники, не стоит ждать развития оптических процессоров.
НС>Потому что для передачи мизерного аудиопотока преимущества оптики не нужны.
Если говорить о стандартном оптическом входе, то как раз наоборот, его пропускной способности не хватает для современного 7.1 HD
Здравствуйте, Michael7, Вы писали:
НС>>Там где делали, там ничего не глохнет. Оптические свитчи и роутеры никуда не пропали и продолжают развиваться. M>А какое отношение они имеют к процессору?
Прямое. Любой процессор начинается с логики. А чтобы сделать именно процессор нужно еще как то изобрести оптическую память, с чем до сих пор имеются серьезные проблемы.
M>>>да и сам посуди, сейчас CPU содержит более миллиарда транзисторов, что-то подобное на оптике не создать, НС>>Почему? M>Размеры излучателей,
Излучателей много и не надо.
M> сложность их создания, это не вафлю выпечь.
Интегральные лазерные диоды делаются по тем же самым технологиям. См. Intel Light Peak для примера.
НС>>Дело не в скорости распространения сигнала в идеальных условиях, дело в отсутствии емкости и индуктивности оптических цепей. Что позволяет поднять частоты минимум на пару порядков. M>Перспективы, конечно есть. Но уж больно там все непросто, если конкурировать с обычными процессорами.
С обычными процессорами было тоже все очень непросто.
M> Начиная с того, что и тепловой шум будет мешать и потери на двойное преобразование (электричество-оптика-электричество).
Так вот и не надо лишний раз ничего преобразовывать, иначе действительно смысла в оптических процессорах немного.
M>На мой взгляд, раньше, чем действительно полностью исчерпаются возможности обычной полупроводниковой техники, не стоит ждать развития оптических процессоров.
Разумеется.
НС>>Потому что для передачи мизерного аудиопотока преимущества оптики не нужны. M>Если говорить о стандартном оптическом входе, то как раз наоборот, его пропускной способности не хватает для современного 7.1 HD
Там технологии уровня каменной дубинки. У Light Peak 1.6 Тб в секунду для сравнения.
Здравствуйте, petr_t, Вы писали:
_>Хром тормозит только самую чуточку меньше.
Он тормозит, но параллельно
_> А где ты возьмешь столько хороших программистов? Обычный типичный кодер даже с однопоточкой ухитряется накосячить.
Да, обычный порошок — он такой, нифига не отстирывает.
Можно попробовать платить ему деньги, в том числе и за то, чтобы не было глюков. Или платить — это уже экстремизм?
Кодер, кстати, вообще не должен париться с многопоточками, это прорабатывается уровнем выше, а кодер тупо кодит по спецификации. Хотя за зарплату кодера нанять в одном лице архитектора, манагера, прожект-лидера и разработчика — это мысль!
_> Вот в этом и проблема Какое железо ни покупай, даже открытие вкладки в браузере лагает достаточно сильно, чтобы это раздражало. Не говоря уже о студии с ее тормозами.
Так это точно не вопрос железа. "А потом мы выпили ещё фанты — и тормознули крутейший Core-i7!"
Здравствуйте, velkin, Вы писали:
V>В наше время уже очень много производителей процессоров.
При всём богатстве выбора, другой альтернативы нет...
V>Вот я, например, могу воспользоваться компьютером на GNU/Linux с архитектурой arm, ia64, sparc
ia64 и sparc — за совсем конские деньги? Ксеоны дешевле и быстрее. arm — это если считать не надо, слабенький он.
V>а пользователи Windows жёстко завязаны на x86 и amd64. Причём производители ПО уже начали разрывать их на части устраивая принудительные блокировки.
Забудем про "пользователей Виндовз", им ничего не надо. А что за блокировки? Так-то то же самое ПО под другую систему всегда приходилось покупать отдельно.
C>>Ага, там их пока всё ещё два V>Понятное дело два GPU
Я имел в виду, два производителя.
V>Для x86 и amd64 фактически два производителя Intel и AMD.
Формально может даже и 3, ещё VIA вспомним. Но если мы о быстрых вычислениях, то таки один. С бульдозером AMD упоролась, да так после этого и не оправилась. Теперь всякой фигнёй мается, пытается свою видюху внутрь процессора затолкать. В общем, ищет пятый угол.
Здравствуйте, alex19, Вы писали:
A> Нужно либо найти способ увеличить кеши на той же площади кристалла,
Внезапно, способ увеличить кэши на той же площади — это увеличить количество транзисторов, про который и есть закон Мура. Так вот он-то и прекратился, об чём и топик.
Опять же, ещё можно те транзисторы использовать именно для кэшей, а не для всякого мусора типа видео, но тоже низзя, ибо продукты для вычислений и для хомячков надо разводить по бабкам.
Ещё кэши можно выносить в третий-четвёртый уровни, но смотри предыдущий пункт.
В общем, Intel закон придумал, Intel же и отменил.
а где нужны приложения с параллельной архитектурой?
— сложные математические вычисления (суперкомпьютеры) — моделирование погоды, вселенной — здесь они нужны
— антивирусы сканирование — нужны и на персоналках
— базы данных — здесь всё упирается в саму базу данных — каков бы ни был размер кэша база хранится в единственном экземпляре на диске
— игры — здесь действительно как пишут многие используются GPU
Здравствуйте, cures, Вы писали:
V>>а пользователи Windows жёстко завязаны на x86 и amd64. Причём производители ПО уже начали разрывать их на части устраивая принудительные блокировки. C>Забудем про "пользователей Виндовз", им ничего не надо. А что за блокировки? Так-то то же самое ПО под другую систему всегда приходилось покупать отдельно.
При установке проверяется подходит ли операционная система под требования, такие как версия винды. Причём если подредактировать файлы, то всё ставится и на ту же XP с 32 битами. Но с теми же драйверами от той же NVidia всё гораздо сложнее. Технология NVidia 3D Vision в линуксе просто не будет работать. Да и даже в винде есть ограничения на одобренные игры, хотя давным давно во времена анаглифа можно было включить без проблем.
Собственно речь даже не о том, чтобы продать ПО второй раз, а просто тупо не дать поставить его на старую версию винды не получая с этого выгоды. А поскольку программы разные нужны, программы разные важны, при привыкании к неправильным продуктам пользователь оказывается заложником. Он стоит перед выбором, вот эта программа работает под этой версией винды, а вот это под другой, а вместе они работать не будут. Это я и называю разрывать на части.
Если же речь не о прикладных программах, а о драйверах, то и здесь проблемы. У меня в Windows XP и в линуксе не работает NVidia 3D Vision, потому что NVidia заблокировала эту возможность в драйверах. А в Windows 7 и Windows 8.1 NVidia 3D Vision работает, но не работает (NVidia) HDMI Audio, зато он работает в линуксе. Наблюдается ситуация, когда винда избавляется от поддержки не только нового, но и старого оборудования.
Производители программ тоже ведут себя как-то странно. Хотя если взять Steam от Valve, то он напротив подстраховывается и продаёт саму программу вне зависимости от операционной системы или устройства. В общем и целом правила потихоньку меняются. AMD никуда не денется, потому что теперь Intel платит ей деньги за архитектуру amd64, тогда как раньше AMD платила за x86.
Ускорение от Intel всё ещё идёт за счёт улучшения техпроцессов, хотя сдаётся мне скоро они уже нарвутся на предел. Ну и рейтинг процессоров в неких абстрактных величинах тоже не особо внушает. В общем посмотрим, домашние компьютеры за несколько сотен тысяч рублей в наше время больше похожи на разводку, чем на реальную необходимость.
Здравствуйте, AlexGin, Вы писали:
AG>Так, если завтра компания Intel разориться — что будет? AG>Я уже и не говорю, что будет, если завтра (не дай Бог) на Землю упадёт громадный метиорит или грянет термоядерная война.
А если мы нечаянно создадим черную дыру и засосем туда все Землю со всеми ее проводниками, полупроводниками и диэлектриками, закон Ома тоже перестанет быть объективным? Я просто логику понять не могу. Как вы их делите?
Здравствуйте, velkin, Вы писали:
V>Собственно речь даже не о том, чтобы продать ПО второй раз, а просто тупо не дать поставить его на старую версию винды не получая с этого выгоды.
Выгода есть, она в упрощении процесса разработки и тестирования, равно как и в удешевлении техподдержки.
Так пользователи винды сталкиваются с проблемой одного процента
V>при привыкании к неправильным продуктам пользователь оказывается заложником.
Привыкание — штука вообще неприятная. Но то, что нас не убивает — делает нас сильнее. Очень хороший повод посмотреть, что вокруг появилось нового.
V> AMD никуда не денется, потому что теперь Intel платит ей деньги за архитектуру amd64, тогда как раньше AMD платила за x86.
Как получатель денег от Intel — не денется, как производитель процессоров и конкурент — уже кирдык.
V>Ускорение от Intel всё ещё идёт за счёт улучшения техпроцессов,
Не только и не столько. За счёт техпроцесса последние лет 5 они не ускоряют процессоры, а снижают абстрактное энергопотребление. Скоро они во время интенсивных вычислений начнут замерзать
А ускорять десктопные процессоры им крайне невыгодно, тогда они начнут конкурировать с ксеонами, а там Intel давно расслабился, дерёт по 2 штуки за восьмиядерник и менять ничего не хочет, конкурентов всё равно нет.
Даже не то что ускорять, а хотя бы разрешить процессору поддерживать больше 32 Гигов памяти, и разрешить ставить 2 процессора на мамку — только в ксеонах. Ну ещё есть у них "полусерверное" семейство, на всякий случай — несовместимое ни с чем другим, где ограничения чуть слабее, там бывают и 6 ядер, и 64 Гига. Видимо, на нём обкатывают новшества.
V>домашние компьютеры за несколько сотен тысяч рублей в наше время больше похожи на разводку, чем на реальную необходимость.
Фор хум хау. Так-то и домашние компьютеры давно уже не нужны, подавляющему большинству их прежних пользователей хватает "сморфона" или планшета.
Здравствуйте, Sheridan, Вы писали:
_>>Кто что думает? Что будет дальше? S>Будут наращивать количество ядер (железные инженера) и распараллеливать задачи (погроммисты. Надеюсь.). S>В железе, емнип, уже практически к физическим пределам подошли, еще лет 10 назад толщина диэлектрика в транзисторах составляла 5-7 атомов, чего уж теперь...
Не поможет. Параллельное программирование (именно программирование на 100500 ядер а не то что сейчас) это тебе не гуюшечку писать. Там надо действительно мозгами работать и продумывать все до наносекунд. Промах по доступу к данным и мгновенный провал по скорости, если конечно приложение не взорвётся до этого от рассинхронизации.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, cures, Вы писали:
C>Можно попробовать платить ему деньги, в том числе и за то, чтобы не было глюков. Или платить — это уже экстремизм?
Вполне согласен, но это вопрос не ко мне. В любом случае, число людей, которые могут в многопоточность — крайне мало.
C>Кодер, кстати, вообще не должен париться с многопоточками, это прорабатывается уровнем выше
И каким образом ты "проработаешь выше" асинхронный вызов веб-запроса, к примеру?
C>Так это точно не вопрос железа. "А потом мы выпили ещё фанты — и тормознули крутейший Core-i7!"
Тоже верно. Но я как-то не надеюсь, что разработчики хромающего хрома и тормозиллы возьмутся за ум. Раньше их криворучие компенсировалось приростом производительности, но теперь уже нет.
Это в какой-то дикой постобработке кадр. Оно выглядит куда лучше без нее.
_>Получше, но все равно косяков хватает. Интересно, а косяк с возникающими из ниоткуда камнями и прочими мелкими объектами, по мере приближения к ним, уже исправили?
Косяк? Никакого косяка, это работа LOD. Причем его работа сделана лучше, чем в более ранних движках, т.к. объекты не появляются из ниоткуда, а, как бы так сказать, сначала штрихами рисуются, потом целиком. Это практически не напрягает в сравнении с внезапным появлением.
Я не разбирался, можно ли LOD оттянуть на бОльшее расстояние, но если можно, то с умеренным разрешением можно будет рендерить с очень большой дистанцией прорисовки.
Здравствуйте, Vain, Вы писали:
_>>>Кто что думает? Что будет дальше? S>>Будут наращивать количество ядер (железные инженера) и распараллеливать задачи (погроммисты. Надеюсь.). S>>В железе, емнип, уже практически к физическим пределам подошли, еще лет 10 назад толщина диэлектрика в транзисторах составляла 5-7 атомов, чего уж теперь... V>Не поможет. Параллельное программирование (именно программирование на 100500 ядер а не то что сейчас) это тебе не гуюшечку писать. Там надо действительно мозгами работать и продумывать все до наносекунд. Промах по доступу к данным и мгновенный провал по скорости, если конечно приложение не взорвётся до этого от рассинхронизации.
Ты считаешь, что программисты НАСТОЛЬКО плохи?
Даже я считаю, что в итоге осилят.
Здравствуйте, Don Reba, Вы писали:
DR>И увеличение числа ядер дальше четырёх на даёт прироста производительности на пользовательских задачах. Все, кому нужна производительность, переписывают свои алгоритмы под GPU. Тем более, что графические ускорители уже могут многое из того, что недавно было уделом процессоров общего назначения, а CUDA поддерживает С++11.
А переписывают под GPU, ВНЕЗАПНО, потому как в GPU 100500 ядер.
Здравствуйте, Sheridan, Вы писали:
V>>Не поможет. Параллельное программирование (именно программирование на 100500 ядер а не то что сейчас) это тебе не гуюшечку писать. Там надо действительно мозгами работать и продумывать все до наносекунд. Промах по доступу к данным и мгновенный провал по скорости, если конечно приложение не взорвётся до этого от рассинхронизации. S>Ты считаешь, что программисты НАСТОЛЬКО плохи? S>Даже я считаю, что в итоге осилят.
Ну тыж не программист чтобы так считать?
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, Vain, Вы писали:
V>Не поможет. Параллельное программирование (именно программирование на 100500 ядер а не то что сейчас) это тебе не гуюшечку писать. Там надо действительно мозгами работать и продумывать все до наносекунд. Промах по доступу к данным и мгновенный провал по скорости, если конечно приложение не взорвётся до этого от рассинхронизации.
Я так думаю, чтобы это взлетело, нужен прорыв в компиляторах. Потому что делать это всё вручную в массовых масштабах — нереально.
Здравствуйте, petr_t, Вы писали:
_>Я так думаю, чтобы это взлетело, нужен прорыв в компиляторах. Потому что делать это всё вручную в массовых масштабах — нереально.
Компилятор не превратит последовательный алгоритм в массивно-параллельный.
Здравствуйте, Vain, Вы писали:
V>>>Не поможет. Параллельное программирование (именно программирование на 100500 ядер а не то что сейчас) это тебе не гуюшечку писать. Там надо действительно мозгами работать и продумывать все до наносекунд. Промах по доступу к данным и мгновенный провал по скорости, если конечно приложение не взорвётся до этого от рассинхронизации. S>>Ты считаешь, что программисты НАСТОЛЬКО плохи? S>>Даже я считаю, что в итоге осилят. V>Ну тыж не программист чтобы так считать?
Ты хочешь сказать, что программисты настолько тупые, что неспособны писать многопоточно?
Здравствуйте, petr_t, Вы писали:
_>Пока что даже самый банальный асинхронный вызов и возврат данных (без косяков) осиливает максимум один из сотни.
Когда вариантов не останется — осилят все ))
Здравствуйте, Sheridan, Вы писали:
S>>>Ты считаешь, что программисты НАСТОЛЬКО плохи? S>>>Даже я считаю, что в итоге осилят. V>>Ну тыж не программист чтобы так считать? S>Ты хочешь сказать, что программисты настолько тупые, что неспособны писать многопоточно?
Нет, я считаю, что надо быть программистом, чтобы заявлять об этом во всеуслышание.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, Vain, Вы писали:
S>>>>Ты считаешь, что программисты НАСТОЛЬКО плохи? S>>>>Даже я считаю, что в итоге осилят. V>>>Ну тыж не программист чтобы так считать? S>>Ты хочешь сказать, что программисты настолько тупые, что неспособны писать многопоточно? V>Нет, я считаю, что надо быть программистом, чтобы заявлять об этом во всеуслышание.
Ну так ты и заявляешь. Я же наоборот, высказываю убежденность в том, что программисты осилят многопоточность рано или поздно.
Здравствуйте, Sheridan, Вы писали:
V>>>>Ну тыж не программист чтобы так считать? S>>>Ты хочешь сказать, что программисты настолько тупые, что неспособны писать многопоточно? V>>Нет, я считаю, что надо быть программистом, чтобы заявлять об этом во всеуслышание. S>Ну так ты и заявляешь. Я же наоборот, высказываю убежденность в том, что программисты осилят многопоточность рано или поздно.
Как человек не знающий о программировании в следствии своей профессиональной непрограммистской деятельности может по этому поводу высказывать убеждённость?
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, Algebroid, Вы писали:
A>а где нужны приложения с параллельной архитектурой?
Да собственно везде кроме десктопа. Самое очевидное — веб-фронтенд обслужит в два раза больше пользователей одновременно если ему дать в два раза больше ядер (если нет других узких мест естественно).
A>- сложные математические вычисления (суперкомпьютеры) — моделирование погоды, вселенной — здесь они нужны A>- антивирусы сканирование — нужны и на персоналках
Они как раз не нужны
A>- базы данных — здесь всё упирается в саму базу данных — каков бы ни был размер кэша база хранится в единственном экземпляре на диске
Вообще-то не обязательно в единственном.
A>- игры — здесь действительно как пишут многие используются GPU
Многие — это все.
Откуда же его [независимый суд] взять, если в нем такие же как мы? (c) VladD2
Здравствуйте, petr_t, Вы писали:
_>Я так думаю, чтобы это взлетело, нужен прорыв в компиляторах.
Скорее в языках.
_>Потому что делать это всё вручную в массовых масштабах — нереально.
Это да.
Откуда же его [независимый суд] взять, если в нем такие же как мы? (c) VladD2
Здравствуйте, SkyDance, Вы писали:
SD>Ха. Ну как тебе сказать. Я если без очков иду, у меня много чего возникает ниоткуда в этих самых 5-10 метрах
Вот поэтому: SD>На самом деле LOD там вполне неплох. Говорю же, не бросается в глаза.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, petr_t, Вы писали:
_> число людей, которые могут в многопоточность — крайне мало.
Нет ножек — нет мультиков. Пока им не готовы за это платить, они и не появятся. Точнее — не проявятся, предпочтут за ту же копейку лабать гуюшечки, их хоть много можно за то же время наваять.
_>И каким образом ты "проработаешь выше" асинхронный вызов веб-запроса, к примеру?
Кодер пишет код по спецификации. Проработать выше можно либо эти спецификации (тупо описать, что в каком порядке вызывать), либо соответствующие API, либо в сам язык примитивы засунуть, как сейчас модно. В крайнем случае, для написания этой части нанять более дорогого разработчика.
_> Но я как-то не надеюсь, что разработчики хромающего хрома и тормозиллы возьмутся за ум.
А им оно надо? Им не за это платят. Вы готовы платить серьёзные деньги за вылизывание браузеров, чтобы "разработчики" сайтов навалили вам ещё этого ароматного говнища типа скриптов и переливающихся банеров? Они же именно так и разрабатывают: берут мощный комп, и пока на нём сайт хоть как-то шевелится — пихают туда ещё радости.
Если что, elinks не тормозит.
Здравствуйте, Sheridan, Вы писали:
S>>>Ты считаешь, что программисты НАСТОЛЬКО плохи? S>>>Даже я считаю, что в итоге осилят. V>>Ну тыж не программист чтобы так считать? S>Ты хочешь сказать, что программисты настолько тупые, что неспособны писать многопоточно?
Шеридан!
Я с многопоточностью воюю уже лет семь, наверное.
Знаешь, я до сих пор не осилил: всё равно периодически допускаю ошибки синхронизации и падение производительности там, где теоретически она должна была бы вырасти.
Последующих поиск ошибок распаралеливания и синхронизации настолько сложная и нетривиальная задача, что я предпочитаю обходится без неё там, где без многопоточности можно обойтись.
Простой пример: в одном из 100 случаев не валидируются данные клиента. Такое нельзя отдебажить — в дебаге у тебя всё будет работать как часы. Нужно перечитывать код, и переделывать его так, чтобы ошибка стала очевидна. А это значительное время, и учитывая мою зарплату большие деньги. Если нет проблемы с производительностью, то лучшим выходом здесь будет отказ от многопоточности — проблема уйдёт сама собой.
А ты сам-то способен "писать многопоточно"?
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Vain, Вы писали:
V>Здравствуйте, Sheridan, Вы писали:
V>>>>>Ну тыж не программист чтобы так считать? S>>>>Ты хочешь сказать, что программисты настолько тупые, что неспособны писать многопоточно? V>>>Нет, я считаю, что надо быть программистом, чтобы заявлять об этом во всеуслышание. S>>Ну так ты и заявляешь. Я же наоборот, высказываю убежденность в том, что программисты осилят многопоточность рано или поздно. V>Как человек не знающий о программировании в следствии своей профессиональной непрограммистской деятельности может по этому поводу высказывать убеждённость?
Ок, ты видимо знаешь больше меня. Так как ты опровергаешь моё мнение о том, что программисты достаточно умны для того, чтобы осилить многопоточность, с этого момента, исходя из твоего мнения (мнения профессионала), буду считать, что программисты настолько тупы, что не могут осилить даже многопоточность.
Помоги только с пределами, пожалуйста. Очевидно же, не все программисты настолько тупы. Где границы твоего утверждения?
Здравствуйте, Философ, Вы писали:
Ф>Здравствуйте, Sheridan, Вы писали:
S>>>>Ты считаешь, что программисты НАСТОЛЬКО плохи? S>>>>Даже я считаю, что в итоге осилят. V>>>Ну тыж не программист чтобы так считать? S>>Ты хочешь сказать, что программисты настолько тупые, что неспособны писать многопоточно?
Ф>Шеридан! Ф>Я с многопоточностью воюю уже лет семь, наверное. Ф>Знаешь, я до сих пор не осилил: всё равно периодически допускаю ошибки синхронизации и падение производительности там, где теоретически она должна была бы вырасти. Ф>Последующих поиск ошибок распаралеливания и синхронизации настолько сложная и нетривиальная задача, что я предпочитаю обходится без неё там, где без многопоточности можно обойтись.
Я в курсе, что это сложно. Так же я в курсе, что это вполне осуществимо, хотя и сложно.
Так или иначе, но многопоточность придется использовать, иначе это сделают ваши конкуренты
Ф>Простой пример: в одном из 100 случаев не валидируются данные клиента. Такое нельзя отдебажить — в дебаге у тебя всё будет работать как часы. Нужно перечитывать код, и переделывать его так, чтобы ошибка стала очевидна. А это значительное время, и учитывая мою зарплату большие деньги. Если нет проблемы с производительностью, то лучшим выходом здесь будет отказ от многопоточности — проблема уйдёт сама собой.
Я нигде не писал, что это легко.
Ф>А ты сам-то способен "писать многопоточно"?
Ну, пока что получалось. Я совершенно не мегакрут в этом вопросе, но везде гле прикручивал многопоточность — везде работает. И да, пока что это потоки, которым как правило не нужно обмениваться данными.
Как правило это всевозможные скрипты, начиная от рекурсивного обхода сетей с подсетями и заканчивая скриптом, снимающего по 1 кадру раз в 30 секунд с нескольких камер в отдельности. Ну, и чтото многопоточное есть и там.
Здравствуйте, Sheridan, Вы писали:
S>Так или иначе, но многопоточность придется использовать, иначе это сделают ваши конкуренты
Так нет конкурентов. Просто потому, что на это нет спроса.
Никому не нужно что-то ускорять для пользователя, хотя бы потому, что пользователь всё равно выберет то, что красивее.
Тем более нет нужды париться с многопоточностью на десктопе, где 2, от силы 4 ядра, причём все они уже заняты антивирусами, скриптами во вкладках браузера и прочей мутью.
Никто же не требует ускорять кофемолку или пылесос.
S>Как правило это всевозможные скрипты
То есть для Вас вообще не критична производительность, иначе Вы бы легко ускорились на несколько порядков, переписав их на компилируемом языке. А многопоточность сделать там, где за взаимодействием надо следить, гораздо сложнее.
Здравствуйте, Vain, Вы писали:
V>Как человек не знающий о программировании в следствии своей профессиональной непрограммистской деятельности может по этому поводу высказывать убеждённость?
Он верит в человечество
Но он не так уж и неправ, будет надо — осилят.
Здравствуйте, cures, Вы писали:
C>Здравствуйте, Sheridan, Вы писали:
S>>Так или иначе, но многопоточность придется использовать, иначе это сделают ваши конкуренты C>Так нет конкурентов. Просто потому, что на это нет спроса.
Будет. Не завтра и не послезавтра, но спрос появится.
C>Никому не нужно что-то ускорять для пользователя, хотя бы потому, что пользователь всё равно выберет то, что красивее. C>Тем более нет нужды париться с многопоточностью на десктопе, где 2, от силы 4 ядра, причём все они уже заняты антивирусами, скриптами во вкладках браузера и прочей мутью. C>Никто же не требует ускорять кофемолку или пылесос.
Согласен, ты правильно говоришь. Но попробуй заглянуть чуть дальше вперед. По железу почти в предел уткнулись. А софту постоянно надо больше и больше, поэтому железо, хотя и перестало расти вверх (частоты), но стало расти вширь (ядра). Пока что ситуация нивелируется пногозадачностью, но рано или поздно, так или иначе, но придется, там где есть возможность, писать многопоточно. Просто потому, как другого выбора уже не будет, а конкуренты уже выпускают многопоточную бету.
S>>Как правило это всевозможные скрипты C>То есть для Вас вообще не критична производительность, иначе Вы бы легко ускорились на несколько порядков, переписав их на компилируемом языке. А многопоточность сделать там, где за взаимодействием надо следить, гораздо сложнее.
Согласен
Мне то там многопоточность нужна всего лишь, для примера, затем, что лень несколько процессов вручную запускать, а в одном потоке запрос к одной отвалившейся камере будет тормозить опросы остальных.
Здравствуйте, cures, Вы писали:
C>Кодер пишет код по спецификации. Проработать выше можно либо эти спецификации (тупо описать, что в каком порядке вызывать)
В этом случае, кодер просто не нужен.
C>либо соответствующие API, либо в сам язык примитивы засунуть, как сейчас модно.
А толку? Системы примитивов и API, чтобы можно было писать многопоточный код и нельзя было при это очень легко накосячить, попросту нет и не предвидится.
Здравствуйте, petr_t, Вы писали:
_>Здравствуйте, Sheridan, Вы писали:
S>>И да, пока что это потоки, которым как правило не нужно обмениваться данными.
_> _>В связи с нехваткой времени, сердечник трансформатора пока что делается из дерева, а индикаторы и переключатели нарисованы на передней панели.
Я как то про сердечник из дерева видел в реальной дипломной работе курса радиоэлектроники в училище. Там было по тексту чтото типа "...а сердечник трансформатора сделаем из хвойных пород древесины, потому что до этого места х... кто нибудь когда нибудь дочиатет...". Как утверждал преподаватель — выпускник сам пришел через 3 года после сдачи диплома и показал чего у него приняли.
Здравствуйте, Sheridan, Вы писали:
S>Будет. Не завтра и не послезавтра, но спрос появится.
Мы-то до коммунизма не доживём, а вот дети... детей жалко!
S>По железу почти в предел уткнулись. А софту постоянно надо больше и больше, поэтому железо, хотя и перестало расти вверх (частоты), но стало расти вширь (ядра).
Во-первых, вширь расти оно тоже перестало, с этого начался топик, уже больше пяти лет на десктопах максимум 4 ядра.
Во-вторых, софту надо больше и больше только потому, что пишут его всё кривее и кривее. Прежде, чем потребуется его ускорять за счёт многопоточности, из него нужно будет выкинуть ещё очень много глупости, а это никто не оплатит.
Ведь правда же, никто не требует ускорять кофемолки. Так же и с десктопами, свою задачу энтертеймента они уже выполняют, и кинишко можно глянуть, и в чятике потрещать, даже на самых слабых. И для этого уже не нужны и сами десктопы, телефоны вполне справляются, даже новейшие игрушки типа GTA-5 выходят сначала под них.
А для специальных нужд типа тяжёлых расчётов предлагается покупать специальные компы, за специальные деньги.
S>Пока что ситуация нивелируется пногозадачностью, но рано или поздно, так или иначе, но придется, там где есть возможность, писать многопоточно. Просто потому, как другого выбора уже не будет, а конкуренты уже выпускают многопоточную бету.
"Может, станут автоматы не глупее людей, но уж очень это будет невскорости."
Здравствуйте, cures, Вы писали:
C>Здравствуйте, Sheridan, Вы писали:
S>>Будет. Не завтра и не послезавтра, но спрос появится. C>Мы-то до коммунизма не доживём, а вот дети... детей жалко!
Рано или поздно...
S>>По железу почти в предел уткнулись. А софту постоянно надо больше и больше, поэтому железо, хотя и перестало расти вверх (частоты), но стало расти вширь (ядра). C>Во-первых, вширь расти оно тоже перестало, с этого начался топик, уже больше пяти лет на десктопах максимум 4 ядра.
sheridan@spc ~ $ cat /proc/cpuinfo| grep 8350
model name : AMD FX(tm)-8350 Eight-Core Processor
model name : AMD FX(tm)-8350 Eight-Core Processor
model name : AMD FX(tm)-8350 Eight-Core Processor
model name : AMD FX(tm)-8350 Eight-Core Processor
model name : AMD FX(tm)-8350 Eight-Core Processor
model name : AMD FX(tm)-8350 Eight-Core Processor
model name : AMD FX(tm)-8350 Eight-Core Processor
model name : AMD FX(tm)-8350 Eight-Core Processor
sheridan@spc ~ $ cat /proc/cpuinfo| grep 8350 | wc -l
8
C>Во-вторых, софту надо больше и больше только потому, что пишут его всё кривее и кривее. Прежде, чем потребуется его ускорять за счёт многопоточности, из него нужно будет выкинуть ещё очень много глупости, а это никто не оплатит.
Об этом я и так постоянно тут говорю, решил в этом треде не напоминать, а то совсем заплюют
C>Ведь правда же, никто не требует ускорять кофемолки. Так же и с десктопами, свою задачу энтертеймента они уже выполняют, и кинишко можно глянуть, и в чятике потрещать, даже на самых слабых. И для этого уже не нужны и сами десктопы, телефоны вполне справляются, даже новейшие игрушки типа GTA-5 выходят сначала под них.
Естественно, есть класс задач, к которымм вообще не прикрутить многопоточность. Я ж так и писал — "там, где есть возможность".
C>А для специальных нужд типа тяжёлых расчётов предлагается покупать специальные компы, за специальные деньги.
Про них вообще сейчас речи нет.
S>>Пока что ситуация нивелируется пногозадачностью, но рано или поздно, так или иначе, но придется, там где есть возможность, писать многопоточно. Просто потому, как другого выбора уже не будет, а конкуренты уже выпускают многопоточную бету. C>"Может, станут автоматы не глупее людей, но уж очень это будет невскорости."
Когда надо будет обеспечить рост производительности — вспомнят. Рано или поздно.
Здравствуйте, petr_t, Вы писали:
S>>model name : AMD FX(tm)-8350 Eight-Core Processor _>А толку? Даже 4 ядра не используются полноценно.
У меня все используются
Здравствуйте, DreamMaker, Вы писали:
S>>>model name : AMD FX(tm)-8350 Eight-Core Processor _>>А толку? Даже 4 ядра не используются полноценно.
DM>смотря какие задачи. DM>у меня тоже все ядра используются.
Судя по Философу, ты тоже жалок и смешон. Быть же такого не может, чтобы 4 ядра полноценно использовались. САМ Философ так сказал!
Здравствуйте, btn1, Вы писали:
B>Ещё забыл: мой четырёхядерник/восьмикорошник 5-летней давности практически ПРОСТАИВАЕТ — раз в сто лет кто-то напряжёт одно из 8 ядер до 100% — на том и кончили. Есть ли смысл переживать, что сегодня кто-то быстрее "только" на 25%, когда мне и эти ресурсы ДЕВАТЬ НЕКУДА? Вот и думай...
А зачем труба в унитазе такого диаметра? Большую часть времени она простаивает.
S>Судя по Философу, ты тоже жалок и смешон. Быть же такого не может, чтобы 4 ядра полноценно использовались. САМ Философ так сказал!
Как?! сам Философ?! ну все, пойду в океан топиться..
...давным давно, в докумпьютерную эпоху был анекдот. завхоз универа жалуется: "самое кошмарное — это физики и химики! это просто ужас какой-то, постоянно им нужны какие-то приборы, какое-то оборудование, без конца — никаких денег не напасешься! а вот математики — те намного лучше, им только бумага, карандаш и ластики нужны, прелесть! но лучше всех философы — им даже ластики не требуются!!"
прошли годы, математика стала вычислительной, стали нужные еще и компьютеры и ядра.
а вот у философов, судя по всему, все как в старые добрые времена
Здравствуйте, Sheridan, Вы писали:
V>>Как человек не знающий о программировании в следствии своей профессиональной непрограммистской деятельности может по этому поводу высказывать убеждённость? S>Ок, ты видимо знаешь больше меня. Так как ты опровергаешь моё мнение о том, что программисты достаточно умны для того, чтобы осилить многопоточность, с этого момента, исходя из твоего мнения (мнения профессионала), буду считать, что программисты настолько тупы, что не могут осилить даже многопоточность.
А что мешает не делать выбор в пользу тупости или не тупости?
S>Помоги только с пределами, пожалуйста. Очевидно же, не все программисты настолько тупы. Где границы твоего утверждения?
Пределы просты, программисты такие же работники как и все остальные. Но, чтобы понять выбор программистов, для начала надо самому таковым стать.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, Vain, Вы писали:
V>Здравствуйте, Sheridan, Вы писали:
V>>>Как человек не знающий о программировании в следствии своей профессиональной непрограммистской деятельности может по этому поводу высказывать убеждённость? S>>Ок, ты видимо знаешь больше меня. Так как ты опровергаешь моё мнение о том, что программисты достаточно умны для того, чтобы осилить многопоточность, с этого момента, исходя из твоего мнения (мнения профессионала), буду считать, что программисты настолько тупы, что не могут осилить даже многопоточность. V>А что мешает не делать выбор в пользу тупости или не тупости?
Даже не пробуй включать заднюю. Ты только назвал программистов тупыми. Не пытайся замять это.
S>>Помоги только с пределами, пожалуйста. Очевидно же, не все программисты настолько тупы. Где границы твоего утверждения? V>Пределы просты, программисты такие же работники как и все остальные. Но, чтобы понять выбор программистов, для начала надо самому таковым стать.
Вода, вода, вода. Ты пока что пределов не назвал, а попытался увести разговор в сторону, даже в две: 1. "Программисты тоже люди", что в общем то по умолчанию понятно. 2. "Шеридан не программист" — что тоже как бы общеизвестно. Почему то на основе этого делается вывод, что Шеридан (то есть я) не может решать чтототам за программиистов.
Но, внимание, я ничего не решаю. Я не говорю за других. Я всего лишь сказал, что думаю что программистам рано или поздно придется писать многопоточно и считаю что программисты это потянут.
Ты же внезапно со мной не согласился.
Так вот, повторю вопрос. Почему ты считаешь, что программисты тупые и где пределы?
Здравствуйте, Sheridan, Вы писали:
V>>А что мешает не делать выбор в пользу тупости или не тупости? S>Даже не пробуй включать заднюю. Ты только назвал программистов тупыми. Не пытайся замять это.
Это ты их назвал тупыми, я такого не говорил.
S>>>Помоги только с пределами, пожалуйста. Очевидно же, не все программисты настолько тупы. Где границы твоего утверждения? V>>Пределы просты, программисты такие же работники как и все остальные. Но, чтобы понять выбор программистов, для начала надо самому таковым стать. S>Вода, вода, вода. Ты пока что пределов не назвал, а попытался увести разговор в сторону, даже в две: 1. "Программисты тоже люди", что в общем то по умолчанию понятно. 2. "Шеридан не программист" — что тоже как бы общеизвестно. Почему то на основе этого делается вывод, что Шеридан (то есть я) не может решать чтототам за программиистов.
Всё верно
S>Но, внимание, я ничего не решаю. Я не говорю за других. Я всего лишь сказал, что думаю что программистам рано или поздно придется писать многопоточно и считаю что программисты это потянут.
Программисты и так пишут многопоточно. Хоть один два потока приходится синхрить. Речь шла про 100500 ядер нагрузить.
S>Ты же внезапно со мной не согласился. S>Так вот, повторю вопрос. Почему ты считаешь, что программисты тупые и где пределы?
Почему вы по утрам пьёте коньяк?
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, Sheridan, Вы писали:
S>model name : AMD FX(tm)-8350 Eight-Core Processor
Конечно, если процессор назвать Eight-Core, то у него точно будет восемь ядер
Проблема АМДшных "восьмиядерников" в том, что это не настоящие восемь ядер, а скорее то, что у Intel называется HyperThreads, может чуть лучше. У четырёхядерных Intel (которые с HT) тоже 8 энтрей в cpuinfo. Но и у тех и у других на два треда совмещено очень многое, просто Intel не пытается это назвать ядрами, а для AMD важнее маркетинг.
И АМД гораздо хуже работает с памятью, так что на вычислениях сливает четырёхядерникам Intel, но берёт более низкими ценами.
Здравствуйте, Vain, Вы писали:
V>Здравствуйте, Sheridan, Вы писали:
V>>>А что мешает не делать выбор в пользу тупости или не тупости? S>>Даже не пробуй включать заднюю. Ты только назвал программистов тупыми. Не пытайся замять это. V>Это ты их назвал тупыми, я такого не говорил.
Э, нет, не выйдет стрелки перевести. Я как раз таки говорил о том, что программисты разберутся и начнут писать многопоточно. Ты начал со мной не соглашаться.
S>>Но, внимание, я ничего не решаю. Я не говорю за других. Я всего лишь сказал, что думаю что программистам рано или поздно придется писать многопоточно и считаю что программисты это потянут. V>Программисты и так пишут многопоточно. Хоть один два потока приходится синхрить. Речь шла про 100500 ядер нагрузить.
Если так, то почему ты начал со мной не соглашаться?
Здравствуйте, cures, Вы писали:
C>Здравствуйте, Sheridan, Вы писали:
S>>model name : AMD FX(tm)-8350 Eight-Core Processor C>Конечно, если процессор назвать Eight-Core, то у него точно будет восемь ядер Ядра/потоки
AMD FX-8150
Intel Core i7-2600K
Intel Core i7-3820
Bulldozer
Sandy Bridge
Sandy Bridge-E
8/8
4/8
4/8
А вообще неплохо написано про бульдозер, предыдущую версию, там. Общий итог, грубо говоря — у модуля действительно два ядра, но большинство ресурсов общие, в отличии от интела, где ядро одно, но выполняет два потока.
C>Проблема АМДшных "восьмиядерников" в том, что это не настоящие восемь ядер, а скорее то, что у Intel называется HyperThreads, может чуть лучше. У четырёхядерных Intel (которые с HT) тоже 8 энтрей в cpuinfo. Но и у тех и у других на два треда совмещено очень многое, просто Intel не пытается это назвать ядрами, а для AMD важнее маркетинг. C>И АМД гораздо хуже работает с памятью, так что на вычислениях сливает четырёхядерникам Intel, но берёт более низкими ценами.
Но интел таки да, в тестах выигрывает, тут ты прав.
Здравствуйте, Sheridan, Вы писали:
V>>Это ты их назвал тупыми, я такого не говорил. S>Э, нет, не выйдет стрелки перевести. Я как раз таки говорил о том, что программисты разберутся и начнут писать многопоточно. Ты начал со мной не соглашаться.
не разберутся, и тебе уже ответили, и не потому-что тупые
S>>>Но, внимание, я ничего не решаю. Я не говорю за других. Я всего лишь сказал, что думаю что программистам рано или поздно придется писать многопоточно и считаю что программисты это потянут. V>>Программисты и так пишут многопоточно. Хоть один два потока приходится синхрить. Речь шла про 100500 ядер нагрузить. S>Если так, то почему ты начал со мной не соглашаться?
потому-что я слышу заявления от человека ничего не смыслящего в заявляемом
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
S>Minecraft
Вопрос был про задачи, а не про их конкретные (кривые) реализации. Итак?
"Больше 100кмч можно ехать на автобане в любом ряду кроме правого крайнего" (c) pik
"В германии земля в частной собственности" (c) pik
"Закрывать школы, при нулевой смертности среди детей и подростков, это верх глупости" (c) Abalak
Здравствуйте, Аноним931, Вы писали:
S>>Minecraft А>Вопрос был про задачи, а не про их конкретные (кривые) реализации. Итак?
Ну так я как бы тоже придерживаюсь мнения, что так или иначе большинство задач можно разложить на потоки
Здравствуйте, Vain, Вы писали:
V>>>Это ты их назвал тупыми, я такого не говорил. S>>Э, нет, не выйдет стрелки перевести. Я как раз таки говорил о том, что программисты разберутся и начнут писать многопоточно. Ты начал со мной не соглашаться. V>не разберутся, и тебе уже ответили, и не потому-что тупые
Я лучшего мнения о программерах, чем ты.
S>>>>Но, внимание, я ничего не решаю. Я не говорю за других. Я всего лишь сказал, что думаю что программистам рано или поздно придется писать многопоточно и считаю что программисты это потянут. V>>>Программисты и так пишут многопоточно. Хоть один два потока приходится синхрить. Речь шла про 100500 ядер нагрузить. S>>Если так, то почему ты начал со мной не соглашаться? V>потому-что я слышу заявления от человека ничего не смыслящего в заявляемом
То есть интересная морковка получается: я прав, но я неправ
Здравствуйте, Sheridan, Вы писали:
S>>>Даже я считаю, что в итоге осилят. V>>Ну тыж не программист чтобы так считать? S>Ты хочешь сказать, что программисты настолько тупые, что неспособны писать многопоточно?
Многопоточный код писать сложнее чем обычный. Даже если ты потратишь на это годы, всё равно обычный линейный код будет писаться быстрее всего.
var x = a + b;
В многопоточном коде такая вот задачка вынуждает подумать, что же такое a и b, не юзает ли их ктото еще.
В задачах посложнее надо думать об общей загрузке системы. Если она недостаточная, то это отстой. Если чрезмерная, то это отстой.
В том, что такой код люди уже осилили, сомневаться не нужно — видеокарты, кластеры всех сортов и тд работают очень достойно.
Тем не менее, по прежнему простой однопоточный линейный код писать легче и быстрее всего
Здравствуйте, Ikemefula, Вы писали:
I>Многопоточный код писать сложнее чем обычный. Даже если ты потратишь на это годы, всё равно обычный линейный код будет писаться быстрее всего. I>....[skip]
Блин, да знаю я это. Я что, говорю, что будет проще? Нет.
Здравствуйте, Sheridan, Вы писали:
I>>Многопоточный код писать сложнее чем обычный. Даже если ты потратишь на это годы, всё равно обычный линейный код будет писаться быстрее всего. I>>....[skip]
S>Блин, да знаю я это. Я что, говорю, что будет проще? Нет.
Вопрос — чем придется заплатить за лишнюю сложность софта ?
Не читайте до обеда советских газет. Впрочем, даже там написано, что они "не совсем" полноценные.
Они не являются независимыми ядрами, как и в интеле потоки, два амдшных "ядра" сидят в одном настоящем ядре и делят между собой его вычислительные ресурсы, на случай, если вдруг какой-то будет простаивать, а другому пригодится.
Да, в бульдозере они делят чуть меньше ресурсов, чем в интелах, однако делают это хуже, иначе вряд ли четырёхгигагерцовый бульдозер слил бы аналогичному интелу, у которого "меньше ядер".
Здравствуйте, Ikemefula, Вы писали:
S>>Блин, да знаю я это. Я что, говорю, что будет проще? Нет. I>Вопрос — чем придется заплатить за лишнюю сложность софта ?
Конкурентоспособностью, если не будет многопоточности.
Здравствуйте, cures, Вы писали:
C>Да, в бульдозере они делят чуть меньше ресурсов, чем в интелах, однако делают это хуже, иначе вряд ли четырёхгигагерцовый бульдозер слил бы аналогичному интелу, у которого "меньше ядер".
Здравствуйте, Sheridan, Вы писали:
S>>>Блин, да знаю я это. Я что, говорю, что будет проще? Нет. I>>Вопрос — чем придется заплатить за лишнюю сложность софта ? S>Конкурентоспособностью, если не будет многопоточности.
Это общие слова. Представь себе самую крутую прогу, которую ты только способен осилить. Теперь представь, что её надо запускать на 3000 процессоров.
Вопрос — при равных затратах времени/денег, чем будут отличаться оба варианта ?
Здравствуйте, ylem, Вы писали:
IO>>Скорее в языках.
Y>await, async подвижки в правильную сторону?
Это скорее в сторону многопоточности, а не многоядерности. Т.е. более удобное управление ресурсами ОС. Кроме того этим идеям сто лет в обед.
_>>>Потому что делать это всё вручную в массовых масштабах — нереально. IO>>Это да.
Y>Если все иммьютбл, раздали задания, собрали результаты, -- это же уже на порядок проще и пригодно для массового прикладного кода?
В какой-то сепени. Но не для программирования 100500 ядер, о котором говорил Vain. State of art тут — OpenCL/CUDA. И они ужасны.
Откуда же его [независимый суд] взять, если в нем такие же как мы? (c) VladD2
S>Я как то про сердечник из дерева видел в реальной дипломной работе
Это что! Я вот лично знал трех разных женщин по имени Лена Головач.
"Больше 100кмч можно ехать на автобане в любом ряду кроме правого крайнего" (c) pik
"В германии земля в частной собственности" (c) pik
"Закрывать школы, при нулевой смертности среди детей и подростков, это верх глупости" (c) Abalak
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, Sheridan, Вы писали:
S>>>>Блин, да знаю я это. Я что, говорю, что будет проще? Нет. I>>>Вопрос — чем придется заплатить за лишнюю сложность софта ? S>>Конкурентоспособностью, если не будет многопоточности.
I>Это общие слова.
Пока еще да.
I>Представь себе самую крутую прогу, которую ты только способен осилить. Теперь представь, что её надо запускать на 3000 процессоров.
Подразумевается, что оно способно параллелиться? Ок. I>Вопрос — при равных затратах времени/денег, чем будут отличаться оба варианта ?
Ясен пень, качеством.
А теперь представь, на тех же условиях, что твоя контора пишет софт, подобие которого пишут еще несколько контор. Решите ли вы не вкладываться в распараллеливание, если есть ненулевой шанс того, что конкуренты таки решатся?
_>>Пока что даже самый банальный асинхронный вызов и возврат данных (без косяков) осиливает максимум один из сотни. S>Когда вариантов не останется — осилят все ))
Ты не осилил даже основы. Но опять лезешь всех поучать.
Здравствуйте, Sheridan, Вы писали:
V>>не разберутся, и тебе уже ответили, и не потому-что тупые S>Я лучшего мнения о программерах, чем ты.
ты можешь быть любого мнения о программерах, но оно никак не связано с реальностью.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, Vain, Вы писали:
V>>>не разберутся, и тебе уже ответили, и не потому-что тупые S>>Я лучшего мнения о программерах, чем ты. V>ты можешь быть любого мнения о программерах, но оно никак не связано с реальностью.
От что ж ты заладил то так. Надеюсь, остальные программисты не настолько зациклены на единственной идее, как ты.
Да, я не профессиональный программист, то есть сейчас я программистом не работаю.
Но несколько лет назад я был профессиональным программистом на питоне — написал за деньги одному из провайдеров систему настройки системы мониторинга (оно обходило сеть, искало железо провайдера и натравливало заббикс). Дописал, перестал быть профессиональным программистом. Щас время от времени пишу в своё удовольствие. Конкретно вот щас — изучаю потихоньку R (интересно потрогать sdss за его 12й релиз) да вылизываю код ленивого подёргивания нескольких ip камер за rstp с сохранением кадров (1 кадр\30 сек) в файлики. Плюс к этому сборщик архива кадров в кено с указанной длительностью (таймлапс)
Так что твои мечты о том, что я ничего не соображаю в погроммировании — лишь мечты. Я пишу, но пишу не для дяди, а в своё удовольствие.
И да, чтобы два раза не вставать — процитирую сразу
Профессиона́л — человек, сделавший определённое занятие своей профессией; человек, ставший в какой-либо области деятельности специалистом; подготовленный для работы в определённой сфере специалист, имеющий навыки, квалификацию, а при необходимости и допуск к выполнению обязанностей по своей специальности. Многие путают понятие профессиона́ла с мастером. Не все профессионалы могут быть мастерами своего дела, точно так же, как и мастер в определенной области деятельности не всегда является профессионалом в этой же области.
Здравствуйте, Sheridan, Вы писали:
V>>>>не разберутся, и тебе уже ответили, и не потому-что тупые S>>>Я лучшего мнения о программерах, чем ты. V>>ты можешь быть любого мнения о программерах, но оно никак не связано с реальностью. S>От что ж ты заладил то так. Надеюсь, остальные программисты не настолько зациклены на единственной идее, как ты.
зациклен я значит, а телеги пишешь мне ты?
S>Так что твои мечты о том, что я ничего не соображаю в погроммировании — лишь мечты. Я пишу, но пишу не для дяди, а в своё удовольствие.
вода. вот когда начнёшь писать не для себя и не один, вот тогда будет смысл и говорить.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, Vain, Вы писали:
V>>>>>не разберутся, и тебе уже ответили, и не потому-что тупые S>>>>Я лучшего мнения о программерах, чем ты. V>>>ты можешь быть любого мнения о программерах, но оно никак не связано с реальностью. S>>От что ж ты заладил то так. Надеюсь, остальные программисты не настолько зациклены на единственной идее, как ты. V>зациклен я значит, а телеги пишешь мне ты?
Ты первый начал
S>>Так что твои мечты о том, что я ничего не соображаю в погроммировании — лишь мечты. Я пишу, но пишу не для дяди, а в своё удовольствие. V>вода. вот когда начнёшь писать не для себя и не один, вот тогда будет смысл и говорить.
Опять же интересная морковка: раз я пишу в своё удовольствие, то не умею писать
Да, у меня нет навыков командной работы, но от этих навыков умение писать как бы не зависит от слова "воощпе".
Здравствуйте, petr_t, Вы писали:
_>На 25%, Карл! За 4 года и 2 новых техпроцесса/архитектуры. Раньше такой результат за 1 год считался провалом. Похоже, прирост производительности уже совсем закончился.
Уже много лет как закон Мура работает на уменьшение энергопотребления, а не на чистую производительность.
Это очень заметно на больших масштабах — для крупных облачных провайдеров, в итоге, выгодно железо менять каждые 4 года, так как новые чипы себя окупают за счёт экономии энергии примерно за 3 года.
Здравствуйте, Sheridan, Вы писали:
S>Подразумевается, что оно способно параллелиться? Ок. I>>Вопрос — при равных затратах времени/денег, чем будут отличаться оба варианта ? S>Ясен пень, качеством.
И сразу же у юзеров пойдёт плак и вой, что программист Шеридан ни на что не годен, слил качество и тд и тд.
S>А теперь представь, на тех же условиях, что твоя контора пишет софт, подобие которого пишут еще несколько контор. Решите ли вы не вкладываться в распараллеливание, если есть ненулевой шанс того, что конкуренты таки решатся?
Что бы взяться за распараллеливание, нужно очень четко оценить потери из за снижения качества.
Здравствуйте, Ikemefula, Вы писали:
S>>Подразумевается, что оно способно параллелиться? Ок. I>>>Вопрос — при равных затратах времени/денег, чем будут отличаться оба варианта ? S>>Ясен пень, качеством. I>И сразу же у юзеров пойдёт плак и вой, что программист Шеридан ни на что не годен, слил качество и тд и тд.
А тут куда ни плюнь — всюду клин. Либо насчет качества, либо насчет задержки очередного апдейта, либо насчет стоимости
S>>А теперь представь, на тех же условиях, что твоя контора пишет софт, подобие которого пишут еще несколько контор. Решите ли вы не вкладываться в распараллеливание, если есть ненулевой шанс того, что конкуренты таки решатся? I>Что бы взяться за распараллеливание, нужно очень четко оценить потери из за снижения качества.
Перефразирую:
Решите ли вы не оценивать потери и не вкладываться в распараллеливание, если есть ненулевой шанс того, что конкуренты таки решатся?
Здравствуйте, Sheridan, Вы писали:
S>Опять же интересная морковка: раз я пишу в своё удовольствие, то не умею писать
Напиши что-нибудь несложное, но уровнем немного повыше лабы за 1 курс. Например, синхронизатор файлов между заданными путями с гуем и прогресс баром. А я пока за попкорном схожу.
Здравствуйте, Sheridan, Вы писали:
S>Опять же интересная морковка: раз я пишу в своё удовольствие, то не умею писать
Именно. В силу того, что ты пишешь в своё удовольствие, ты скорее всего проходишь мимо очень важных, но скучных, рутинных вещей, которые напрямую не связаны с результатом, например тестирование, проектирование, майнтенанс, суппорт. Что характерно, именно эти вещи дают наибОльшее количество экспириенса, в т.ч. даже в кодинге.
S>Да, у меня нет навыков командной работы, но от этих навыков умение писать как бы не зависит от слова "воощпе".
Наоборот. Твои посты про юнит-тесты очень хорошо показали твои возможности. Эквивалентный разработчик, с таким же пониманием юнит-тестов, приравнивается примерно к джуниору.
Просто так, `в своё удовольствие`, ты понятия не имеешь, какие куски твоего кода работают хорошо, а какие — плохо. Такую информацию даёт только особо злостный тестировщик или целая команды таких же. То есть, надо работать в команде.
Собтсвенно все твои разногласия с местными девелоперами именно отсюда — они уже прошли вот такое 'крещение' тестировщиками, майнтенансом и тд, а ты только пишешь в своё удовольствие.
M>Ну пока погроммисты пишут на языках, неспособных хоть что-то внятно делать на этих ядрах (например, С++), то ничего не изменится.
А чо там за проблема у С++ с внятностью на ядрах? И какие языки следует выбрать для достижения внятности?
"Больше 100кмч можно ехать на автобане в любом ряду кроме правого крайнего" (c) pik
"В германии земля в частной собственности" (c) pik
"Закрывать школы, при нулевой смертности среди детей и подростков, это верх глупости" (c) Abalak
Здравствуйте, Sheridan, Вы писали:
S>>>А теперь представь, на тех же условиях, что твоя контора пишет софт, подобие которого пишут еще несколько контор. Решите ли вы не вкладываться в распараллеливание, если есть ненулевой шанс того, что конкуренты таки решатся? I>>Что бы взяться за распараллеливание, нужно очень четко оценить потери из за снижения качества. S>Перефразирую: S>Решите ли вы не оценивать потери и не вкладываться в распараллеливание, если есть ненулевой шанс того, что конкуренты таки решатся?
Я тебе страшное скажу — вводить или не вводить параллельный алгоритм — такие вопросы обычно мусолятся постоянно и конкуренты здесь вообще ни при чем. Ты большей частью даже не знаешь, чем заняты конкуренты, а когда узнаёшь, это всегда два варианта — 1. они опередили 2. они опоздали.
Чудеса параллельного программирования пока что сильно преувеличены. Большинство задач или плохо параллелятся, или дают такое усложнение, что качество само собой обваливается ниже плинтуса.
Просто шериданам всегда всё намного лучше известно, чем инженеру который 10 лет выжимает биты всеми возможными и невозможными способами.
Здравствуйте, petr_t, Вы писали:
_>Напиши что-нибудь несложное, но уровнем немного повыше лабы за 1 курс. Например, синхронизатор файлов между заданными путями с гуем и прогресс баром. А я пока за попкорном схожу.
Параллельное усреднение кучи изображений для видео (надо 30 кадров в секунду, имеем 1500 изображений, которые надо свести в эти 30 кадров) при помощи imagemagick и перла, с прогрессбаром тебя устроит?
Здравствуйте, Sheridan, Вы писали:
S>Так что твои мечты о том, что я ничего не соображаю в погроммировании — лишь мечты. Я пишу, но пишу не для дяди, а в своё удовольствие.
Программирование уже давно стало командной игрой, как футбол или хоккей.
Никто в своём уме не говорит "я классный футболист-одиночка". Но вот в программировании такое почему то норма.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, Sheridan, Вы писали:
S>>Опять же интересная морковка: раз я пишу в своё удовольствие, то не умею писать
I>Именно. В силу того, что ты пишешь в своё удовольствие, ты скорее всего проходишь мимо очень важных, но скучных, рутинных вещей, которые напрямую не связаны с результатом, например тестирование, проектирование, майнтенанс, суппорт. Что характерно, именно эти вещи дают наибОльшее количество экспириенса, в т.ч. даже в кодинге.
Ты говоришь о процессе разработки вообще, я же говорю только о его части — собственно, программировании.
Как, например, процесс саппорта дает опыт в программировании? Да, процесс влияет на результат (выясняем баги, пишем патчи), но сам процесс не дает такого опыта. То есть, опыт программирования появляется при правке багов, найденных при саппорте. Но этот опыт появляется не из за того, что мы саппортим продукт, а из за того, что приходится больше программировать.
S>>Да, у меня нет навыков командной работы, но от этих навыков умение писать как бы не зависит от слова "воощпе". I>Наоборот. Твои посты про юнит-тесты очень хорошо показали твои возможности. Эквивалентный разработчик, с таким же пониманием юнит-тестов, приравнивается примерно к джуниору.
Это в ваших табелях о рангах какая ступень? Первая? Даже если нулевая — мне от этого ни холодно, ни жарко. Тот же перл не перекрывает мне часть своих возможностей из за этого
I>Просто так, `в своё удовольствие`, ты понятия не имеешь, какие куски твоего кода работают хорошо, а какие — плохо. Такую информацию даёт только особо злостный тестировщик или целая команды таких же. То есть, надо работать в команде.
Особого удовольствия нанимать команду тестировщиков у меня нет, а кто нибудь из местных вряд ли за-так будет мне помогать с этим
I>Собтсвенно все твои разногласия с местными девелоперами именно отсюда — они уже прошли вот такое 'крещение' тестировщиками, майнтенансом и тд, а ты только пишешь в своё удовольствие.
Это зависть? Обида? Непонимание того как программирование может быть хобби?
Неужели, если я завтра наймусь программистом куда нибудь, ко мне сменится отношение? Навыки то у меня останутся те же.
C>Ну как чего, уходить от плоской модели, например, никто не мешает через сотню атомов сделать ещё десяток-другой таких же плоскостей. Да и выкинуть "видеокарту" из чипа процессора, не место ей в топовых камнях, там юзер себе нормальную видюху всё равно возьмёт.
Мне вот отдельная видеокарта нафиг не нужна с лишними контактами или боже упаси вентиляторами. А вот процессор нужен чем больше тем лучше. (Не все играются в графические игрушки, особенно сервера)
Здравствуйте, Ikemefula, Вы писали:
S>>Решите ли вы не оценивать потери и не вкладываться в распараллеливание, если есть ненулевой шанс того, что конкуренты таки решатся? I>Я тебе страшное скажу — вводить или не вводить параллельный алгоритм — такие вопросы обычно мусолятся постоянно и конкуренты здесь вообще ни при чем. Ты большей частью даже не знаешь, чем заняты конкуренты, а когда узнаёшь, это всегда два варианта — 1. они опередили 2. они опоздали.
Гуд
I>Чудеса параллельного программирования пока что сильно преувеличены. Большинство задач или плохо параллелятся, или дают такое усложнение, что качество само собой обваливается ниже плинтуса.
Я как бы в курсе, но всё идет именно к распараллеливанию, так как по частоте уже уперлись почти в потолок и для дальнейшего роста придется расти вширь
I>Просто шериданам всегда всё намного лучше известно, чем инженеру который 10 лет выжимает биты всеми возможными и невозможными способами.
Ты наверное по инерции думаешь, что я сейчас кого то чему то учу. Нет, не учу. Исторически сложилось так, что я выразил надежду
Здравствуйте, Ikemefula, Вы писали:
I>Никто в своём уме не говорит "я классный футболист-одиночка". Но вот в программировании такое почему то норма.
Я не говорю что я классный программист
Здравствуйте, cures, Вы писали:
C>Да, обычный порошок — он такой, нифига не отстирывает. C>Можно попробовать платить ему деньги, в том числе и за то, чтобы не было глюков. Или платить — это уже экстремизм? C>Кодер, кстати, вообще не должен париться с многопоточками, это прорабатывается уровнем выше, а кодер тупо кодит по спецификации.
Но нужен ли тогда вообще кодер? Не превышают ли времЕнные затраты на спецификацию выигрыш от использования кодеров?
M>>Ну пока погроммисты пишут на языках, неспособных хоть что-то внятно делать на этих ядрах (например, С++), то ничего не изменится.
А>А чо там за проблема у С++ с внятностью на ядрах? И какие языки следует выбрать для достижения внятности?
Можно начать с вопроса: Когда там потоки в С++ на уровне языка/стандартных библиотек появились?
M>Можно начать с вопроса: Когда там потоки в С++ на уровне языка/стандартных библиотек появились?
"Когда-то" и Путин сперматозоидом был.
Не уходим от вопроса.
Итак, что там у С++ за траблы с многопоточной невнятностью? И какие языки размалывают его по внятности?
"Больше 100кмч можно ехать на автобане в любом ряду кроме правого крайнего" (c) pik
"В германии земля в частной собственности" (c) pik
"Закрывать школы, при нулевой смертности среди детей и подростков, это верх глупости" (c) Abalak
Здравствуйте, 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 ядер нагрузить.
когда вместо блокирующего ожидания на примитивах синхронизации получаем роутинг событий, т.е. цепочку асинхронных обработчиков, порождающих других асинхронных обработчиков.
Здравствуйте, Sheridan, Вы писали:
_>>Кто что думает? Что будет дальше?
S>Будут наращивать количество ядер (железные инженера) и распараллеливать задачи (погроммисты. Надеюсь.).
Я лет 10 назад покупал четырёхядерный процессор. Intel Core Quad, если мне память не изменяет. В то время мейнстримом были 2 ядра, но 4-ядерные уже были вполне популярны. Сейчас ситуация абсолютно идентична, 90% процессоров для персональных компьютеров 4-ядерные. Похоже это какое то оптимальное число и каких то перспектив по увеличению количества ядер в ближайшие годы я не вижу. При желании можно хоть щас поставить пару процессоров по 16 ядер, ща ещё и с хайпертрэдингом, но кому это надо?
Тут, скорее, прогресс будет идти по специализации процессоров. Сопроцессоры для типичных задач. Например для AES-шифрования в Intel давно есть специальные инструкции. Может быть сделают гибридные процессоры, которые приложение сможет перестраивать под свои нужды (например для видеокодировки).
vsb>Я лет 10 назад покупал четырёхядерный процессор. Intel Core Quad, если мне память не изменяет. В то время мейнстримом были 2 ядра, но 4-ядерные уже были вполне популярны. Сейчас ситуация абсолютно идентична
Идентична с одним исключением.
10 лет назад на каждом углу орали — вот, щас, когда многоядерность наконец-то стала быдлостандар мейнстримом, производители софта быренько отреагируют на это, и через года 3-4 мы будем скакать на многоядерниках аки Тор-громовержец.
Сейчас говорят — мдаа, не вышел каменный цветок, ну да и в топку эти ядра...
"Больше 100кмч можно ехать на автобане в любом ряду кроме правого крайнего" (c) pik
"В германии земля в частной собственности" (c) pik
"Закрывать школы, при нулевой смертности среди детей и подростков, это верх глупости" (c) Abalak
Здравствуйте, Ikemefula, Вы писали:
I>Кроме распараллеливания есть возможность менять алгоритмы и переходить, скажем, на более другой матан и другие вычислительные модели. Например, в одной области клиент отдаёт часть обязанностей серверу, обработка речи. А в другой, наоборот, сервер отдаёт клиенту часть обязанностей, тот же рендеринг.
Согласен, можно и так. Но через несколько итераций все равно путь приведет к многопоточности.
Здравствуйте, petr_t, Вы писали:
_>Неа. Разделяемых данных опять практически нет, а без них это даже не 1% от сложности нормального многопоточного приложения, а скорее 0.01%. Твою задачу можно легко разнести даже по отдельным процессам.
Ну тогда этот черновик посмотри, заодно по твоему ответу пойму что не так сделал, если не так
Здравствуйте, Sheridan, Вы писали:
I>>Кроме распараллеливания есть возможность менять алгоритмы и переходить, скажем, на более другой матан и другие вычислительные модели. Например, в одной области клиент отдаёт часть обязанностей серверу, обработка речи. А в другой, наоборот, сервер отдаёт клиенту часть обязанностей, тот же рендеринг.
S>Согласен, можно и так. Но через несколько итераций все равно путь приведет к многопоточности.
Часто бывает так, что если перекроить приложение, то можно найти более мирный способ увеличить производительность, нежели многопоточность. Например специализированые процессоры и тд.
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, Ikemefula, Вы писали:
S>А теперь представь, на тех же условиях, что твоя контора пишет софт, подобие которого пишут еще несколько контор. Решите ли вы не вкладываться в распараллеливание, если есть ненулевой шанс того, что конкуренты таки решатся?
Всё время решаемся. Коммерчески, идея что-то распараллелить довольно дурацкая. Чем-то напоминает мексиканскую дуэль, когда первые трое параллельщиков проигрывают деньги.
А>10 лет назад на каждом углу орали — вот, щас, когда многоядерность наконец-то стала быдлостандар мейнстримом, производители софта быренько отреагируют на это, и через года 3-4 мы будем скакать на многоядерниках аки Тор-громовержец. А>Сейчас говорят — мдаа, не вышел каменный цветок, ну да и в топку эти ядра...
Проблема не столько в ядрах, столько в том, что софт — включая ОСи — вообще неспособен эти ядра эффективно использовать. Наивный подход часто приводит к проседанию — и ощутимому — в производительности.
Как эту проблему решить правильно — хз. Потому что даже решения типа Grand Central Dispatch и им подобные — это костыли, а не решение.
100500 уже нереально. С этим (первым?) столкнулся Erlang, которому, казалось бы, сам бог велел быть впереди планеты всей на этом фронте. Ан нет. Банальная синхронизация и менеджмент процессов на 100500 ядер накладывает нехилые проблемы, что приводит к жутким просаживаниям по производительности.
Здравствуйте, Ikemefula, Вы писали:
V>>100500 не знаю, а десятки — легко.
I>В том то и дело, что нужны более серьезные инструменты, нежели нынешние, для десятка тредов.
Тут хорошо бы уточнить, какие задачи подразумеваются. Если посмотреть на процессы, работающие на типичном десктопе, десяток тредов там норма, и понятно, что это ни о чем не говорит.
Откуда же его [независимый суд] взять, если в нем такие же как мы? (c) VladD2
Здравствуйте, ins-omnia, Вы писали:
I>>В том то и дело, что нужны более серьезные инструменты, нежели нынешние, для десятка тредов.
IO>Тут хорошо бы уточнить, какие задачи подразумеваются. Если посмотреть на процессы, работающие на типичном десктопе, десяток тредов там норма, и понятно, что это ни о чем не говорит.
В том то и дело. В специфичных задачах уже давно работают по тесяче и более ядер
Я думаю скорее стоит ожидать появления специализированых процессоров например для ио
Если часть функций ос вынести в железо, это даст не слабую масштабируемость
Здравствуйте, Ikemefula, Вы писали:
I>В том то и дело, что нужны более серьезные инструменты, нежели нынешние, для десятка тредов.
Для десятков физических тредов нужны тысячи логических потоков, чтобы адекватно загрузить всё это. Сейчас основные бока в том, что переключение потоков ядром оч тяжелое, поэтому в бусте одна из активно развивающихся либ — корутины. Т.е. настоящие корутины, а не автоматы, сгенерённые с помощью async/await.
Т.е. характерен тот момент, что корутины для нейтива что они есть, что их нет — абсолютно пофиг для остальной программы, в отличие от того же дотнета, которому нужен детерминированный стек для нормальной работы GC.
Единственно что для нейтива требуется — это для каждого вида механизма, на котором можно что-то ожидать в блокирующем виде, написать специальную ф-ию ожидания, которая будет переключать корутины в кооперативной манере, если ожидание приведет к блокировке текущего потока исполнения. А этих механизмов всего 5 видов — примитив синхронизации (семафор/мьютекс/HEVENT), другой поток/фибер, дескриптор файла, сокет (для линухов сокет и файл — одно и то же) и некая очередь сообщений (типа IOCP, сообщений для GUI-окошка или сообщений для юзер-мод драйвера).
Здравствуйте, Mamut, Вы писали:
M>100500 уже нереально. С этим (первым?) столкнулся Erlang, которому, казалось бы, сам бог велел быть впереди планеты всей на этом фронте. Ан нет. Банальная синхронизация и менеджмент процессов на 100500 ядер накладывает нехилые проблемы, что приводит к жутким просаживаниям по производительности.
Это проблемы не Эрланга, а SMP-архитектуры. Про эту архитектуру с самого начала было известно, что она нацелена на небольшое кол-во процессоров/ядер, т.к. основной затык в ней — в аппаратуре, поддерживающей когерентность видимых процессорам данных + дорогое переключение контекстов при вытесняющей многозадачности.
Предлагаю взглянуть на старый Эльбрус или Крэй, с их несимметричной архитектурой. Простая вытесняющая многозадачность на тех процессорах была бы крайне неэффективной, т.к. логический вычислительный поток занимал оч много регистров из файла регистров, при том, что сам файл регистров состоял из различных видов этих регистров — от обычных 64-хразрядных, до 64х64бит векторов. Эффективно всё это использовать можно было только в пакетном режиме вычислений.
Уже сейчас понятно, что дальнейшее развитие многопоточности будет идти через усложнение архитектуры SMP. Например, суперкомпьютеры, которые ранее делались на процессорах Sun или HP, давно показали, как надо строить такие системы: это "двухярусная" система, где на первом "ярусе" располагаются SMP-узлы (порядка 16-32 ядер на узел), а на верхнем "ярусе" — транспортная шина некоей топологии, объединяющая эти узлы + специальный шедуллер, раскидывающий задачи по узлам. Сама система при этом получается гетерогенная, т.е. один/несколько узлов зарезервированы для работы системы, а все остальные рассматриваются как вспомогательные (современный аналог происходящего — GPU, типа как в Cell/PowerPC).
Получается, что "основной блок" может работать в режиме привычной вытесняющей многозадачности, а режим работы остальных блоков больше походит на пакетную обработку. Примерно так же получается в случае вычислений на GPU, при использовании GPU как "сопроцессора".
Современные же т.н. "суперкомпьютеры" — это то, что будет впоследствии высмеяно потомками, причем громко и по-конски. Современный "суперкомпьютер" — это узлы на основе какого-нить топового x64-процессора от Интел + GPU от nVidia + гигабитный Ethernet м/у ними. Эти т.н. "суперкомпьютеры" построены по принципу "я его слепила из того, что было". В отсутствии специализированного транспорта для памяти, берут Ethernet и огонь. ))
Кароч, современный отрыв в производительности настольных процов от производительности "классических серверных процов" сделал своё дело — сервера строят на процах и периферии от десктопов. Т.н. "серверные" процы от интел — это модификации ядер десктопных процов, где вся модификация сводится к большему кол-ву кеш-памяти и кол-ву каналов для внешней памяти.
С другой стороны, падение спроса на десктопы и постепенное перемещение вычислений в web могут подстегнуть создание более специализированной для серваков архитектуры. Не удивлюсь, если это сначала сделают у нас. )) Не зря наш Эльбрус-3 когда-то растащили сначала на Crusoe от Transmeta, потом на сановские процы, потом на Itanium от Intel.
Здравствуйте, Ikemefula, Вы писали:
IO>>Тут хорошо бы уточнить, какие задачи подразумеваются. Если посмотреть на процессы, работающие на типичном десктопе, десяток тредов там норма, и понятно, что это ни о чем не говорит. I>В том то и дело. В специфичных задачах уже давно работают по тесяче и более ядер
В пакетном режиме вычислений, однако.
I>Я думаю скорее стоит ожидать появления специализированых процессоров например для ио I>Если часть функций ос вынести в железо, это даст не слабую масштабируемость
В случае с обычным произвольным вытеснением никакой масштабируемости не будет по определению.
Здравствуйте, vdimas, Вы писали:
I>>В том то и дело, что нужны более серьезные инструменты, нежели нынешние, для десятка тредов.
V>Для десятков физических тредов нужны тысячи логических потоков, чтобы адекватно загрузить всё это.
Наоборот, потоков вообще не нужно для этого. Смотри на видеокарту — винде не надо создавать по 3 тысячи потоков если в видеокарте 3 тысячи ядер
V>Т.е. характерен тот момент, что корутины для нейтива что они есть, что их нет — абсолютно пофиг для остальной программы, в отличие от того же дотнета, которому нужен детерминированный стек для нормальной работы GC.
Смешное утверждение. Файберы могут работать с дотнетом. Принципиальной разницы нет. Если GC может сканировать стек, то может сканировать и стек короутин. Ничего военного.
V>Единственно что для нейтива требуется — это для каждого вида механизма, на котором можно что-то ожидать в блокирующем виде, написать специальную ф-ию ожидания, которая будет переключать корутины в кооперативной манере, если ожидание приведет к блокировке текущего потока исполнения.
Вся идея короутин в отсутствии ожиданий. Короутина ничего и никого ждать не должна. Все тяжелые блокирующие вызовы нужно отфутболивать в тред-пул, а шедулер будет брать следующую короутину. Отсюда ясно, что проблема вовсе не в примитивах синхронизации, как ты тут утверждаешь. Т.е. все дело в том, сколько тактов нужно потратить на вызов следующей короутины, а не в том, какие механицмы синхронизации у кого есть.
Здравствуйте, vdimas, Вы писали:
IO>>>Тут хорошо бы уточнить, какие задачи подразумеваются. Если посмотреть на процессы, работающие на типичном десктопе, десяток тредов там норма, и понятно, что это ни о чем не говорит. I>>В том то и дело. В специфичных задачах уже давно работают по тесяче и более ядер
V>В пакетном режиме вычислений, однако.
И что тебя смущает ?
I>>Я думаю скорее стоит ожидать появления специализированых процессоров например для ио I>>Если часть функций ос вынести в железо, это даст не слабую масштабируемость
V>В случае с обычным произвольным вытеснением никакой масштабируемости не будет по определению.
Здравствуйте, alex19, Вы писали:
A>Так что серьезного роста количества ядер в процессорах для решения широкого круга задач в ближайшее время не предвидится (без серьезного прорыва в какой-либо технологии, связанной с работой CPU). Нужно либо найти способ увеличить кеши на той же площади кристалла, либо научиться работать без них.
А что благородные доны думают про Xeon Phi? 60 ядер и всё такое...
_____________________
С уважением,
Stanislav V. Zudin
SVZ>А что благородные доны думают про Xeon Phi? 60 ядер и всё такое...
Практически нет задач, которые будут нагружать хотя бы половину из этих ядер. По разным причинам — от отсутсвия задач до неподготовленности ОСей, программ, языков программирования и программистов
У нас вот на работе в продакшне 80-ядерник стоит. Максимум 10% CPU, максимум 4 ядра заняты (сейчас, вроде, ухитрились 8 заставить работать ).
Здравствуйте, Mamut, Вы писали:
M>Практически нет задач, которые будут нагружать хотя бы половину из этих ядер. По разным причинам — от отсутсвия задач до неподготовленности ОСей, программ, языков программирования и программистов M>У нас вот на работе в продакшне 80-ядерник стоит. Максимум 10% CPU, максимум 4 ядра заняты (сейчас, вроде, ухитрились 8 заставить работать ).
Мы еще только собираемся прикупить такой агрегат.
У нас есть чем его загрузить — электродинамическим 3Д-солвером
Но, как выше верно говорили, отдельную задачу не распараллелить, алгоритмы не позволяют, но зато можно разом запустить целую пачку однотипных задач.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, Ikemefula, Вы писали:
I>В том то и дело. В специфичных задачах уже давно работают по тесяче и более ядер
В смысле ядер, соединенных сетью? Это уже не многопоточность, а нечно на порядок сложнее.
I>Я думаю скорее стоит ожидать появления специализированых процессоров например для ио I>Если часть функций ос вынести в железо, это даст не слабую масштабируемость
Сетевые карты, обрабатывающие внутри себя TCP — это оно, или что-то другое?
Откуда же его [независимый суд] взять, если в нем такие же как мы? (c) VladD2
Здравствуйте, Ikemefula, Вы писали:
I>>>В том то и дело. В специфичных задачах уже давно работают по тесяче и более ядер V>>В пакетном режиме вычислений, однако. I>И что тебя смущает ?
Что это плохо ложится на современные SMP-системы "общего назначения".
Здравствуйте, Ikemefula, Вы писали:
V>>Для десятков физических тредов нужны тысячи логических потоков, чтобы адекватно загрузить всё это. I>Наоборот, потоков вообще не нужно для этого. Смотри на видеокарту — винде не надо создавать по 3 тысячи потоков если в видеокарте 3 тысячи ядер
Это зависит от вида алгоритма. В видеокарте, считай, все тыщщи ядер выполняют один и тот же алгоритм, просто над разными участками данных.
Кароч, это спор о видах пареллелизма.
Я имел виду "независимый" параллелизм, т.е. паралеллизм независимых потоков, где каждый поток выполняет уникальный алгоритм.
V>>Т.е. характерен тот момент, что корутины для нейтива что они есть, что их нет — абсолютно пофиг для остальной программы, в отличие от того же дотнета, которому нужен детерминированный стек для нормальной работы GC.
I>Смешное утверждение. Файберы могут работать с дотнетом. Принципиальной разницы нет.
Да, но корутины буста дешевле, чем файберы windows, поэтому и разрабатываются.
Дотнету НЕОБХОДИМО разметить стек на фреймы, чтобы GC мог в нём работать. Если же корутина была создана не ср-вами дотнета, то дотнет в таком стеке сможет работать только с самым последним кадром стека, который создаётся, например, вы вызове из нейтива unmanaged poiner to function, которую можно получить из дотнетного делегата.
I>Если GC может сканировать стек, то может сканировать и стек короутин. Ничего военного.
GC сканирует не весь стек, а только список связанный фреймов в нём. Оборвешь связь — и нет никакого сканирования.
I>Вся идея короутин в отсутствии ожиданий. Короутина ничего и никого ждать не должна. Все тяжелые блокирующие вызовы нужно отфутболивать в тред-пул, а шедулер будет брать следующую короутину. Отсюда ясно, что проблема вовсе не в примитивах синхронизации, как ты тут утверждаешь. Т.е. все дело в том, сколько тактов нужно потратить на вызов следующей короутины, а не в том, какие механицмы синхронизации у кого есть.
Облом спорить. Но, таки, ожидание IO — это де-факто больное место ВСЕХ библиотек statefull-корутин. Могу рекомендовать посмотреть на PPL, как там с этим борются.
Здравствуйте, Sheridan, Вы писали:
I>>Именно. В силу того, что ты пишешь в своё удовольствие, ты скорее всего проходишь мимо очень важных, но скучных, рутинных вещей, которые напрямую не связаны с результатом, например тестирование, проектирование, майнтенанс, суппорт. Что характерно, именно эти вещи дают наибОльшее количество экспириенса, в т.ч. даже в кодинге. S>Ты говоришь о процессе разработки вообще, я же говорю только о его части — собственно, программировании. S>Как, например, процесс саппорта дает опыт в программировании? Да, процесс влияет на результат (выясняем баги, пишем патчи), но сам процесс не дает такого опыта.
Этот процесс даёт возможность посмореть на своё приложение под разными углами.
Грубо говоря, новичок-разработчик смотрит на код и видит в нём один execution path. Его устраивает поведение программы на этом execution path, поэтому он считает свою работу выполненной.
Разработчик, отпахавший 10 лет в саппорте, смотрит в тот же самый hello world и видит пару сотен вариантов того, как могут пойти дела на самом деле.
Естественно, он пишет программы с учётом этого опыта.
Точно так же, как начинающий DBA пыхтит над тем, чтобы нарисовать корректный SQL-запрос, а опытный — сразу видит, где могут быть просадки производительности.
И эта опытность никак не зависит от количества "написанных" стейтментов — исключительно от количества решённых проблем, возникающих при реальной эксплуатации "в поле".
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>И эта опытность никак не зависит от количества "написанных" стейтментов — исключительно от количества решённых проблем, возникающих при реальной эксплуатации "в поле".
Всё верно. Изменится подход к написанию софта, возможно архитектура.
На знание языка, на умение программировать это никаким образом не влияет
Здравствуйте, petr_t, Вы писали:
S>>Пока еще ничего. _>Если оно даже не работает, то о чем вообще говорить?
Не прыгай в сторону, сам же просил показать, а теперь отмахиваешься. Нет уж, смотри.
Во первых, оно работает, но преследуемая мной цель еще не достигнута.
Во вторых, поясню немного — что это: это еще одна распределенная система мониторинга сервантов. На компах устанавливаются ноды (демон), которые сенсорами собирают инфу и передают её коллекторам (демон), которые сохраняют это в хранилище (демон). Из хранилища это потом отдельными приложениями будет браться инфа и рисоваться как хистори графики, так и реалтайм. Будет как минимум веб-приложение для сводного хистори (с графиками, рисованными на R) и обычное клиентское приложение для реалтайм наблюдения и хистори.
Проект сильно вялотекущий, пишу когда есть желание. Чтение\запись конфигов уже есть (собственный парсер/генератор json), данные от сенсоров уже приходят к коллекторам (как раз на этом этапе пока остановился). Это всё будет гибко конфигурироваться (сколько каких данных с какой периодичностью сохранять, надо ли усреднять, с каким периодом итд), данные будут кешироваться для уменьшения запросов к БД (например, для реалтайма, крайний слепок данных будет всегда в памяти), написаны макросы для легкого написания новых сенсоров (в макросы запиханы все кишки взаимодействия с нодой, программисту останется написать сам код выкапывания данных и json-описание сенсора, например). Потоки там используются так: каждый сенсор в своем потоке, каждая нода в каждом коллекторе в своем потоке. Хранилище тоже будет общаться с коллекторами и клиентами тоже в отдельных потоках для каждого.
Не реализовано еще хранение, визуализация, сенсоры, поддержка snmp, обеспечение непрерывности данных (не хочу терять данные, пока коллектор или хранилище по тем или иным причинам недоступны).
В третьих, пишу потому как всё доступное существующее меня не устраивает, руки иногда тянутся писать код, а голова требует задачу. Поэтому вопрос "нафига оно надо" задавать не стоит, равно как и вопрос "когда допишешь" — допишу тогда, когда допишу, этот проект ради шашечек пишется. Как получится ехать — тогда и поедем, возможно очень нескоро
Надеюсь, на все возникшие вопросы ответить получилось, давай дальше по существу. У себя в этом проекте в потоках я могу куда нибудь упороться? Если да, то какой дашь совет?
Здравствуйте, Sheridan, Вы писали:
S>Всё верно. Изменится подход к написанию софта, возможно архитектура. S>На знание языка, на умение программировать это никаким образом не влияет
Я все пропустил. Работать, понимаете ли, надо.
Когда меняется подход к решению задачи, привычные средства языка, которым ты, казалось бы, владеешь в совершенстве, открываются с совершенно неожиданной стороны.
Здравствуйте, Sheridan, Вы писали:
S>Всё верно. Изменится подход к написанию софта, возможно архитектура. S>На знание языка, на умение программировать это никаким образом не влияет
Знание языка, о котором ты говоришь — это умение читать программы.
Умение программировать — это и есть "подход к написанию софта, возможно архитектура".
Например, я могу читать программы на примерно 7-8 языках. "Со словарём" — на полусотне.
А вот программировать я умею от силы на пяти языках, а скорее даже на трёх-четырёх.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>>Всё верно. Изменится подход к написанию софта, возможно архитектура. S>>На знание языка, на умение программировать это никаким образом не влияет S>Знание языка, о котором ты говоришь — это умение читать программы. S>Умение программировать — это и есть "подход к написанию софта, возможно архитектура". S>Например, я могу читать программы на примерно 7-8 языках. "Со словарём" — на полусотне. S>А вот программировать я умею от силы на пяти языках, а скорее даже на трёх-четырёх.
Попытаюсь пояснить свою мысль...
Вот я пишу некий код, я язык знаю, всё идёт ровно. Потом имею опыт его поддержки.
В следующем проекте я буду ровно так же писать код, но, оглядываясь на опыт, буду сразу в нужных местах исключать знакомые ошибки.
Иными словами у меня появится опыт написания софта, который легче поддерживать, но знания языка не прибавится, ибо я и так знаю, например, как ловить исключения или отслеживать косяк в вводимых пользователем данных, но поимев опыт поддержки я узнаю, что мои знания надо применить еще "тут" и "там".
Насчет "знания языка". Умение читать программы как бы не зависит от знания языка, на котором оно написано, а зависит от аналитических способностей головы и опыта в программировании вообще, то есть надо понять алгоритм работы читаемого куска кода. Если это конечно не экзотика типа bf. Не зная того же R я писал на нем осознанно уже через 15 минут, поглядывая в доки. Не зная форта, я прочёл исходник со второй попытки (это всё таки немного экзотика). Жабаскрипт я вообще никогда специально не изучал, я просто на ём пишу, поглядывая в доки.
_>>... Там было по тексту чтото типа "...а сердечник трансформатора сделаем из хвойных пород древесины, потому что до этого места х... кто нибудь когда нибудь дочиатет...". Как утверждал преподаватель — выпускник сам пришел через 3 года после сдачи диплома и показал чего у него приняли.
Ему повезло. Я знал иной случай. В дипломной работе было написано что-то такое: "эту ***** все равно никто читать не будет, на фига я корячусь". И эта работа попала на выборочную проверку в комиссию. И все, что там было написано, прочитали. Такие дела.
Здравствуйте, Sheridan, Вы писали:
S>Конкурентоспособностью, если не будет многопоточности.
Ага, вот, рапример, Огнелис в последних версиях скатился в УГ. Он весь работает в единственном процессе. Что-то мне подсказывает, что в нем используется многопоточность. А, например, Опера 28 (или какая там, 29?) запускает несколько процессов. Возможно, внутри каждого и есть многопоточность, но используется иначе. Надо признать, работает лучше Огнелиса. А я еще потдрунивал над уважаемым Lazytech по этому поводу. Вот и вся конкуренция.
Мы, кстати, подобный подход использовали однажды. Запустили пару десятков однопоточных процессов, и оно прекрасно лет 5 работало. Там есть свои грабли, но подход не хуже других.
Здравствуйте, Privalov, Вы писали:
P>Мы, кстати, подобный подход использовали однажды. Запустили пару десятков однопоточных процессов, и оно прекрасно лет 5 работало. Там есть свои грабли, но подход не хуже других.
Да не вопрос, пусть будут процессы. Все равно надо будет как то переколбашивать продукт, писать например менеджер этих процессов. Или, например, переписывать взаимодействие с БД, доступ к файлам.
Я так понимаю, судя по минусу соседнему сообщению и отсутствию ответа, языком чесать ты мастер, а как до дела дошло, так сразу заднюю включил.
Показательно.
Здравствуйте, Mamut, Вы писали:
SVZ>>А что благородные доны думают про Xeon Phi? 60 ядер и всё такое...
M>Практически нет задач, которые будут нагружать хотя бы половину из этих ядер. По разным причинам — от отсутсвия задач до неподготовленности ОСей, программ, языков программирования и программистов
Это же по сути GPU только с более мощными ядрами и x86 ISA. Задач для них хватает.
Откуда же его [независимый суд] взять, если в нем такие же как мы? (c) VladD2
Здравствуйте, Sheridan, Вы писали:
S>Попытаюсь пояснить свою мысль...
Мысль понятна. Она просто неправильна.
S>Вот я пишу некий код, я язык знаю, всё идёт ровно. Потом имею опыт его поддержки. S>В следующем проекте я буду ровно так же писать код, но, оглядываясь на опыт, буду сразу в нужных местах исключать знакомые ошибки.
И в результате код будет выглядеть существенно по-другому. Например, вместо введения интерфейса и пары классов, которые его реализуют, в коде останется пара лямбд.
S>Иными словами у меня появится опыт написания софта, который легче поддерживать, но знания языка не прибавится, ибо я и так знаю, например, как ловить исключения или отслеживать косяк в вводимых пользователем данных, но поимев опыт поддержки я узнаю, что мои знания надо применить еще "тут" и "там".
Иными словами, после полугода примерно поддержки на вопрос "что вы скажете о ваших знаниях языка полгода назад" ты будешь смеяться как мы сейчас.
S>Насчет "знания языка". Умение читать программы как бы не зависит от знания языка, на котором оно написано, а зависит от аналитических способностей головы и опыта в программировании вообще, то есть надо понять алгоритм работы читаемого куска кода. Если это конечно не экзотика типа bf. Не зная того же R я писал на нем осознанно уже через 15 минут, поглядывая в доки. Не зная форта, я прочёл исходник со второй попытки (это всё таки немного экзотика). Жабаскрипт я вообще никогда специально не изучал, я просто на ём пишу, поглядывая в доки.
Я в пятом классе тоже так думал о своих умениях программировать.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Sheridan, Вы писали:
S>>Попытаюсь пояснить свою мысль... S>Мысль понятна. Она просто неправильна.
Ты меня не понял.
S>>Вот я пишу некий код, я язык знаю, всё идёт ровно. Потом имею опыт его поддержки. S>>В следующем проекте я буду ровно так же писать код, но, оглядываясь на опыт, буду сразу в нужных местах исключать знакомые ошибки. S>И в результате код будет выглядеть существенно по-другому. Например, вместо введения интерфейса и пары классов, которые его реализуют, в коде останется пара лямбд.
Я классы, лямбды умею и так, после саппорта я их просто начну применять. Саппорт не даст мне знаний о лямбдах, а даст понимание куда их применить. И дело тут не в лямбдах, замени на что угодно.
S>>Иными словами у меня появится опыт написания софта, который легче поддерживать, но знания языка не прибавится, ибо я и так знаю, например, как ловить исключения или отслеживать косяк в вводимых пользователем данных, но поимев опыт поддержки я узнаю, что мои знания надо применить еще "тут" и "там". S>Иными словами, после полугода примерно поддержки на вопрос "что вы скажете о ваших знаниях языка полгода назад" ты будешь смеяться как мы сейчас.
Нет. Знание о языке останется такое же. Опыт саппорта даст мне понимание, как и где эти знания еще применить.
S>>Насчет "знания языка". Умение читать программы как бы не зависит от знания языка, на котором оно написано, а зависит от аналитических способностей головы и опыта в программировании вообще, то есть надо понять алгоритм работы читаемого куска кода. Если это конечно не экзотика типа bf. Не зная того же R я писал на нем осознанно уже через 15 минут, поглядывая в доки. Не зная форта, я прочёл исходник со второй попытки (это всё таки немного экзотика). Жабаскрипт я вообще никогда специально не изучал, я просто на ём пишу, поглядывая в доки. S>Я в пятом классе тоже так думал о своих умениях программировать.
А я нигде не говорил, что я мегакрут
Я так понимаю, с чтением кода мы разобрались, я оказался прав, раз на личности начинаем тут переходить.
Здравствуйте, Sheridan, Вы писали:
S>Я так понимаю, судя по минусу соседнему сообщению и отсутствию ответа, языком чесать ты мастер, а как до дела дошло, так сразу заднюю включил.
Не вижу ни малейшего смысла тратить на код, который даже не работает.
Здравствуйте, Sheridan, Вы писали: S>Я классы, лямбды умею и так, после саппорта я их просто начну применять.
Это ты меня не понял. То, что ты называешь "умею и так" — это "знаю, как оно пишется". А уметь означает не просто знать буковки, а знать, когда и как применять.
И именно это приходит с опытом.
S>Я так понимаю, с чтением кода мы разобрались, я оказался прав, раз на личности начинаем тут переходить.
Да мы-то разобрались, а ты всё ещё не понимаешь, о чём говоришь. Ну вот, грубо говоря, каждый здесь владеет русским языком. Тем не менее, далеко не каждый способен быть даже журналистом, а уж тем более — писателем. Потому что надо не только знать алфавит и словарь, а ещё и уметь их применять для достижения нужного эффекта.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, petr_t, Вы писали:
S>>Я так понимаю, судя по минусу соседнему сообщению и отсутствию ответа, языком чесать ты мастер, а как до дела дошло, так сразу заднюю включил. _>Не вижу ни малейшего смысла тратить на код, который даже не работает.
Здравствуйте, Sinclair, Вы писали:
S>Да мы-то разобрались, а ты всё ещё не понимаешь, о чём говоришь. Ну вот, грубо говоря, каждый здесь владеет русским языком. Тем не менее, далеко не каждый способен быть даже журналистом, а уж тем более — писателем. Потому что надо не только знать алфавит и словарь, а ещё и уметь их применять для достижения нужного эффекта.
Логика в твоих словах есть, но ты меня пока что не убедил. Предлагаю пока остановиться и, возможно, вернуться к разговору позже, у меня аргументы пока всё
Здравствуйте, Sheridan, Вы писали:
S>Логика в твоих словах есть, но ты меня пока что не убедил. Предлагаю пока остановиться и, возможно, вернуться к разговору позже, у меня аргументы пока всё
Этот твой ответ — уже нехилый прогресс. На моей памяти ты такое пишешь впервые. С другой стороны, звучит несколько странно: аргументов у тебя нет, но тебя не убедили. Это очень похоже на веру. Ну или поясни все же, в чем твои сомнения.
Здравствуйте, Privalov, Вы писали:
S>>Логика в твоих словах есть, но ты меня пока что не убедил. Предлагаю пока остановиться и, возможно, вернуться к разговору позже, у меня аргументы пока всё
P>Этот твой ответ — уже нехилый прогресс. На моей памяти ты такое пишешь впервые. С другой стороны, звучит несколько странно: аргументов у тебя нет, но тебя не убедили. Это очень похоже на веру. Ну или поясни все же, в чем твои сомнения.
Я сомневаюсь что мы говорим об одном и том же. Мне все таки кажется, что знание языка — это как раз знание его возможностей и хитростей. А ты, похоже, говоришь о знании как и где эти возможности и хитрости применить.
Здравствуйте, petr_t, Вы писали:
S>>Дооо _>Да. Сначала напиши код, который проходит минимальную проверку на качество — а потом можно и о более тонких материях поговорить.
Дооо
Здравствуйте, Sheridan, Вы писали:
S>Я сомневаюсь что мы говорим об одном и том же. Мне все таки кажется, что знание языка — это как раз знание его возможностей и хитростей. А ты, похоже, говоришь о знании как и где эти возможности и хитрости применить.
Здравствуйте, Sheridan, Вы писали:
S>Да не вопрос, пусть будут процессы. Все равно надо будет как то переколбашивать продукт, писать например менеджер этих процессов. Или, например, переписывать взаимодействие с БД, доступ к файлам.
Снова теоретические рассуждения. Менеджер, разумеется, нужен. Но это отдельный модуль. Его просто написали. А все остальное сильно переделывать ничего не пришлось. Добавили пару-тройку функций для взаимодействия в менеджером. Все остальное каким было, таким и осталось. Менеджер этот — штука не самая тривиальная. Межпроцессное взаимодействие — не то же самое, что межпоточное в рамках одного процесса.
Здравствуйте, Privalov, Вы писали:
P>Снова теоретические рассуждения. Менеджер, разумеется, нужен. Но это отдельный модуль. Его просто написали. А все остальное сильно переделывать ничего не пришлось. Добавили пару-тройку функций для взаимодействия в менеджером. Все остальное каким было, таким и осталось. Менеджер этот — штука не самая тривиальная.
А я и не говорю, что надо переколбашивать всё подряд и никогда не говорил. Я говорю лишь о том, что проект надо пересмотреть и в каких то местах, возможно, поправить.
P>Межпроцессное взаимодействие — не то же самое, что межпоточное в рамках одного процесса.
Это я понимаю.
Напомню, с чего всё началось. Началось всё с того, что я предположил дальнейший путь повышения производительности софта, в связи с скорым (?) достижением железом потолка, будет прокладываться в сторону распараллеливания. Сначала говорил про многопоточность (и упёрся в нежелание понимать того простого факта, что так или иначе, рано или поздно, но это сделать придется там где есть возможность). Ок, внесли предложение заменить на "многопроцессность" — пусть будет так, я не против, результат будет и в этом случае.
И все равно, вместо того чтобы согласиться с очевидным фактом того, что так или иначе придется идти в этом направлении, все начинают со мной спорить о том, что это сложно. Блин, да я не говорю о том что будет легко. Я вообще не даю никаких оценок и никого ничему не учу.
Или тут тренд такой — не соглашаться со мной? Надо будет как нибудь попробовать написать пост типа "Память нынче не ресурс, давайте откусывать много и не жалеть, клиент всего лишь купит еще пару плашек по 8Г и будет счастлив", интересно — все сменят свое мнение и начнут возражать или нет?...
Здравствуйте, Sheridan, Вы писали:
S>Вот! Я как раз говорю про знание, а вы про владение.
Ну да, про владение. Программисты-теоретики — это злющее зло. Правда, таких теоретиков, не участвовавших ни в одном проекте, я встречал только в качестве преподов в вузах (не среди своих). По счастью, их было очень мало. Для студентов они — адский адЪ. Никогда не ставят зачет, если исходник программы студента выглядит не так, как препод его себе представляет.
Здравствуйте, Sheridan, Вы писали:
S>И все равно, вместо того чтобы согласиться с очевидным фактом того, что так или иначе придется идти в этом направлении, все начинают со мной спорить о том, что это сложно.
Это не сложно. В массовых маштабах и с сегодняшними технологиями многопоточного программирования, это просто невозможно.
Здравствуйте, Sheridan, Вы писали:
S>И все равно, вместо того чтобы согласиться с очевидным фактом того, что так или иначе придется идти в этом направлении, все начинают со мной спорить о том, что это сложно. Блин, да я не говорю о том что будет легко. Я вообще не даю никаких оценок и никого ничему не учу.
Сложность очевидна, как ты сам сказал. А вот отсутствие альтернативных путей это, мягко говоря, дилетантские рассуждения.
S>Или тут тренд такой — не соглашаться со мной? Надо будет как нибудь попробовать написать пост типа "Память нынче не ресурс, давайте откусывать много и не жалеть, клиент всего лишь купит еще пару плашек по 8Г и будет счастлив", интересно — все сменят свое мнение и начнут возражать или нет?...
У тебя слишком категорично выходит. Во первых, возможны принципиально новые архитектуры вычислителей. Во вторых, возможна реструктуризация софта. Скажем, вместо "вычислить за секунду на сотне ядер" получится "считать с упреждением за ночь и по требованию выдать за секунду".
В третьих, возможны новые технологии в микропроцессорах, операционных системах и тд и тд.
У тебя вместо всего этого только один ответ — "много(поточность|процессорность|нужное вписать)".
Здравствуйте, vdimas, Вы писали:
I>>>>В том то и дело. В специфичных задачах уже давно работают по тесяче и более ядер V>>>В пакетном режиме вычислений, однако. I>>И что тебя смущает ?
V>Что это плохо ложится на современные SMP-системы "общего назначения".
Наоборот, очень даже хорошо. Видеокарты тому пример.
Здравствуйте, vdimas, Вы писали:
V>Дотнету НЕОБХОДИМО разметить стек на фреймы, чтобы GC мог в нём работать. Если же корутина была создана не ср-вами дотнета, то дотнет в таком стеке сможет работать только с самым последним кадром стека, который создаётся, например, вы вызове из нейтива unmanaged poiner to function, которую можно получить из дотнетного делегата.
Нет никаких фундаментальных препятствий научить GC таким короутинам. С теми же файберами он может худо-бедно работать.
I>>Если GC может сканировать стек, то может сканировать и стек короутин. Ничего военного.
V>GC сканирует не весь стек, а только список связанный фреймов в нём. Оборвешь связь — и нет никакого сканирования.
Ну так не обрывай.
I>>Вся идея короутин в отсутствии ожиданий. Короутина ничего и никого ждать не должна. Все тяжелые блокирующие вызовы нужно отфутболивать в тред-пул, а шедулер будет брать следующую короутину. Отсюда ясно, что проблема вовсе не в примитивах синхронизации, как ты тут утверждаешь. Т.е. все дело в том, сколько тактов нужно потратить на вызов следующей короутины, а не в том, какие механицмы синхронизации у кого есть.
V>Облом спорить. Но, таки, ожидание IO — это де-факто больное место ВСЕХ библиотек statefull-корутин. Могу рекомендовать посмотреть на PPL, как там с этим борются.
Любое ожидание, не только IO, это больное место вообще всей целиком взятой кооперативной многозадачности, а сюда входят не только statefull, но и stateless-корутины и многие другие вещи.
Здравствуйте, ins-omnia, Вы писали:
I>>Я думаю скорее стоит ожидать появления специализированых процессоров например для ио I>>Если часть функций ос вынести в железо, это даст не слабую масштабируемость IO>Сетевые карты, обрабатывающие внутри себя TCP — это оно, или что-то другое?
Управление от потока данных. Как IOCP, но 'сильнее'
Здравствуйте, Ikemefula, Вы писали:
S>>И все равно, вместо того чтобы согласиться с очевидным фактом того, что так или иначе придется идти в этом направлении, все начинают со мной спорить о том, что это сложно. Блин, да я не говорю о том что будет легко. Я вообще не даю никаких оценок и никого ничему не учу. I>Сложность очевидна, как ты сам сказал. А вот отсутствие альтернативных путей это, мягко говоря, дилетантские рассуждения. I>У тебя слишком категорично выходит. Во первых, возможны принципиально новые архитектуры вычислителей. Во вторых, возможна реструктуризация софта. Скажем, вместо "вычислить за секунду на сотне ядер" получится "считать с упреждением за ночь и по требованию выдать за секунду". I>В третьих, возможны новые технологии в микропроцессорах, операционных системах и тд и тд. I>У тебя вместо всего этого только один ответ — "много(поточность|процессорность|нужное вписать)".
Я не говорил что альтернатив нет, альтернативы вполне себе обсуждались в соседних подветках и я туда не лез, я ограничил свой подсабж только распараллеливанием
Я просто стараюсь всётаки в рамках сабжекта разговаривать, не прыгать туда-сюда, иначе бардак. Не всегда, конечно получается. но я стремлюсь чтобы всегда.
Здравствуйте, Ikemefula, Вы писали:
I>Управление от потока данных. Как IOCP, но 'сильнее'
А это как-то можно сделать в рамках процессора общего назначения? ЦПУ с dataflow-архитектурой — идея не новая, но её практическая реализуемость вроде бы никто не продемонстрировал. Хотя попытки были.
Откуда же его [независимый суд] взять, если в нем такие же как мы? (c) VladD2
Здравствуйте, Sheridan, Вы писали:
S>Напомню, с чего всё началось. Началось всё с того, что я предположил дальнейший путь повышения производительности софта, в связи с скорым (?) достижением железом потолка, будет прокладываться в сторону распараллеливания. Сначала говорил про многопоточность (и упёрся в нежелание понимать того простого факта, что так или иначе, рано или поздно, но это сделать придется там где есть возможность). Ок, внесли предложение заменить на "многопроцессность" — пусть будет так, я не против, результат будет и в этом случае.
Для тебя это очевидно, потому что ты прочитал на эту тему кучу теоретических рассуждений, и на этом основании сформулировал и отстаиваешь свою точку зрения. Это твое "так или иначе, рано или поздно, но это сделать придется" — далеко не очевидный факт. Скажу банальность. Тут бизнес решает. Да, я снова про презренный металл. Выжать больше возможностей, минимизируя при этом затраты. Альтернативные варианты, как ты заметил, обсуждаются.
Заметь, я не утверждаю, что ты категорически неправ. Я говорю, что твоя точка зрения — не единственная.
S>И все равно, вместо того чтобы согласиться с очевидным фактом того, что так или иначе придется идти в этом направлении, все начинают со мной спорить о том, что это сложно.
Повторю: это далеко не очевидный факт.
S>Или тут тренд такой — не соглашаться со мной?
А не сам ли ты способствуешь его развитию?
S>Надо будет как нибудь попробовать написать пост типа "Память нынче не ресурс, давайте откусывать много и не жалеть, клиент всего лишь купит еще пару плашек по 8Г и будет счастлив", интересно — все сменят свое мнение и начнут возражать или нет?...
Когда разрабатывают серверный софт, примерно знают, сколько он отхватит. Знают, как будет использоваться серверное железо. Соответственно, памяти ставят туда, сколько нужно. Может, вдвое больше. Память все еще не ресурс. А вот когда софтина сразу после релиза начинает вылетать из-за нехватки памяти — это уже хреново. Вот тут память становится ресурсом, и еще каким. Потому что простой сервера — это всегда убытки для его владельца.
Здравствуйте, Sheridan, Вы писали:
S>Напомню, с чего всё началось. Началось всё с того, что я предположил дальнейший путь повышения производительности софта, в связи с скорым (?) достижением железом потолка, будет прокладываться в сторону распараллеливания.
Тут есть ещё такой момент. Описанный, ЕМНИП, у Кнута.
Возьмём какую-нибудь простую задачку. Например, сортировку массива.
Есть десятки алгоритмов, построенных для однопоточных реализаций. Есть несколько алгоритмов, которые построены для многопоточных.
Возьмём экстремальный пример: предположим, у нас есть неограниченное количество "ядер" — вычислителей, каждый из которых может выполнять простую операцию типа compare-and-swap за одну стадию.
Длина массива — N. За какое минимальное количество стадий мы можем отсортировать массив?
Внезапно выясняется, что у современной математики нет способа решения таких задач. Для небольших количеств ядер (<10) нам известны оптимальные конфигурации процессорной сети — полученные, собственно, прямым перебором. Уже при K=50 мы не можем нарисовать эффективную сеть.
Этот простой пример показывает причины, по которым твоё предположение пока что весьма сомнительно. Известные нам алгоритмы параллелизации задач начинают сосать при выходе количества ядер за пределы нескольких десятков.
Вот хороший анализ: http://lira.imamod.ru/FondProgramm/Sort/ParallelSort.pdf
Посмотри на алгоритм Бэтчера. Видно, что при 512 ядрах мы сумели разогнать сортировку с 83 секунд до 1.29. Круто? Круто.
Но добавление ещё 128 ядер даёт нам всего лишь 0.08 секунды ускорения. Если у нас бюджет на эту сортировку — 100мс, то мы, судя по форме графика, всё ещё ой как далеки. А слоты под процессоры уже закончились.
Именно поэтому современные тенденции — в консолидации. Мы запихиваем по 48 ядер в одну коробку не для того, чтобы отдавать странички в 48 раз быстрее, а чтобы обрабатывать в 48 раз больше параллельных реквестов, тратя всего лишь в 5 раз больше на электричество и охлаждение.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Этот простой пример показывает причины, по которым твоё предположение пока что весьма сомнительно. Известные нам алгоритмы параллелизации задач начинают сосать при выходе количества ядер за пределы нескольких десятков. S>Вот хороший анализ: http://lira.imamod.ru/FondProgramm/Sort/ParallelSort.pdf S>Посмотри на алгоритм Бэтчера. Видно, что при 512 ядрах мы сумели разогнать сортировку с 83 секунд до 1.29. Круто? Круто. S>Но добавление ещё 128 ядер даёт нам всего лишь 0.08 секунды ускорения. Если у нас бюджет на эту сортировку — 100мс, то мы, судя по форме графика, всё ещё ой как далеки.
Здравствуйте, Sheridan, Вы писали:
S>Я не говорил что альтернатив нет, альтернативы вполне себе обсуждались в соседних подветках и я туда не лез, я ограничил свой подсабж только распараллеливанием
Распараллеливание это не панацея по той простой причине, что слишком много задач имеют сложные зависимости по данным. Если ты найдешь способ, скажем, как хорошо обходить граф в глубину параллельным алгоритмом, сразу двинешь всё человечество далеко вперёд
Здравствуйте, ins-omnia, Вы писали:
I>>Управление от потока данных. Как IOCP, но 'сильнее'
IO>А это как-то можно сделать в рамках процессора общего назначения? ЦПУ с dataflow-архитектурой — идея не новая, но её практическая реализуемость вроде бы никто не продемонстрировал. Хотя попытки были.
В рамках процессора общего назначения не выйдет, конечно.
Здравствуйте, Ikemefula, Вы писали:
I>Распараллеливание это не панацея по той простой причине, что слишком много задач имеют сложные зависимости по данным. Если ты найдешь способ, скажем, как хорошо обходить граф в глубину параллельным алгоритмом, сразу двинешь всё человечество далеко вперёд
_>Тоже верно. Но я как-то не надеюсь, что разработчики хромающего хрома и тормозиллы возьмутся за ум. Раньше их криворучие компенсировалось приростом производительности, но теперь уже нет.
Ну, ващет простые сайты открываются сейчас моментально в браузерах. Другое дело, что как только увеличивается производительность и появляются новые фичи(в дабаскрипте, цсс и т.д.), сразу усложняются сайты. Веб сейчас сильно отличается от того, что был 10 лет назад, и в старых, более шустрых, браузерах, 99.9% современных сайтов просто не откроются.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
I>Чудеса параллельного программирования пока что сильно преувеличены. Большинство задач или плохо параллелятся, или дают такое усложнение, что качество само собой обваливается ниже плинтуса.
Или вообще могут оказаться медленнее однопоточного варианта, часто по весьма неочевидным причинам, которые не были учтены при принятии решения о распараллеливании.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, Sinclair, Вы писали:
S>Именно поэтому современные тенденции — в консолидации. Мы запихиваем по 48 ядер в одну коробку не для того, чтобы отдавать странички в 48 раз быстрее, а чтобы обрабатывать в 48 раз больше параллельных реквестов
Вообще то Мур говорил о том, что наблюдения показали рост плотности транзисторов, не более того.
А так за последние 14 лет частота процессоров Intel выросла аж на 200Мгц.
Халява то закончилась, по этому поводу была статья, 10 лет назад.
Здравствуйте, Ikemefula, Вы писали:
I>>>>>В том то и дело. В специфичных задачах уже давно работают по тесяче и более ядер V>>>>В пакетном режиме вычислений, однако. I>>>И что тебя смущает ?
V>>Что это плохо ложится на современные SMP-системы "общего назначения". I>Наоборот, очень даже хорошо. Видеокарты тому пример.
Как всегда, ты взрываешь мне моск. ))
Видеокарта — это SMP.
Здравствуйте, Ikemefula, Вы писали:
I>Любое ожидание, не только IO, это больное место вообще всей целиком взятой кооперативной многозадачности, а сюда входят не только statefull, но и stateless-корутины и многие другие вещи.
Вовсе не любое, т.к. ожидание, связанное с недоступным нам "черным ящиком", например, с ядерным IO, очень сложно подчинить некоей своей архитектуре. В отличие от ожидание на ядерном IO, ожидание готовности, скажем, результатов вычислений обыгрываются в асинхронщине PPL просто великолепно. Я так думаю, что в итоге это приведет к росту популярности неядерных дров IO (они и сейчас постепенно набирают популярность, например, практически весь HFT давно сидит на неядерном IO, т.е. практически всё современное ПО для бирж, можно сказать, что уже ушло от IO уровня ОС).
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Ikemefula, Вы писали:
I>>Любое ожидание, не только IO, это больное место вообще всей целиком взятой кооперативной многозадачности, а сюда входят не только statefull, но и stateless-корутины и многие другие вещи.
V>Вовсе не любое, т.к. ожидание, не связанное с недоступным нам "черным ящиком", например, с ядерным IO, очень сложно подчинить некоей своей архитектуре.
Ты сам то понял что сказал ?
"не связанное с недоступным нам "черным ящиком", например, с ядерным IO" -> "не связанное с недоступным нам с ядерным IO" -> "не связаное с ядерным IO"
Здравствуйте, vdimas, Вы писали:
V>>>Что это плохо ложится на современные SMP-системы "общего назначения". I>>Наоборот, очень даже хорошо. Видеокарты тому пример.
V>Как всегда, ты взрываешь мне моск. )) V>Видеокарта — это SMP.
Это дело десятое. Главное что SMP-система общего назначения может этой видеокарте делегировать большую и продолжительную работу.
Здравствуйте, petr_t, Вы писали:
I>>Распараллеливание это не панацея по той простой причине, что слишком много задач имеют сложные зависимости по данным. Если ты найдешь способ, скажем, как хорошо обходить граф в глубину параллельным алгоритмом, сразу двинешь всё человечество далеко вперёд
_>А чем плох поиск в ширину?
Попробуй решить вот такую задачу при помощи поиска в ширину — найти на графе все пути между узлами А и Б.
Здравствуйте, petr_t, Вы писали:
I>>Попробуй решить вот такую задачу при помощи поиска в ширину — найти на графе все пути между узлами А и Б.
_>Идеальный вариант именно для поиска в ширину. Или я чего-то не понимаю?
Поиском в ширину эта задача вообще не решается. В ширину ты найдешь несколько кратчайших путей. Все оставшиеся сможет дать только поиск в глубину.
Другой вариант — тебе нужно находить циклы в графе. Здсь снова нужен поиск в глубину
Здравствуйте, petr_t, Вы писали:
I>>Поиском в ширину эта задача вообще не решается. В ширину ты найдешь несколько кратчайших путей.
_>Хм. Почему это?
Поиск в ширину — это волна из определенного центра. Она распространяется всегда в одном и том же направлении — от центра, правда по некоторой кривой зависящей от топологии. Отсюда ясно, что найдутся только те пути, которые совпадают с этим направлением.
Поиск в глубину это фактически перебор всех возможных цепочек, при чем нет никакого направления
Здравствуйте, Ikemefula, Вы писали:
I>>>Любое ожидание, не только IO, это больное место вообще всей целиком взятой кооперативной многозадачности, а сюда входят не только statefull, но и stateless-корутины и многие другие вещи.
V>>Вовсе не любое, т.к. ожидание, не связанное с недоступным нам "черным ящиком", например, с ядерным IO, очень сложно подчинить некоей своей архитектуре. I>Ты сам то понял что сказал ?
Я понял, что ты пока не понял, о чем речь.
I>"не связанное с недоступным нам "черным ящиком", например, с ядерным IO" -> "не связанное с недоступным нам с ядерным IO" -> "не связаное с ядерным IO" I>Ты бы пробовал короче писать что ли
Я написал ровно то, что написал.
Ядерное IO — это лишь один из примеров. Дело-то не в IO, вовсе, а в том, что шедуллинг выч. ресурсов в случае ядерного IO нам недоступен и нам стоит лишь полагаться на ядерный же шедулер. Когда речь об ожидании (а именно об ожидании шла речь, а не об IO), то скорость реакции на готовность ожидаемого события зависит от шедуллера. Ядерный шедуллер априори плохо в курсе насчет того, что надо прикладной программе здесь и сейчас.
См. например TBB flow graph.
По ссылке краткая вводная относительно того, как можно строить "умные" шедуллеры.
Здравствуйте, Don Reba, Вы писали:
DR>Здравствуйте, petr_t, Вы писали: _>>Я так думаю, чтобы это взлетело, нужен прорыв в компиляторах. Потому что делать это всё вручную в массовых масштабах — нереально.
DR>Компилятор не превратит последовательный алгоритм в массивно-параллельный.
Почему? Инструменты от Intel Parallel Studio могут подсвечивать в коде места, где можно применить параллельность. Так же есть т.н. "шаблонизация" при профилировании, когда создаётся примерный "шаблон" гранулярности распаралелливания конкретных мест. В пределе это всё придёт к некоторой автоматизации.
Здравствуйте, vdimas, Вы писали:
I>>"не связанное с недоступным нам "черным ящиком", например, с ядерным IO" -> "не связанное с недоступным нам с ядерным IO" -> "не связаное с ядерным IO" I>>Ты бы пробовал короче писать что ли
V>Я написал ровно то, что написал.
Следовательно, ты сознательно утверждаешь, что любое ожидание не-в-ядре, сложно подчинить своей архитектуре.
Примером такого ожидания является обычный вызов Math.sin(x)
Итого — ценность твоих высказываний равна нулю.
Здравствуйте, petr_t, Вы писали:
_>Посмотрел я на бенчмарки и приуныл. Самый мощный на сегодня 4-ядерник 4790K уделывает аналогичный i7 четырехлетней давности аж на целых 25%.
... _>Кто что думает? Что будет дальше?
Есть технологии, которые позволят поднять частоты почти на порядок, но для этого надо фактически полностью отказываться от кремния. Т.е. на сегодня пока мест стараются выжать максимум из технологий, в которые вкладывались десятки лет.
На тот момент были прогнозы примерно в ~15-30 для начала массового использования отличных от кремния тенхнологий микросхем. Сейчас получается лет 10-25 ))
Проблема для всех будет, если реально научатся делать хороший 3D на кремнии, это отсрочит увеличение частот, будем продолжать поедать увеличение ядер/выч.блоков. ))
Здравствуйте, elmal, Вы писали:
E>А что все — это наращивание тактовой частоты все. Уперлись в невозможность охлаждения, узкое место в охлаждении.
Это проблема исключительно кремния.
1. для кремния надо относительно высокое напряжение, от 0.75В и выше;
2. малое кол-во подвижных зарядов, больше сопротивление, большие потери на единичном переключении при прочих равных (т.е. при таких же емкостях, но на другом полупроводнике, с лучшей проводимостью) — большее выделение тепла.
Т.е., теоретически современные кремниевые процы могут стабильно работать на частотах порядка 10ГГц (при некотором подъеме рабочего напряжения), а практически — плавятся. ))
E>Вот только тяжело это, охрененно. Потому большинство программ по существу параллелизм не использует, для производительности важна в основном тактовая частота, а также кеш.
Это зависит от общепринятой культуры программирования. 100% всех современных программистов отталкивались в своём изучении программирования от линейных алгоритмов. Надо сразу обучать параллелизму, конвейерам, графам сигналов и т.д. с первых же занятий. )) Вбивать в мозжечок, такскать.
E>Так что пока далеко не завершено действие этого закона.
Считай, завершено. Пределы кремниевой технологии были известны лет 10 назад и эти пределы никуда не делись на сегодня, мы аккурат к этим пределам подошли.
Здравствуйте, Don Reba, Вы писали:
DR>Здравствуйте, denisko, Вы писали:
D>>Что именно, интересно? По моему опыту как были большим симдом, так большим симдом и остались.
DR>Динамическое выделение памяти, динамическое ветвление и циклы. А ещё, с shared memory можно эффективно обмениваться данными между потоками в блоке.
Ок, т.е как был большой симд, так и остался. Очередь из ядра вообще лучше не трогать, это адский тормоз.
Ветвление возможно и для большого симда, просто тебе надо пройти все ветки алгоритма. Циклы также, с шаред памятью есть нюансы: например то, что её использованный размер ограничивают количество варпов/вейв фронтов, с регистрами также . В итоге для того, чтобы это быстро работало нужно иметь опыт с парой граблей и терпение вылизывать алгоритм. Если у тебя алгоритм после предложения на карту стал работать в 30 раз быстрее, то просто перепиши его на хосте и получишь в среднем выигрыш раз в 5. Если все грабли тебя ударили, то есть шанс остаться с 10-20 ядерным(надеюсь понятно, откуда взялась цифра и почему там нет 100500 ядер) медленным процом с довольно специфическими понятиями о кэше.
На практике, массовые процессоры застряли уже на 4.5 ггц и дальше каменный цветок никак не выходит.
Интересно, а какие направления более перспективные?
Здравствуйте, ins-omnia, Вы писали:
A>>а где нужны приложения с параллельной архитектурой? IO>Да собственно везде кроме десктопа. Самое очевидное — веб-фронтенд обслужит в два раза больше пользователей одновременно если ему дать в два раза больше ядер (если нет других узких мест естественно).
Для веба в первом приближении не нужны "приложения с параллельной архитектурой", количество параллельных запросов там обычно существенно больше, чем количество аппаратных потоков.
_>На практике, массовые процессоры застряли уже на 4.5 ггц и дальше каменный цветок никак не выходит. _>Интересно, а какие направления более перспективные?
Любые, где подвижность зарядов на порядок больше, чем у кремния.
Например, из германия еще и не начинали выжимать его потенциал.
На германии можно сделать меньшие напряжения + большие токи. Всё вместе даёт на порядок меньший теплопакет при прочих равных, т.е. потенциал для дальнейшего повышения частот.
Но у каждого альтернативного полупроводника свои проблемы.
Например, германия в земной коре много, очень. Меньше, чем кремния, но тоже дофига. Но его очень сложно добывать, т.к. он практически всегда встречается лишь в виде небольших по долям примесях в других породах. Еще он очень хрупкий, поэтому из него невозможно прямо сейчас делать большие пластины, как это принято в кремниевой технологии. Одно из перспективных направлений на сегодня — это германий на кремнии. Но вот в чем беда, при том, что литографический процесс остаётся прежним, надо полностью менять процесс производства пластин. А сейчас сложились традиции ровно наоборот: при том, что литографический процесс модернизируется относительно часто, процесс по производству пластин живет десяток и более лет.
Здравствуйте, Sheridan, Вы писали:
Ф>>А ты сам-то способен "писать многопоточно"? S>Ну, пока что получалось. Я совершенно не мегакрут в этом вопросе, но везде гле прикручивал многопоточность — везде работает.
Или просто никто это нормально не тестировал.
S>Как правило это всевозможные скрипты, начиная от рекурсивного обхода сетей с подсетями и заканчивая скриптом, снимающего по 1 кадру раз в 30 секунд с нескольких камер в отдельности.
Для этого не нужно многопотоков, для этого достаточно уметь пользоваться IOCP.
Здравствуйте, Sheridan, Вы писали:
S>По железу почти в предел уткнулись.
Знаешь по чему в предел уткнулись? Не, не по железу. Уткнулись по потребностям массового рынка. Ну то есть есть сегменты, где перформанс еще важнее всего, но их суммарная доля совсем не велика. А массовый сегмент нынче страдает от маленьких батареек. И в энергожоркость все инвестиции и перешли. И там пока все хорошо с прогрессом, каждое следующее поколение имеет значительно более высокий перформанс на ватт.
Здравствуйте, Privalov, Вы писали:
P>Ага, вот, рапример, Огнелис в последних версиях скатился в УГ. Он весь работает в единственном процессе. Что-то мне подсказывает, что в нем используется многопоточность. А, например, Опера 28 (или какая там, 29?) запускает несколько процессов. Возможно, внутри каждого и есть многопоточность, но используется иначе. Надо признать, работает лучше Огнелиса. А я еще потдрунивал над уважаемым Lazytech по этому поводу. Вот и вся конкуренция.
Знаешь, тут лет 10 назад любымый аргумент хейтеров дотнета был — вот посмотрите на янус, он ведь тормозит, значит и дотнет тормозной. При том что любому, кто хоть немножечко в теме было известно, что ровно 100% тормозов януса связано с БД, которая никакого отношения к дотнету не имела.
Ты сейчас делаешь ровно тоже самое. Ты понятия не имеешь, чем реально вызваны тормоза огнелиса, но уже сделал выводы космического масштаба по поводу распараллеливания в нем.
Здравствуйте, Ikemefula, Вы писали:
I>Попробуй решить вот такую задачу при помощи поиска в ширину — найти на графе все пути между узлами А и Б.
Ищем полным перебором вариантов? Тогда на каждом ветвлении добавляем параллельных обходчиков, но только если их количество меньше количества процессоров. Путь накапливаем в односвязном списке, чтобы не возиться с синхронизацией. При большом количестве узлов бенефит от распараллеливания будет вполне ощутимым.
Здравствуйте, vdimas, Вы писали:
V>Например, из германия еще и не начинали выжимать его потенциал. V>На германии можно сделать меньшие напряжения + большие токи.
Например у германия обратный ток больше чем у кремния на 4 порядка, что ставит крест не то что на процессорном применении, но даже и на более менее сложной логике типа регистров. И в качестве вишенки на тортике значительно более высокие термошумы и сильно ниже предельная рабочая температура. Вобщем, гавно этот ваш германий, и не зря от него отказались. Единственный его плюс это возможность изготовления корпусных приборов примитивными технологиями — вплавлением таблеток индия.
Здравствуйте, Ночной Смотрящий, Вы писали:
I>>Попробуй решить вот такую задачу при помощи поиска в ширину — найти на графе все пути между узлами А и Б.
НС>Ищем полным перебором вариантов? Тогда на каждом ветвлении добавляем параллельных обходчиков, но только если их количество меньше количества процессоров. Путь накапливаем в односвязном списке, чтобы не возиться с синхронизацией. При большом количестве узлов бенефит от распараллеливания будет вполне ощутимым.
Параллельные алгоритмы для DFS есть, я в курсе. Все они, что характерно, очень сложные. Это хороший пример, который показывает, как паралеллизм усложняет софт. Вместо алгоритма в десяток строк появляется монстр с лоадбалансером и сложной коммуникацией между потоками. Эффект, правда, окупает затраты и такие решения уже неплохо масштабируются, до сотен и даже тысяч ядер.
Тем не менее DFS и BFS являются хорошим примером очень трудных в распараллеливании задач.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Например у германия обратный ток больше чем у кремния на 4 порядка, что ставит крест не то что на процессорном применении, но даже и на более менее сложной логике типа регистров. И в качестве вишенки на тортике значительно более высокие термошумы и сильно ниже предельная рабочая температура. Вобщем, гавно этот ваш германий, и не зря от него отказались. Единственный его плюс это возможность изготовления корпусных приборов примитивными технологиями — вплавлением таблеток индия.
Ну германий таки не говно. Чуть не все серьезные усилители низкой частоты в свое время делали именно на германиевых транзисторах, аккурат из за точности передачи, слабым искажениям и низкому уровню шумов. Их даже сравнивали с ламповыми.
Есть сомнения на счет частотных свойств германия, ибо практически все усилители высокой частоты что доводилось смотреть, были именно на кремниевых.
Владение это например понимание кода — сколько каких потенциальных цепочек выполнения ты видишь. Слишком часто баги от суппорта заставляют радикально пересмотреть свой опыт, потому что демонстрирую те самые цепочки, которые невооруженным глазом слабо видны.
Возникают вопросы: "А как это раньше работало ?" или "А почему только сейчас всё встало колом"
Начинаешь копать, и оказывается, что вся стройная концепция, которая изложена во множестве книжек, держится на честном слове и сотнях человеко-недель жесточайшего багфикса. И именно такое показывает, где какая концепция работает, а где за неё же нужно методично бить лицо.
Здравствуйте, Ikemefula, Вы писали:
I>Ну германий таки не говно.
Говно.
I> Чуть не все серьезные усилители низкой частоты в свое время делали именно на германиевых транзисторах, аккурат из за точности передачи, слабым искажениям и низкому уровню шумов.
Низкий уровень шумов у германия? Спасибо, насмешил. А искажения что у кремния, что у германия примерно одинаковые, физика то искажений примерно одна. Для всех полупроводниковых усилителей схемотехнику выбирают такой, чтобы искажения отдельных приборов не выливались в искажение усиливаемого сигнала. В идеале туда вообще ОУ ставят во входных каскадах. А нормальный интегральный ОУ, состоящий из десятков тысяч транзисторов на германии — "это, сынок, фантастика".
I>Есть сомнения на счет частотных свойств германия, ибо практически все усилители высокой частоты что доводилось смотреть, были именно на кремниевых.
Частотные свойства у германия как раз таки не хуже кремния благодаря более высокой подвижности электронов. А вот обратный ток снижает сильно чувствительность. А ВЧ как правила имеет низкий уровень сигнала.
Здравствуйте, Ночной Смотрящий, Вы писали:
I>> Чуть не все серьезные усилители низкой частоты в свое время делали именно на германиевых транзисторах, аккурат из за точности передачи, слабым искажениям и низкому уровню шумов.
НС>Низкий уровень шумов у германия? Спасибо, насмешил. А искажения что у кремния, что у германия примерно одинаковые, физика то искажений примерно одна. Для всех полупроводниковых усилителей схемотехнику выбирают такой, чтобы искажения отдельных приборов не выливались в искажение усиливаемого сигнала. В идеале туда вообще ОУ ставят во входных каскадах. А нормальный интегральный ОУ, состоящий из десятков тысяч транзисторов на германии — "это, сынок, фантастика".
Ты что, сомневаешься, что лучшие УНЧ были именно на германиевых транзисторах ?
интегральный ОУ — смешно. Где ты видел в 60-70 интегральные ОУ ?
Здравствуйте, Ikemefula, Вы писали:
I>Ты что, сомневаешься, что лучшие УНЧ были именно на германиевых транзисторах ?
А ты не задумывался, почему сейчас даже в выходной каскад германиевые транзисторы не ставят?
Был некоторый период, когда германиевые транзисторы были стабильнее по параметрам. Обрати внимание — стабильнее, а не лучше. Связано это, как я уже писал, с тем что германиевые технологии проще кремниевых, особенно для мощных приборов. А кремниевые по началу давали большой разброс (у знаменитых 315/361 разброс был в десятки, а то и сотни процентов). Как только кремниевые технологии доросли до зрелого состояния, так сразу германий закончился повсеместно.
I>интегральный ОУ — смешно. Где ты видел в 60-70 интегральные ОУ ?
При чем тут 70? Мы вроде как про перспективность германия говорим, а не про исторических монстриков.
Здравствуйте, cures, Вы писали:
C>игры — перешли на ускорение с помощью GPU, но и там уже несколько лет просматривается застой.
Не просматривается застоев.
Например возьмём топовые nVidia GPUs. Cейчас 6.1 TFLOPS, в 2014 5.1, в 2013 4.5, в 2012 3.0 TFLOPS.
C>И тенденция сильно урезать 64-битные вычисления, не нужные для игрушек.
Типичный маркетинг.
Они бы рады не урезать ничего, но кто же тогда станет покупать их теслы за $3-5k?
Здравствуйте, petr_t, Вы писали:
К>>Например возьмём топовые nVidia GPUs. Cейчас 6.1 TFLOPS, в 2014 5.1, в 2013 4.5, в 2012 3.0 TFLOPS. _>~20% за год — это таки застой.
Так текущий год ещё не кончился, половина только прошла.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Знаешь по чему в предел уткнулись? Не, не по железу. Уткнулись по потребностям массового рынка. Ну то есть есть сегменты, где перформанс еще важнее всего, но их суммарная доля совсем не велика. А массовый сегмент нынче страдает от маленьких батареек. И в энергожоркость все инвестиции и перешли. И там пока все хорошо с прогрессом, каждое следующее поколение имеет значительно более высокий перформанс на ватт.
Это называется путать причину и следствие. Массовые гаджеты потому стали массовыми, что слишком близко подошли по выч. мощности к десктопу. Если бы сегодня, как лет 15 назад, этот разрыв был бы в сотни-тысячи раз по выч.мощности, то десктоп бы не отмирал так печально, т.е. как и 15 лет назад было бы хорошим тоном иметь дома десктоп.
Здравствуйте, Ночной Смотрящий, Вы писали:
V>>Например, из германия еще и не начинали выжимать его потенциал. V>>На германии можно сделать меньшие напряжения + большие токи.
НС>Например у германия обратный ток больше чем у кремния на 4 порядка, что ставит крест не то что на процессорном применении, но даже и на более менее сложной логике типа регистров.
Но-но, не так быстро ))
Германий имеет смысл использовать только тогда, когда станет целесообразно еще уменьшить рабочее напряжение раза так в 3. И тут же обнаружится, что на обратном напряжении порядка 0.25В обратный же ток будет аккурат в необходимых пределах.
НС>И в качестве вишенки на тортике значительно более высокие термошумы и сильно ниже предельная рабочая температура.
Шумы в полупроводниках бывают более чем одного типа:
— термошумы (согласен);
— неоднородность проводника (малое кол-во носителей зарядов на единицу объема).
Первые имеют собой следствие некое генерируемое шумовое ЭДС, а вот второе — неоднородность сопротивления при открытии транзисторов. Так вот, для цифровой схемотехники первое не играет рояли вообще, т.к. в долях от помех буквально с соседнего проводника это генерируемое шумовое ЭДС не видно и под микроскопом и прекрасно "сливается" прямо в шины питания, имеющие предельно низкий импеданс, зато второе для кремния является тем самым ограничителем порядка 7-8нм, после которого вероятность правильного срабатывания логического ключа становится ниже необходимой, т.к. кол-во носителей зарядов в еще меньшем объеме пойдет уже буквально на единицы.
НС>Вобщем, гавно этот ваш германий, и не зря от него отказались.
Первый раз слышу, чтобы от германия отказались ))
Большое кол-во высокочастотных полупроводниковых приборов или приборов с низким входным импедансом делаются именно на германии.
В общем, ровно наоборот. От германия не отказались, его еще толком и не начинали применять в цифровой технике. Применяют пока совсем по чуть-чуть.
НС>Единственный его плюс это возможность изготовления корпусных приборов примитивными технологиями — вплавлением таблеток индия.
Эдак тебя заносит. ))
Его единственный плюс в том, что нанометровые транзисторы на напряженном германии показывают в 3-4 раза лучшие характеристики, чем аналогичные транзисторы на кремнии. Во всём другом минус, угу, и мы не раз эти минуса разбирали уже — дороговизна сырья и хрупкость материала. Т.е. делать чисто германиевые сложные схемы никогда и не будут, как мне кажется. Но раз уже взялись за графен, из которого в "чистом" виде не собрать полноценного устройства, а только по гибридной технологии, то будущее — за гибридными технологиями. В этих гибридных технологиях германий будет использоваться аж бегом. Погугли, например, "германан" (написано без ошибок), у него характеристики раз в 10 лучше, чем у кремния.
Какое железо ни покупай, даже открытие вкладки в браузере лагает достаточно сильно, чтобы это раздражало. Не говоря уже о студии с ее тормозами.
