Миф: как IBM победил БЭСМ

[Dmitry67]

Ну этим компом можно было хвастаться два года назад, когда он был новый, сейчас я из него вырос, и after effects ругается, что памяти мало (я видео обрабатываю)

[Dmitry67]

Кстати с точки зрения лицензии на ms sql, в виртуальных машинах лучше hyperthreading отключать

[Vladimir1440]

Ну этим компом можно было хвастаться два года назад...

Xорошо Вам, завидую. В моиx краяx и 8 гигабайт на воркстейшене или лаптопе - "много" (обычно - четыре). Но правда я не девелопер или какой еще такой (занятый тем что гоняет какой-то софт для какой-то цели) чел. И в моем окружении - все такие (как я) в основном.

[zVlad]

Большое количество коров (в том числе виртуальных - HyperThreading) на chip-e Intel и AMD обясняется двумя обстоятельствами:

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

2. Что с ней делать не понятно.

Выпуская лишь chip-ы для CPU Intel и AMD не знают где и как его будут использовать производители компютеров: серверов, десктопов и лаптопов. Производители серверов, десктопов и лаптопов в свою очередь не знают какие ОС и софт будет на их изделиях крутиться. Поэтому делать что-либо осмысленное в схемотехнике CPU Intel и AMD не могут, просто не знают что. Кроме того они могут поддерживать спрос на свои CPU толькоо снижая цену на единицу мощности. Поэтому всякиe новации в виде специализированных компонентов CPU как то аппаратная поддержка сжатия, криптографии и сложной арифметики, а также увеличение размеров внутреннего кэша оплачивать никто не будет. Делать малую серию специализированных chip-ов тоже видимо не их модель бизнеса. Да и для кого это делать тоже не понятно.

Вот они и удут простейшим и гарантирующим продажи путем - увеличивают количество виртуальных CPU в chip-e.

Тут явно просматривается тупичок - виртуальных CPU стало уже больше чем нужно - знакомый DBA MS SQL говорил что они вынужденны ограничивать MS SQL чтобы он не использовал всех доступных системе CPU.

Если бы я ничего не сказал про MF меня бы не поняли. На MF другая ситуация. IBM знает для чего делает свои chip-ы. Набор ОС ограничен и главное все они, за исключением Linux, тоже делаются в IBM, а следовательно могут дружно быть изменены чтобы задействовать новые возможности CPU. ИБМ может расширять набор команд CPU настолько насколько это позволяет технология, увеличивать размеры кэша, внедрять "Out-of-order" выполнение команд, ставить на чип сжатие, криптографию и арифметику с плавающей точкой. При этом ИБМ не гонится за количеством кор на chip-e (их "всего" шесть на данный момент), но они имеют гораздо большие размеры кэша (три уровня на самом chip-e и один внешний) и многое другое, причем каждый кор имеет:

http://www.redbooks.ibm.com/redbooks/pdfs/sg248049.pdf
(стр. 41)

Each processor unit, or core, is a superscalar, out-of-order processor that has six execution
units:
- Two fixed point (integer)
- Two load/store
- One binary floating point
- One decimal floating point

Up to three instructions can be decoded per cycle, and up to seven instructions/operations
can be initiated to run per clock cycle (<0.18 ns). The execution of the instructions can occur
out of program order, and memory address generation and memory accesses can also occur
out of program order. Each core has special circuitry to display execution and memory
accesses in order to the software. Not all instructions are directly run by the hardware, which
is the case for several complex instructions. So me are run by millicode, and some are broken
into multiple operations that are then run by the hardware.
The following functional areas are on each core, as shown in Figure 2-11 on page 43:
- Instruction sequence unit (ISU): This unit enables the out-of-order (OOO) pipeline. It
tracks register names, OOO instruction dependency, and handling of instruction resource
dispatch.
This unit is also central to performance measurement through a function called
instrumentation.
- Instruction fetching unit (IFU) (prediction): These units contain the instruction cache,
branch prediction logic, instruction fetching controls, and buffers. Its relative size is the
result of the elaborate branch prediction design. For more information, see 3.4.2,
“Superscalar processor” on page 86.
- Instruction decode unit (IDU): The IDU is fed from the IFU buffers, and is responsible for
parsing and decoding of all z/Architecture operation codes.
- Load-store unit (LSU): The LSU contains the data cache. It is responsible for handling all
types of operand accesses of all lengths, modes, and formats as defined in the
z/Architecture.
- Translation unit (XU): The XU has a large translation lookaside buffer (TLB) and the
Dynamic Address Translation (DAT) function that handles the dynamic translation of
logical to physical addresses.
- Fixed-point unit (FXU): The FXU handles fixed-point arithmetic.
- Binary floating-point unit (BFU): The BFU handles all binary and hexadecimal
floating-point and fixed-point multiplication operations.
- Decimal floating-point unit (DFU): The DU runs both floating-point and decimal fixed-point
operations and fixed-point division operations.
- Recovery unit (RU): The RU keeps a copy of the complete state of the system that
includes all registers, collects hardware fault signals, and manages the hardware recovery
actions.
- Dedicated Co-Processor (COP): The dedicated coprocessor is responsible for data
compression and encryption functions for each core.

[АццкоМото]

Большое количество коров

Ходит по улицам Бангалора

2. Что с ней делать не понятно.

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

[Palych]

Большое количество коров

Ходит по улицам Бангалора

2. Что с ней делать не понятно.

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

Причём в случае серверов вообще нет проблемы распараллеливания: параллельные запросы требуют параллельных вычислений.
(я подозреваю что это имелось в виду под непонятками)

[Dmitry67]

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

Массивнопарралельный подход GPU мне кажется более перспективным. Хочу ОС которая работает чисто на GPU

[zVlad]

... Все это перетерли еще лет 10 назад.

И что за десять лет ничего не изменилось? Я имею в виду в первую очередь опыт использования много-много-много коровых установок. Дают ли они адекватную отдачу? Линейный рост производительности на реальных задачах?

[zVlad]

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

Массивнопарралельный подход GPU мне кажется более перспективным. Хочу ОС которая работает чисто на GPU

Напишите сами и назовите ее "Dima 1-2-3"

[Palych]

Кстати, БЭСМ похоже возвращается: http://www.softmachines.com/technology/
Здесь вроде по-лучше описано: http://www.tomshardware.com/news/visc-v ... 27958.html
Удастся ли взять реванш, показать буржуинам мать Кузьмы?

[oshibka_residenta]

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

Массивнопарралельный подход GPU мне кажется более перспективным. Хочу ОС которая работает чисто на GPU

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

[Palych]

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

Массивнопарралельный подход GPU мне кажется более перспективным. Хочу ОС которая работает чисто на GPU

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

А мне кажется что базы данных как отдельные единицы должны умереть, раствориться между OS and Application Server.
Чтобы ось предоставляла доступ к storage не в виде файловой системы, а чего-то вроде NoSQL базы.
А приложение было бы построено так, чтобы предоставлять данные в разном виде чисто виртуально, не копируя в памяти мегабайты для каждого запроса только чтобы сделать их "удобными"...

[АццкоМото]

Причём в случае серверов вообще нет проблемы распараллеливания: параллельные запросы требуют параллельных вычислений.
(я подозреваю что это имелось в виду под непонятками)

Ага. И можная нынче виртуализация со всеми этими облаками - абсолютно соответствует концепции..

Как и сдвиг парадигмы прошраммирования

[АццкоМото]

... Все это перетерли еще лет 10 назад.

И что за десять лет ничего не изменилось? Я имею в виду в первую очередь опыт использования много-много-много коровых установок. Дают ли они адекватную отдачу? Линейный рост производительности на реальных задачах?

За 10 лет стало очевидно, что направление, которое очерчивали 10 лет назад - работает. Stay in course - результат этой декады

Каждый раз гугля сиськи очередной селебрити или выкладывая фоточку в фейсбучек стоит об этом вспоминать

[zVlad]

...
За 10 лет стало очевидно, что направление, которое очерчивали 10 лет назад - работает. Stay in course - результат этой декады
...

Это так потому лишь что ничего Вам другого за 10 лет не предложили. А не пресложили потому что не имеют что предлагать.
А вот если бы предложили, то пели бы Вы совсем другую песню. Не просиськи.
И это не только в ИТ. Вы ездите на машинах предложенных Вам, едите предложенную пищу и носите предложенную одежду, смотрите кино и слушаете те песни что Вам предложены.

И Вы не знаете альтернатив тому что предложено. А это значит - Вы не можете выбирать. Ваш выбор предопределен предложенным.

[АццкоМото]

...
За 10 лет стало очевидно, что направление, которое очерчивали 10 лет назад - работает. Stay in course - результат этой декады
...

Это так потому лишь что ничего Вам другого за 10 лет не предложили. А не пресложили потому что не имеют что предлагать.
А вот если бы предложили, то пели бы Вы совсем другую песню. Не просиськи.
И это не только в ИТ. Вы ездите на машинах предложенных Вам, едите предложенную пищу и носите предложенную одежду, смотрите кино и слушаете те песни что Вам предложены.

И Вы не знаете альтернатив тому что предложено. А это значит - Вы не можете выбирать. Ваш выбор предопределен предложенным.

А давайте не переходить на личности? Или - беттер йет - не скакать с субжа на субж?

Вы утверждали, что глупцы из Интела и АМД не знают, что делать с большим количеством ядер. Я вам заметил - что и они и индустрия прекрасно знают.
наличие же "выбора" - это совсем другой вопрос. очевидно, что выбор таки есть - есть все эти x86 vs ARM, CPU vs GPU, CUDA vs... забыл название. а если сильно хочется выбора уаще другого - то вон в "о жизни" жара идет, что людей создали какие-то тараканы с обратной стороны луны. ну, в смысле фантазия прет как раз там

[oshibka_residenta]

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

Ну вы сравнили: где глупцы из Intel или, прости господи, AMD и где гигант мысли, отец русской канадской демократии.

[Palych]

... Все это перетерли еще лет 10 назад.

И что за десять лет ничего не изменилось? Я имею в виду в первую очередь опыт использования много-много-много коровых установок. Дают ли они адекватную отдачу? Линейный рост производительности на реальных задачах?

Кстати, линейный рост производительности не является адекватной задачей.
Я уверен все современные кластерные технологии не дотягивают до линейного роста. (кроме МФ конечно)
Как говорится - so what?

[АццкоМото]

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

Ну вы сравнили: где глупцы из Intel или, прости господи, AMD и где гигант мысли, отец русской канадской демократии.

Извиняюсь. Действительно, что-то я зазвезделся.

[zVlad]

....Вы утверждали, что глупцы из Интела и АМД не знают, что делать с большим количеством ядер.....

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

[zVlad]

.... очевидно, что выбор таки есть - есть все эти x86 vs ARM, CPU vs GPU, CUDA vs... забыл название. ...

Это не выбор, это просто разные вещи сделанные для разного. Мы здесь толкуем о скучных вещах обычно - о БД, об ОС, о скучных программах считающих деньги или штуки сукна на складе, или болячки, или сколько деталей и каких в атомном реакторе. Вот когда GPU смогут это делать (Вы скажете уже могут, но тогда покажите как и где они это делают) в том же ценовом диапазоне и с тем же качеством как хотя бы Intel вот тогда, и то условно, у Вас появится выбор.

[zVlad]

... Все это перетерли еще лет 10 назад.

И что за десять лет ничего не изменилось? Я имею в виду в первую очередь опыт использования много-много-много коровых установок. Дают ли они адекватную отдачу? Линейный рост производительности на реальных задачах?

Кстати, линейный рост производительности не является адекватной задачей.
Я уверен все современные кластерные технологии не дотягивают до линейного роста. (кроме МФ конечно)
Как говорится - so what?

Значит есть предел роста, а то Вы не знаете сами. Я не имею в виду некоторые задачи типа тех что делает Google, который фактически облако уже давно. Я имею в виду большие задачи где надо давать ответ не в общем, а вполне конкретно, не варианты, а то что есть на самом деле.

[АццкоМото]

.... очевидно, что выбор таки есть - есть все эти x86 vs ARM, CPU vs GPU, CUDA vs... забыл название. ...

Это не выбор, это просто разные вещи сделанные для разного. Мы здесь толкуем о скучных вещах обычно - о БД, об ОС, о скучных программах считающих деньги или штуки сукна на складе, или болячки, или сколько деталей и каких в атомном реакторе. Вот когда GPU смогут это делать (Вы скажете уже могут, но тогда покажите как и где они это делают) в том же ценовом диапазоне и с тем же качеством как хотя бы Intel вот тогда, и то условно, у Вас появится выбор.

А! Вот в чем дело
Ну дык со скучными задачами вы справились еще в прошлом веке. Спасибо и можете умирать

[АццкоМото]

....Вы утверждали, что глупцы из Интела и АМД не знают, что делать с большим количеством ядер.....

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

А давайте!
Вот цитата:

Большое количество коров (в том числе виртуальных - HyperThreading) на chip-e Intel и AMD обясняется двумя обстоятельствами:

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

2. Что с ней делать не понятно.

5 минут на поиск саморефлексии типа "мне кажется". Время пошло. Время вышло. Не нашли? А это потому что было вполне четкое утверждение, с которым я не согласился

[Palych]

Я уверен все современные кластерные технологии не дотягивают до линейного роста. (кроме МФ конечно)
Как говорится - so what?

Значит есть предел роста, а то Вы не знаете сами. Я не имею в виду некоторые задачи типа тех что делает Google, который фактически облако уже давно. Я имею в виду большие задачи где надо давать ответ не в общем, а вполне конкретно, не варианты, а то что есть на самом деле.

Предел есть всему.
Или Вы хотите сказать что есть задачи которые в принципе не возможно реализовать на PC servers?