128 бит в массы

А еще курица несет яйца..

> Так ведь 64 в два раза больше, чем 32, вот она и памяти столько жрет.

Не в 2, а в 2^32 раза больше.

Да просто поработав с x86_64 я понял что это п..ц (и ваще не-Ъ-64-бита), на..й не нужная технология, которая продвигалась только маркетинговыми способами (кто покодит под неё на уровне асма -- поймёт). Наверное, x86_128 будет таким же говном.

>Там, где нужна серьезная криптография, делают аппапратные ускорители.

"серьезная криптография" это аналог "конкретной криптографии" или просто криптографии?

>А из числа тех, что выиграют от 128-бит арифметики? ;)

понятия не имею, но от многопоточности не много больше пользы, если не вреда

>Люди не будут массово покупать процессор, который поддерживает 128-битные вычисления, но проигрывает конкурентам по другим параметрам (например, вдвое сильнее греется).

А с чего бы это ему больше греться или вообще уступать по каким-то параметрам? Речь не о впаривании какого-то товара, а о его характеристиках

>Разумеется. Я как раз и предлагаю сторонникам 128-битных адресных пространств эти моменты озвучить ;)

Я таких не знаю

> А с чего бы это ему больше греться или вообще уступать по каким-то параметрам? Речь не о впаривании какого-то товара, а о его характеристиках

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

> Не в 2, а в 2^32 раза больше.

Разрядность больше в два раза.

Венда, может быть, рада сожрать и в 2^32 раза больше, но кто ж ей столько даст?

> Разрядность больше в два раза.

Да, но в сообщении на которое ты отвечал, речь шла не о разрядности, а о объёме памяти.

> А с чего бы это ему больше греться или вообще уступать по каким-то параметрам?

Хорошо известно, что наиболее греющаяся часть CPU - это ALU. Чтобы без потерь производительности поддержать 128 бит, размер ALU придется увеличить вдвое. Вот оно и будет греться значительно сильнее.

> от многопоточности не много больше пользы

Эффективно распараллелить можно не всё, но очень и очень многое. Так что из многоядерности пользу удается извлечь в гораздо бОльшем количестве случаев, чем из дофигабитности.

> у новых операционных систем будет 128-битная архитектура ядра. Переговоры о поддержке новой архитектуры на аппаратной части ведутся с компаниями Intel, AMD, HP и IBM.

Перевод: новая операционка будет 128-битной. Если нам удастся договориться с производителями процессоров, то нам не придётся _эмулировать_ 128-битность на 64-битных процессорах.

> Да просто поработав с x86_64 я понял что это п..ц

Зачем асм?

www.linux.org.ru/view-message.jsp?msgid=2107537

>"Объем вашей ОЗУ не зависит от разрядности вашего процессора" (С) КО =)

Угу. И поэтому лишние и никому ненужные разряды пусть просто так будут. Для красоты.

>Процессор может быть и 128-и битным, а память останется 32-х битной

Поэтому в теме, если ты внимательно читаешь, и обсуждается вопрос разрядности РОН отдельно, а вопрос адресного пространства - отдельно.

См. тему с начала.

>А еще курица несет яйца..

Не всегда.

>Потому что количество транзисторов, при тех же остальных характеристиках, увеличится вдвое.

А мне кажется, что нынешние процессоры таки 2-х мерные, не? :) И ведь никто не знает, какими они будут в будущем, и будет ли в них вообще кремний :)

>размер ALU придется увеличить вдвое

Размер -> площадь для теперешних процессоров, и увеличивать её/уменьшать техпрощесс до бесконечности невозможно, потому что уже сейчас довольно остро стоит проблема разводки линий питания для этого хозяйства. Из электроники просто дожимают соки - это факт. Пусть и не очевидный, но другой факт - будущее за оптикой, где большие размерности/разрядности структур практически норма, также как и не проблема, скажем перемножение матриц любой размерности за 1 импульс :)

>Эффективно распараллелить можно не всё, но очень и очень многое.

Девять женщин не сделают ребенка за месяц. Это же касается и подавляющего большинства вычислительных задач.

>Так что из многоядерности пользу удается извлечь в гораздо бОльшем количестве случаев, чем из дофигабитности.

Ну да, купили молоток - теперь самое время искать, что же им можно забить :)

s/матриц любой размерности/векторов любого размера/ ofc

> Девять женщин не сделают ребенка за месяц. Это же касается и подавляющего большинства вычислительных задач.

Да ну? Можно попросить топ20 наиболее актуальных нераспараллеливаемых вычислительных задач?

Сходу отвечу про потоковую компрессию/декомпрессиию: это актуально для серверов. А у сервера обычно несколько клиентских сессий. Дай каждой ессии по отдельному ядру - и вот оно, параллельное счастье. Второй вариант - ценой небольшого лага резать поток на пакеты, и каждый пакет сжимать уже не потоково.

Комбинаторика и дифуры успешно параллелятся. И при этом люто актуальны.

> Из электроники просто дожимают соки - это факт.

Ничего лучше в ближайшие лет 10 не предвидится.

> не проблема, скажем перемножение матриц любой размерности за 1 импульс :)
> s/матриц любой размерности/векторов любого размера/ ofc

Afaik, размерность матриц ограничена сверху, причем не слишком-то впечатляющими значениями.
А векторы ... ну хотя бы 32-bit float точность удается обеспечить при таком умножении?

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

>Да ну? Можно попросить топ20 наиболее актуальных нераспараллеливаемых вычислительных задач?

1. Сжатие/распаковка данных словарными методами
2. Математика, численные методы (туева хуча задач)
3. Лексический/семантический анализ
Этого более, чем достаточно, мне кажется

>Дай каждой ессии по отдельному ядру - и вот оно, параллельное счастье

Это значит, что в любой момент времени юзеру (единственному, для примера) доступна мощность не более одного ядра, что как бы показательно

>Второй вариант - ценой небольшого лага резать поток на пакеты, и каждый пакет сжимать уже не потоково.

Это не только лаг, это ещё и потеря в степени сжатия, т.к. нужно сбрасывать словарь/статистику

>Ничего лучше в ближайшие лет 10 не предвидится.

Прямо таки железная аргументация: "раз ничего лучше не предвидется, то давайте говорить, что ничего другого и не нужно!" 8-D

>А векторы ... ну хотя бы 32-bit float точность удается обеспечить при таком умножении?

Точность ограничена лишь разрешением управляемого транспаранта

640 терабайт оперативки хватит всем

> 1. Сжатие/распаковка данных словарными методами

Зацикливаться на словарных методах не обязательно. Например, pbzip2 (многопоточная версия bzip2) с ростом числа ядер масштабирует свою производительность почти линейно.

LZMA, даром что словарный, поддерживает многопоточность.

> 2. Математика, численные методы (туева хуча задач)

Ага, и гораздо бОльшая куча таких задач параллелится.

> 3. Лексический/семантический анализ

Анализ чего? Текстов? На каждый текст по потоку - и получаем 100% распараллеливаемость.

>>Дай каждой ессии по отдельному ядру - и вот оно, параллельное счастье
> Это значит, что в любой момент времени юзеру (единственному, для примера) доступна мощность не более одного ядра, что как бы показательно

Только при условии, что юзер качает в одно соединение. Что довольно не типично ,)

>> Второй вариант - ценой небольшого лага резать поток на пакеты, и каждый пакет сжимать уже не потоково.

> Это не только лаг, это ещё и потеря в степени сжатия, т.к. нужно сбрасывать словарь/статистику

Полный сброс не обязателен. Некоторая потеря будет, но едва ли она смертельна.

> Прямо таки железная аргументация: "раз ничего лучше не предвидется, то давайте говорить, что ничего другого и не нужно!" 8-D

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

>>А векторы ... ну хотя бы 32-bit float точность удается обеспечить при таком умножении?

>Точность ограничена лишь разрешением управляемого транспаранта

Вопрос не в том, чем ограничена точность, а в том, какая точность на деле обеспечивается.

Да. Всех загонят на один большой vk.com cloud, на котором будет 640 терабайт оперативки.

>Зацикливаться на словарных методах не обязательно.

Та взять то же арифметическое кодирование или хаффмана (практически везде используется), профита от многоядерности - 0

>Например, pbzip2 (многопоточная версия bzip2) с ростом числа ядер масштабирует свою производительность почти линейно.

bzip довольно ограниченный сам по себе, поскольку делит входные данные на блоки, плюс от многоядерности есть, но до характеристик того же LZMA ему очень и очень далеко

>LZMA, даром что словарный, поддерживает многопоточность.

Только дополнительные проходы по окну, и только во время компрессии, т.е. улучшить степень сжатия оно может, но скорости по сравнению с однопоточным/однопроходным не добавит. Про распаковку вообще молчу.

>Ага, и гораздо бОльшая куча таких задач параллелится.

О, один раз попали! :)

>Анализ чего? Текстов? На каждый текст по потоку - и получаем 100% распараллеливаемость.

Т.е. ускорить анализ одного конкретного текста/исходника в данный момент времени - никак?

>Только при условии, что юзер качает в одно соединение. Что довольно не типично ,)

Опять же: если данные распаковываются по словарю/статистике из одного источника то это невозможно. Разбитие потока на N частей соответственно ухудшит характеристики метода сжатия. Т.е. шило на мыло.

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

Учим матчасть.

>Давайте думать, чего можно добиться в рамках реально имеющихся возможностей. И как этими возможностями распоряжаться. А не заниматься аутизмом, фапая на загоризонтные технологии.

Давайте не будем указывать другим, о чем им думать и писАть, ок?

>Вопрос не в том, чем ограничена точность, а в том, какая точность на деле обеспечивается.

Это перспектива, поскольку элементная база ещё не полностью сформирована. Если вам нужно "здесь и прямо чейчас" - берите существующее железо и считайте.

> Та взять то же арифметическое кодирование или хаффмана (практически везде используется), профита от многоядерности - 0. bzip довольно ограниченный сам по себе, поскольку делит входные данные на блоки, плюс от многоядерности есть, но до характеристик того же LZMA ему очень и очень далеко

За то голых арифметику и хаффмана bzip2 по степени сжатия превосходит :) И кто после этого ограниченный?

> Только дополнительные проходы по окну, и только во время компрессии, т.е. улучшить степень сжатия оно может, но скорости по сравнению с однопоточным/однопроходным не добавит.

Смешно. Давай сравнивать скорость при _одинаковой_ степени сжатия. С учетом того факта, что для не очень высоких степеней есть bzip2.

> Про распаковку вообще молчу.

Да совершенно аналогично можно распараллелить, порезав архив на крупные куски. Да, степень сжатия будет ниже. Tradeoff между степенью сжатия и скоростью - штука совершенно естественная.

> Т.е. ускорить анализ одного конкретного текста/исходника в данный момент времени - никак?

Нет смысла его ускорять.

>>Только при условии, что юзер качает в одно соединение. Что довольно не типично ,)

>Опять же: если данные распаковываются по словарю/статистике из одного источника то это невозможно. Разбитие потока на N частей соответственно ухудшит характеристики метода сжатия. Т.е. шило на мыло.

Давай возьмем случай скачивания веб-странички. Там совершенно естественным образом есть несколько потоков: фреймы с html, яваскрипты, картинки. Качется всё одновременно. Или, скажем, p2p сеть - в каждый момент времени множество фрагметов отдается, и множество фрагментов принимается.

>>>Прямо таки железная аргументация: "раз ничего лучше не предвидется, то давайте говорить, что ничего другого и не нужно!" 8-D
>>Давайте думать, чего можно добиться в рамках реально имеющихся возможностей. И как этими возможностями распоряжаться. А не заниматься аутизмом, фапая на загоризонтные технологии.
> Давайте не будем указывать другим, о чем им думать и писАть, ок?

Ты попытался угадать за меня, к чему я призываю. И не угадал. Пришлось тебя немного поправить. Разумеется, следовать озвученному призыву, или заниматься чем-то еще -- личное дело каждого. Указывать не берусь ,)

============================================

Не сомневаюсь, что в конечном итоге ты предложишь задачи, которые действительно нихрена не параллелятся. Ты уже предложил парсинг _одного_ Си-шного исходника.

Поинт в том, что при этом очень и очень многие задачи успешно распараллеливаются. И потому многоядерность несет очевидный профит. На 4-ядернике Си-шный проект собирается в 4 раза быстрее, чем на аналогичном одноядернике.

Глупо ругать многоядерность за то, что она - не серебряная пуля.

>За то голых арифметику и хаффмана bzip2 по степени сжатия превосходит :) И кто после этого ограниченный?

Это типа PPM оно превосходит?! Откуда дровишки? :-D У хаффмана более широкое применение, ему простительно.

>Смешно. Давай сравнивать скорость при _одинаковой_ степени сжатия.

Это проблематично, поскольку хоть и lzma2 побыстрее lzma, но иногда дает худшее сжатие, подробности ищи на форуме sf.net

>С учетом того факта, что для не очень высоких степеней есть bzip2.

bzip2 сливает lzma, его давно пора на свалку :)

>Нет смысла его ускорять.

Ну канечна, канечна... как стыкнулись с проблемой в лицо, так сразу "не нужно, нет смысла..." А зачем тогда многоядерность - чтоб больше электроэнергии потреблять? :D

>Давай возьмем случай скачивания веб-странички. Там совершенно естественным образом есть несколько потоков: фреймы с html, яваскрипты, картинки. Качется всё одновременно.

Ууу... :) Вот ты возьми архив какого-нибудь сайта, запакуй его 7zip без solid сжатия, а затем - 7zip с solid сжатием. Сравни размеры, а потом рассказывай мне о преимуществах раздельных потоков =)

>Или, скажем, p2p сеть - в каждый момент времени множество фрагметов отдается, и множество фрагментов принимается.

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

>Поинт в том, что при этом очень и очень многие задачи успешно распараллеливаются.

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

>Глупо ругать многоядерность за то, что она - не серебряная пуля.

Глупо совать её везде, ухудшая качества

>Глупо совать её везде, ухудшая качества

Где она суётся за счёт ухудшений качества?

>>За то голых арифметику и хаффмана bzip2 по степени сжатия превосходит

>Это типа PPM оно превосходит?! Откуда дровишки? :-D

Лихо ты обобщил :D Нет, оно превосходит конкретно арифметику и хаффмана. Дровишки с тех времен, когда я арифметику и хаффмана руками имплементил ,) Да это и не удивительно - bzip использовал на последнем этапе арифметику, а bzip2 использует вместо арифметики хаффмана. При этом разница в степени сжатия между bzip и bzip2 порядка 1% (если верить http://afni.nimh.nih.gov/pub/dist/doc/program_help/README.bzip2.html , раздел "RELATIONSHIP TO bzip-0.21").

> bzip2 сливает lzma, его давно пора на свалку :)

По скорости сжатия bzip2 существенно выигрывает. И на многоядернике разрыв в скорости еще сильнее возрастает.

> Ууу... :) Вот ты возьми архив какого-нибудь сайта, запакуй его 7zip без solid сжатия, а затем - 7zip с solid сжатием. Сравни размеры, а потом рассказывай мне о преимуществах раздельных потоков =)

Премущество здесь - _быстрый_ доступ к любому из файлов внутри архива. Solid нервно курит в сторонке.

Расскажи еще про solid для сжатых файловых систем :P

> Ну канечна, канечна... как стыкнулись с проблемой в лицо, так сразу "не нужно, нет смысла..." А зачем тогда многоядерность - чтоб больше электроэнергии потреблять? :D
> Это при условии, что имеется как минимум 2 однотипных слабо связанных задачи(вычислительных), а мы же говорим про ускорение конкретно одной.

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

> грубо говоря: наращивание ядер дает возможность увидеть _больше_ промежуточных результатов, наращивание производительности ядра - _быстрее_ получить решение. Количество и качество.

Гуманитарный бред. Получение решения (будь то решение системы дифуров, или собранный испольнимый файл, или сжатый bzip-ом архив) как раз вполне себе ускоряется с ростом количества ядер. Да, это не серебряная пуля. Но в среднем профита от многоядерности куда больше, чем от дофигабитности :)

Обсуждали уже пример с потоковым сжатием

>Обсуждали уже пример с потоковым сжатием

Где? Где в потоковом сжатии добавление ядер приводит к деградации???

>Лихо ты обобщил :D

А если ещё подумать над блочностью (которая является явным качественным ограничением), то можно представить блок как одну вычислительную задачу. Tradeoff.

>По скорости сжатия bzip2 существенно выигрывает. И на многоядернике разрыв в скорости еще сильнее возрастает.

а gzip -1 вообще всех рвет, и что? :)

>Премущество здесь - _быстрый_ доступ к любому из файлов внутри архива. Solid нервно курит в сторонке.

Да ну?! Что ж тогда tar делает в современном мире? :-D

>Расскажи еще про solid для сжатых файловых систем :P

Это частный случай, там файлы обычно жмутся блоками по 64к

>Мы говорим о целесообразности многоядерников.

Они целесообразны на данный момент и в ближайшей перспективе.

>> грубо говоря: наращивание ядер дает возможность увидеть _больше_ промежуточных результатов, наращивание производительности ядра - _быстрее_ получить решение. Количество и качество.

>Гуманитарный бред.

Если ты не понял, то я объясню ещё раз: в N-раз быстрее получить результат с помощью N-ядер можно _лишь только в том случае_, если результат вычисления можно получить из N-промежуточных значений, никак не связанных между собой - а это ой как сильно зависит от задачи и порой заставляет менять алгоритмы в ущерб какой-то характеристике. В то время как при N-раз более быстром одном ядре совершенно нет необходимости что-то менять, и результат _гарантированно_ будет получен в N-раз быстрее. Многоядерность это вынужденная мера, вызванная трудностями наращивания частот. Не вижу ни в чем вынужденном того, что стоит оправдывать.

>Где? Где в потоковом сжатии добавление ядер приводит к деградации???

не добавление ядер, а разбитие потока данных на N-последовательных/параллельных (аналогия - solid архивы и обычные)

> В то время как при N-раз более быстром одном ядре совершенно нет необходимости что-то менять, и результат _гарантированно_ будет получен в N-раз быстрее. Многоядерность это вынужденная мера, вызванная трудностями наращивания частот. Не вижу ни в чем вынужденном того, что стоит оправдывать.

Ну да, мечты о стремительном одноядернике разбились о чугунную попу реальности. Остается искать обходные пути. Многоядерность - один из таких путей. Другой путь - специализированные вычислители (крипто, 3д, видеодекодер, и тп). Специализированные cisc инструкции (по типу sse4.2). Повышение разрядности. Какие-нибудь intanium-подобные архитектуры. Наверное, есть и другие пути. Я размышляю об этом всем не как об оправданиях, а как о реально доступных направлениях развития. Одни лучше, другие - хуже...

>не добавление ядер, а разбитие потока данных

Ну так не разбивай. Пусть на одном ядре крутится. Делов-то :)

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

Самое забавное, что теперь стремительность пытаются считать числом этих разбитых мечтаний :-D

>Остается искать обходные пути. Многоядерность - один из таких путей.

Простой пример поиска в двоичном дереве, когда для того, чтобы найти нужный элемент в дереве глубиной N за 1 квант времени при мгновенном доступе к памяти потребуется 2^N-1 ядер (-сравнений) вместо N-раз-быстрого процессора как бы намекает, что этот путь рационален лишь до определённого предела. А вырезать меньшие транзисторы (чтоб впихнуть побольше ядер) c каждым разом всё труднее и труднее... Архитектуры тут особо не при чём, а вот элементная база - ещё как ;)

>реально доступных направлениях развития

Реально доступное сейчас на самом деле имеет весьма ограниченные возможности развития, поскольку роста числа ядер в геометрической прогрессии (при сохранении на уровне всех остальных параметров) вроде не планируется. Да и разговор изначально стартовал лишь о возможном, которое очень не скоро станет доступным :)

> Простой пример поиска в двоичном дереве, когда для того, чтобы найти нужный элемент в дереве глубиной N за 1 квант времени при мгновенном доступе к памяти потребуется 2^N-1 ядер (-сравнений) вместо N-раз-быстрого процессора как бы намекает, что этот путь рационален лишь до определённого предела.

Вне зависимости от устройства процессора, сбалансированному дереву глубиной N потребуется 2^N памяти. Отсюда следует, что глубина такого дерева большой быть не может.

В целом же не спорю: некоторые задачи заведомо не параллелятся.

> Архитектуры тут особо не при чём, а вот элементная база - ещё как ;)

Более совершенной базы пока нет даже в спец лабораториях. Оптика - когда ее допилят - тоже не будет серебряной пулей (что, однако, не лишает её права на существование).

> Отсюда следует, что глубина такого дерева большой быть не может.

.... И потому нужды ускорять единичный акт поиска - нет.

fixed