Re[21]: Программисты тупы, хотя я так не считаю.
От: vdimas Россия  
Дата: 07.06.15 15:05
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>>>>>В том то и дело. В специфичных задачах уже давно работают по тесяче и более ядер

V>>>>В пакетном режиме вычислений, однако.
I>>>И что тебя смущает ?

V>>Что это плохо ложится на современные SMP-системы "общего назначения".

I>Наоборот, очень даже хорошо. Видеокарты тому пример.

Как всегда, ты взрываешь мне моск. ))
Видеокарта — это SMP.
Отредактировано 08.06.2015 6:58 vdimas . Предыдущая версия .
Re[19]: Программисты тупы, хотя я так не считаю.
От: vdimas Россия  
Дата: 07.06.15 15:10
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Любое ожидание, не только IO, это больное место вообще всей целиком взятой кооперативной многозадачности, а сюда входят не только statefull, но и stateless-корутины и многие другие вещи.


Вовсе не любое, т.к. ожидание, связанное с недоступным нам "черным ящиком", например, с ядерным IO, очень сложно подчинить некоей своей архитектуре. В отличие от ожидание на ядерном IO, ожидание готовности, скажем, результатов вычислений обыгрываются в асинхронщине PPL просто великолепно. Я так думаю, что в итоге это приведет к росту популярности неядерных дров IO (они и сейчас постепенно набирают популярность, например, практически весь HFT давно сидит на неядерном IO, т.е. практически всё современное ПО для бирж, можно сказать, что уже ушло от IO уровня ОС).
Отредактировано 08.06.2015 6:56 vdimas . Предыдущая версия .
Re[14]: о0
От: Mamut Швеция http://dmitriid.com
Дата: 08.06.15 06:18
Оценка:
S>Или тут тренд такой — не соглашаться со мной?

«Таки я действительно выгляжу настолько д..м?»
Автор: Sheridan
Дата: 12.10.09
© ты

Я там тебе даже отвечал, на что обратить внимание: http://rsdn.ru/forum/flame.comp/3566621
Автор: Mamut
Дата: 13.10.09


Шесть лет назад! Шесть лет!


dmitriid.comGitHubLinkedIn
Re[20]: Программисты тупы, хотя я так не считаю.
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 08.06.15 06:50
Оценка:
Здравствуйте, vdimas, Вы писали:

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


I>>Любое ожидание, не только IO, это больное место вообще всей целиком взятой кооперативной многозадачности, а сюда входят не только statefull, но и stateless-корутины и многие другие вещи.


V>Вовсе не любое, т.к. ожидание, не связанное с недоступным нам "черным ящиком", например, с ядерным IO, очень сложно подчинить некоей своей архитектуре.


Ты сам то понял что сказал ?

"не связанное с недоступным нам "черным ящиком", например, с ядерным IO" -> "не связанное с недоступным нам с ядерным IO" -> "не связаное с ядерным IO"

Ты бы пробовал короче писать что ли
Re[22]: Программисты тупы, хотя я так не считаю.
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 08.06.15 06:55
Оценка:
Здравствуйте, vdimas, Вы писали:

V>>>Что это плохо ложится на современные SMP-системы "общего назначения".

I>>Наоборот, очень даже хорошо. Видеокарты тому пример.

V>Как всегда, ты взрываешь мне моск. ))

V>Видеокарта — это SMP.

Это дело десятое. Главное что SMP-система общего назначения может этой видеокарте делегировать большую и продолжительную работу.
Re[18]: о0
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 08.06.15 07:14
Оценка:
Здравствуйте, petr_t, Вы писали:

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


_>А чем плох поиск в ширину?


Попробуй решить вот такую задачу при помощи поиска в ширину — найти на графе все пути между узлами А и Б.
Re[19]: о0
От: petr_t  
Дата: 08.06.15 07:17
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Попробуй решить вот такую задачу при помощи поиска в ширину — найти на графе все пути между узлами А и Б.


Идеальный вариант именно для поиска в ширину. Или я чего-то не понимаю?
Re[20]: о0
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 08.06.15 07:38
Оценка:
Здравствуйте, petr_t, Вы писали:

I>>Попробуй решить вот такую задачу при помощи поиска в ширину — найти на графе все пути между узлами А и Б.


_>Идеальный вариант именно для поиска в ширину. Или я чего-то не понимаю?


Поиском в ширину эта задача вообще не решается. В ширину ты найдешь несколько кратчайших путей. Все оставшиеся сможет дать только поиск в глубину.

Другой вариант — тебе нужно находить циклы в графе. Здсь снова нужен поиск в глубину
Отредактировано 08.06.2015 7:40 Pauel . Предыдущая версия .
Re[21]: о0
От: petr_t  
Дата: 08.06.15 08:25
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Поиском в ширину эта задача вообще не решается. В ширину ты найдешь несколько кратчайших путей.


Хм. Почему это?
Re[22]: о0
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 08.06.15 09:18
Оценка:
Здравствуйте, petr_t, Вы писали:

I>>Поиском в ширину эта задача вообще не решается. В ширину ты найдешь несколько кратчайших путей.


_>Хм. Почему это?


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

Поиск в глубину это фактически перебор всех возможных цепочек, при чем нет никакого направления
Re[21]: Программисты тупы, хотя я так не считаю.
От: vdimas Россия  
Дата: 08.06.15 16:19
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>>>Любое ожидание, не только IO, это больное место вообще всей целиком взятой кооперативной многозадачности, а сюда входят не только statefull, но и stateless-корутины и многие другие вещи.


V>>Вовсе не любое, т.к. ожидание, не связанное с недоступным нам "черным ящиком", например, с ядерным IO, очень сложно подчинить некоей своей архитектуре.

I>Ты сам то понял что сказал ?

Я понял, что ты пока не понял, о чем речь.


I>"не связанное с недоступным нам "черным ящиком", например, с ядерным IO" -> "не связанное с недоступным нам с ядерным IO" -> "не связаное с ядерным IO"

I>Ты бы пробовал короче писать что ли

Я написал ровно то, что написал.

Ядерное IO — это лишь один из примеров. Дело-то не в IO, вовсе, а в том, что шедуллинг выч. ресурсов в случае ядерного IO нам недоступен и нам стоит лишь полагаться на ядерный же шедулер. Когда речь об ожидании (а именно об ожидании шла речь, а не об IO), то скорость реакции на готовность ожидаемого события зависит от шедуллера. Ядерный шедуллер априори плохо в курсе насчет того, что надо прикладной программе здесь и сейчас.

См. например TBB flow graph.
По ссылке краткая вводная относительно того, как можно строить "умные" шедуллеры.
Re[5]: закон Мура всё
От: vdimas Россия  
Дата: 08.06.15 16:23
Оценка: 1 (1)
Здравствуйте, Don Reba, Вы писали:

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

_>>Я так думаю, чтобы это взлетело, нужен прорыв в компиляторах. Потому что делать это всё вручную в массовых масштабах — нереально.

DR>Компилятор не превратит последовательный алгоритм в массивно-параллельный.


Почему? Инструменты от Intel Parallel Studio могут подсвечивать в коде места, где можно применить параллельность. Так же есть т.н. "шаблонизация" при профилировании, когда создаётся примерный "шаблон" гранулярности распаралелливания конкретных мест. В пределе это всё придёт к некоторой автоматизации.
Re[22]: Программисты тупы, хотя я так не считаю.
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 08.06.15 16:25
Оценка: +1 :)
Здравствуйте, vdimas, Вы писали:

I>>"не связанное с недоступным нам "черным ящиком", например, с ядерным IO" -> "не связанное с недоступным нам с ядерным IO" -> "не связаное с ядерным IO"

I>>Ты бы пробовал короче писать что ли

V>Я написал ровно то, что написал.


Следовательно, ты сознательно утверждаешь, что любое ожидание не-в-ядре, сложно подчинить своей архитектуре.
Примером такого ожидания является обычный вызов Math.sin(x)
Итого — ценность твоих высказываний равна нулю.
Re: закон Мура всё
От: vdimas Россия  
Дата: 08.06.15 17:48
Оценка: 1 (1)
Здравствуйте, petr_t, Вы писали:

_>Посмотрел я на бенчмарки и приуныл. Самый мощный на сегодня 4-ядерник 4790K уделывает аналогичный i7 четырехлетней давности аж на целых 25%.

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

Обсуждали как раз примерно 5 лет назад ))
http://rsdn.ru/forum/flame.politics/3829023.flat
Автор: vdimas
Дата: 01.06.10


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

На тот момент были прогнозы примерно в ~15-30 для начала массового использования отличных от кремния тенхнологий микросхем. Сейчас получается лет 10-25 ))

Проблема для всех будет, если реально научатся делать хороший 3D на кремнии, это отсрочит увеличение частот, будем продолжать поедать увеличение ядер/выч.блоков. ))
Re[2]: закон Мура всё
От: vdimas Россия  
Дата: 08.06.15 17:55
Оценка:
Здравствуйте, elmal, Вы писали:

E>А что все — это наращивание тактовой частоты все. Уперлись в невозможность охлаждения, узкое место в охлаждении.


Это проблема исключительно кремния.
1. для кремния надо относительно высокое напряжение, от 0.75В и выше;
2. малое кол-во подвижных зарядов, больше сопротивление, большие потери на единичном переключении при прочих равных (т.е. при таких же емкостях, но на другом полупроводнике, с лучшей проводимостью) — большее выделение тепла.

Т.е., теоретически современные кремниевые процы могут стабильно работать на частотах порядка 10ГГц (при некотором подъеме рабочего напряжения), а практически — плавятся. ))


E>Вот только тяжело это, охрененно. Потому большинство программ по существу параллелизм не использует, для производительности важна в основном тактовая частота, а также кеш.


Это зависит от общепринятой культуры программирования. 100% всех современных программистов отталкивались в своём изучении программирования от линейных алгоритмов. Надо сразу обучать параллелизму, конвейерам, графам сигналов и т.д. с первых же занятий. )) Вбивать в мозжечок, такскать.

E>Так что пока далеко не завершено действие этого закона.


Считай, завершено. Пределы кремниевой технологии были известны лет 10 назад и эти пределы никуда не делись на сегодня, мы аккурат к этим пределам подошли.
Re[4]: закон Мура всё
От: denisko http://sdeniskos.blogspot.com/
Дата: 08.06.15 18:39
Оценка:
Здравствуйте, Don Reba, Вы писали:

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


D>>Что именно, интересно? По моему опыту как были большим симдом, так большим симдом и остались.


DR>Динамическое выделение памяти, динамическое ветвление и циклы. А ещё, с shared memory можно эффективно обмениваться данными между потоками в блоке.

Ок, т.е как был большой симд, так и остался. Очередь из ядра вообще лучше не трогать, это адский тормоз.
Ветвление возможно и для большого симда, просто тебе надо пройти все ветки алгоритма. Циклы также, с шаред памятью есть нюансы: например то, что её использованный размер ограничивают количество варпов/вейв фронтов, с регистрами также . В итоге для того, чтобы это быстро работало нужно иметь опыт с парой граблей и терпение вылизывать алгоритм. Если у тебя алгоритм после предложения на карту стал работать в 30 раз быстрее, то просто перепиши его на хосте и получишь в среднем выигрыш раз в 5. Если все грабли тебя ударили, то есть шанс остаться с 10-20 ядерным(надеюсь понятно, откуда взялась цифра и почему там нет 100500 ядер) медленным процом с довольно специфическими понятиями о кэше.
<Подпись удалена модератором>
Re[2]: закон Мура всё
От: petr_t  
Дата: 09.06.15 02:44
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Обсуждали как раз примерно 5 лет назад ))

V>http://rsdn.ru/forum/flame.politics/3829023.flat
Автор: vdimas
Дата: 01.06.10


На практике, массовые процессоры застряли уже на 4.5 ггц и дальше каменный цветок никак не выходит.
Интересно, а какие направления более перспективные?
Re[3]: закон Мура всё
От: Ночной Смотрящий Россия  
Дата: 09.06.15 20:03
Оценка:
Здравствуйте, vsb, Вы писали:

vsb>Я лет 10 назад покупал четырёхядерный процессор. Intel Core Quad, если мне память не изменяет.


Какие 10 лет? Первый квад вышел в 2007.
Re[3]: закон Мура всё
От: Ночной Смотрящий Россия  
Дата: 09.06.15 20:03
Оценка:
Здравствуйте, ins-omnia, Вы писали:

A>>а где нужны приложения с параллельной архитектурой?

IO>Да собственно везде кроме десктопа. Самое очевидное — веб-фронтенд обслужит в два раза больше пользователей одновременно если ему дать в два раза больше ядер (если нет других узких мест естественно).

Для веба в первом приближении не нужны "приложения с параллельной архитектурой", количество параллельных запросов там обычно существенно больше, чем количество аппаратных потоков.
Re[3]: закон Мура всё
От: vdimas Россия  
Дата: 10.06.15 08:25
Оценка: 1 (1)
Здравствуйте, petr_t, Вы писали:

V>>Обсуждали как раз примерно 5 лет назад ))

V>>http://rsdn.ru/forum/flame.politics/3829023.flat
Автор: vdimas
Дата: 01.06.10


_>На практике, массовые процессоры застряли уже на 4.5 ггц и дальше каменный цветок никак не выходит.

_>Интересно, а какие направления более перспективные?

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

Но у каждого альтернативного полупроводника свои проблемы.
Например, германия в земной коре много, очень. Меньше, чем кремния, но тоже дофига. Но его очень сложно добывать, т.к. он практически всегда встречается лишь в виде небольших по долям примесях в других породах. Еще он очень хрупкий, поэтому из него невозможно прямо сейчас делать большие пластины, как это принято в кремниевой технологии. Одно из перспективных направлений на сегодня — это германий на кремнии. Но вот в чем беда, при том, что литографический процесс остаётся прежним, надо полностью менять процесс производства пластин. А сейчас сложились традиции ровно наоборот: при том, что литографический процесс модернизируется относительно часто, процесс по производству пластин живет десяток и более лет.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.