Предела нет, поверь. Предела нет.

Помнится, когда я в первый раз увидел скриншоты из тогда еще грядущего STALKER-а(где-то за два года до релиза), мне сделалось попросту дурно от качества графики. Но потом, естественно, попривык.

>>26645
Квантовые компьютеры. Или целые кластеры сверхмощных многопроцессорных суперкомпьютеров. Предела нет. Мы живём в удивительную эпоху.

>>26650
сталкер - говно

>>26654
Это твое личное мнение. Мне тоже не нравится, но я вижу, что даже на операторчане о нем говорят постоянно.

>>26654>>26656
Баттхёрт на моём новере?!
It's more likely then you think.

>>26651

> Квантовые компьютеры.

Не существует ни одного рабочего образца.

> целые кластеры сверхмощных многопроцессорных суперкомпьютеров

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

>>26656
Потому, что там фап на оружие.

>>26659

>http://www.newscientist.com/article/dn18154-first-universal-programmable-quantum-computer-unveiled.html

уцухо, анепиздишь.пнг?

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

>>26662

>http://www.newscientist.com/article/dn18154-first-universal-programmable-quantum-computer-unveiled.html

Не слышал. Олсо слова "each gate is more than 90 per cent accurate" весьма настораживают, поскольку невозможно реализовать машинку Тьюринга на устройстве которое может ошибаться невозможно.

> технологический процесс дешевеет

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

> можно делать кластеры

Не все задачи хорошо распаралеливаются. Можно даже сказать что задач, которые можно хорошо распараллелить не так уж и много. Если организовать соединение между узлами кластера по шине то производительность упрется в эту шину, если между всеми узлами организовать соединение точка-точка то понадобится n*(n-1)/2 соединений.

>>26665

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

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

>соединение между узлами кластера по шине

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

>>26736

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

Верно только для сферических программ в вакууме и для научных задач. Прикладные же задачи распараллеливаются плохо, по крайней мере в том виде, в котором их пишет большинство программистов. Иногда получается что в несколько потоков программа работает хуже чем в один, а все потому что задачи требуют частой синхронизации.
Например в XviD начиная с 1.1.3 ввели поддержку многопоточности, но выигрыш я видел только при использовании двух потоков, если задать больше до будет съедено указанное количество ядер/процессров но общая скорость даже ниже чем при использовании одного потока.

> соединение вида тор или гиперкуб, или, например, дерево

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

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

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

>>26747

> потому что надо писать параллельную программу, а не какую-то там. и это совсем не сложно.

Как можно распараллелить допустим рендеринг странички в браузере?

> как во всех @home

Что-то мне еще не попадалось S.T.A.L.K.E.R.@home или что-нибудь в этом роде.

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

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

>>26752

> это не та задача, которую нужно параллелить

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

> в компьютерной графике, например, можно рендерить каждый пиксель отдельно

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

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

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

>>26757
мм, ты не прав.

>>26760

> мм, ты не прав.

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

>>26761
так, смотри, вот про пропускную способность шины- мы можем использовать дерево с подшефными центрами(если я правильно помню, такая архитектура используется в jugene, наряду с тором), это раз. во-вторых, гиперкуб может быть любой размерности, я его не зря упомянул. например гиперкуб 5 степени, реализуется как куб с гиперкубами в вершинах, если я правильно посчитал. так что обмен идёт в себе подобной сложной структуре, и ветви параллельной программы пишутся соответственно для гиперкубов разных вершин, это достаточно просто.
вообще большинство сложных задач упирается в матрицы и циклы, как я уже говорил, и ничего мудрить не надо.
далее, в большом вычислительном кластере вообще ничего параллелить не надо, он будет выгоден за счёт того, что запросы от множества пользователей будут на 100% загружать процессоры, или же можно выдавать параллельным программам части того же гиперкуба, например.
потом, программируемость структуры подразумевает, что мы можем изменять структуру соединений вычислителей вс(на самом деле это делается автоматически) для поддержания максимальной производительности, сымитировать пространственную структуру процесса, например.
вот. а на гпу, например, уже опера странички рендерит.
всё вроде как.

>>26763

> большинство сложных задач упирается в матрицы и циклы

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

>>26769
ооп в моих суперкомпьютерах?! ноу вей.