Ещё одна священная война: mainframes vs x86 servers

Forum rules
zVlad
Уже с Приветом
Posts: 15420
Joined: 30 Apr 2003 16:43
Has thanked: 1 time

Post by zVlad »

Dmitry67 wrote:
zVlad wrote: Я Вам приведу пару других личных примеров.
Один из наших клиентов вот уже года три-четыре "избавляется" от МФ. Клиент этот заморозил все апгрейды (за исключением z/OS). Клиент этот использует доисторическую версию ДБ2 - версию 6, и доисторический CICS.
Последнее что я слышал о них это то что за их миграцию на платформу Unix с них запросили такие деньги что они просто... задумались. И второе сообщение от программистов что клиент этот заказывает существенные кастомизации их приложения.

Другой пример из этой конторы где я работаю. Рассказывал мне об этом мой предшественник, работавший системщиком в середине 90-х. Тогда к руководству "подкатило" НР с предложением заменить МФ гораздо более дешевым железом. Решили тогда подойти к теме по научному: прогнать некоторый объем работы на МФ и тот же объем на НР. Не вдаваясь в детали могу сказать что результаты получились очень печальные для НР. Рассказчик ездил в командировку к НР и просто не должался окончания прогона, ему нужно было на самолет. Решение естественно было принято в пользу НР.


По моему оба примера не в пользу МФ
1. В первом клиента держит только стоимость перехода на другую платформу. Он всеми силами пытается сорваться c крючка, так что это дело времеми

2. Второй, очевидно, тоже (победителей не судят)
К тому же вы не знаете какие причины были в выборе HP.
Может быть, цена "рабства" тоже была учтена


1. Дело в том, Дима, что у нас два клиента - оба юзают одно и тоже приложение (версии только у них разошлись). Второй клиент никуда с МФ в обозримом будущем не собирается. Этот второй клиент вовремя делает апгрэйды. Если бы была поставленна такая задача сократить расходы на МФ, то ее можно было бы решить сократив процентов на 20-30% эти расходы.

2. И Вы Дима не знаете тех причин, поэтому не надо фантазировать. Но может и была тогда цена "рабства", в таком случае сейчас наши клиенты платят цену "рабства" платформе Интел.
Top
User avatar
Flash-04
Уже с Приветом
Posts: 63430
Joined: 03 Nov 2004 05:31
Location: RU -> Toronto, ON

Post by Flash-04 »

zVlad wrote: Еще раз. Если бы МФ был заморожен то тогда да грань, как Вы говорите, стиралась бы. Но ИБМ постоянно продвигают МФ.

экстенсивным методом IMHO :roll: стало мегагерц больше, больше каналов, каналы стали быстрее. но принципиально все то же самое :umnik1:
в то же время легко заметить что Intel/AMD постоянно что-то делают революционное, так что разрыв все же стирается.
Top
zVlad
Уже с Приветом
Posts: 15420
Joined: 30 Apr 2003 16:43
Has thanked: 1 time

Post by zVlad »

Flash-04 wrote:.....
экстенсивным методом IMHO :roll: стало мегагерц больше, больше каналов, каналы стали быстрее. но принципиально все то же самое :umnik1:
....


Позволю себе спросить на основании чего сделан такой вывод об экстенсивном методе?
Вы слыхали о таком:

Specialty engines

Это довольно революционное и свежее решение. И можно приводить другие примеры.

С другой стороны, и это один из моих поинтов, архитектура МФ была изначально задумана верно для тех применений в которых МФ позиционировался и позиционируется. Поэтому внешнему наблюдателю (пользователю) могут быть незаметны внутренние иновации. Другая картина с Интел. Задуманый как дешевый процессор для идивидуального пользования он изначально имел архитектуру "общая шина" и огромные прорехи в надежности и секьюрити, с которыми в далейшем Интел и боролся мужественно.
Top
User avatar
Flash-04
Уже с Приветом
Posts: 63430
Joined: 03 Nov 2004 05:31
Location: RU -> Toronto, ON

Post by Flash-04 »

слыхал :D IBM любит их перечислять.
Top
User avatar
Dmitry67
Уже с Приветом
Posts: 28294
Joined: 29 Aug 2000 09:01
Location: SPB --> Gloucester, MA, US --> SPB --> Paris

Post by Dmitry67 »

Думаю, обе технологии тупиковы on the long run

Мегагарцы ограничены, число процессоров с общей памяти тоже
Будущее за слабосвязанными системами a la Google
Microsoft framework сделает какой нибудь чтобы не думать
Кстати они уже давно работают над анализатором кода. Пишите на .Net, а код анализируется на предмет возможного распарралеливания

Думаю в будущем одна и так же программа будет расползаться на имеющееся в наличие число процессоров сама, меняя степень парралелизма по ходу дела, процпессы эти сами как то сигналами будут обмениваться, синхронизироваться... И все без строчки кода... Как сейчас ничего не надо переделывать для x64 и x86 - один и тот же EXE идет
Зарегистрированный нацпредатель, удостоверение N 19719876044787 от 22.09.2014
Top
dB13
Уже с Приветом
Posts: 1494
Joined: 08 May 2001 09:01
Location: Silicon Valley

Post by dB13 »

zVlad wrote:Хорошо. Давайте поездим на вашем любимом коньке - ценах:

Big Blue cheaper than Red Hat, says research firm


running 10 to 50 applications on a mainframe costs less than running the same workload on a one server/one application basis where the servers run Linux or Solaris.

:funny:

В той же заметке:
However, the idea that one server runs one application is going to be far from the norm in today's data centers, where virtualization means multiple applications will run per physical server. VMware, Xen and Solaris containers are completely changing the server application landscape, and server utilization levels are shooting up as virtualized servers run many more applications.


Виртуализация была последним большим преимуществом MF перед x86/x64 servers.
Top
Palych
Уже с Приветом
Posts: 13731
Joined: 16 Jan 2001 10:01

Post by Palych »

Dmitry67 wrote:Думаю, обе технологии тупиковы on the long run

Мегагарцы ограничены, число процессоров с общей памяти тоже
Будущее за слабосвязанными системами a la Google

Возможно, только то что описано ниже:
Microsoft framework сделает какой нибудь чтобы не думать
Кстати они уже давно работают над анализатором кода. Пишите на .Net, а код анализируется на предмет возможного распарралеливания

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

По-моему как раз движение в противоположном направлении.
Прозрачное распараллеливание разносит задачу в Threads, которые суть "процессы" с общей памятью. (Кстати, несмотря на мою нелюбовь к M$, мне понравилась презентация их дополнений к C++, которую тут кто-то приводил с год назад).
Чтобы система была слабосвязанной (если я правильно понимаю) она должна проектироваться из расчёта на минимальный трафик между компонентами...
А вообще - не думаю что ресурсы многопроцессорности так уж быстро исчерпаются...
Top
User avatar
f_evgeny
Уже с Приветом
Posts: 10367
Joined: 12 Apr 2001 09:01
Location: Lithuania/UK

Post by f_evgeny »

Dmitry67 wrote:Думаю в будущем одна и так же программа будет расползаться на имеющееся в наличие число процессоров сама, меняя степень парралелизма по ходу дела, процпессы эти сами как то сигналами будут обмениваться, синхронизироваться... И все без строчки кода... Как сейчас ничего не надо переделывать для x64 и x86 - один и тот же EXE идет

Ну-ну...
Top
User avatar
KP580BE51
Уже с Приветом
Posts: 15007
Joined: 14 Jun 2005 11:50
Location: Ukraine

Post by KP580BE51 »

f_evgeny wrote:
Dmitry67 wrote:Думаю в будущем одна и так же программа будет расползаться на имеющееся в наличие число процессоров сама, меняя степень парралелизма по ходу дела, процпессы эти сами как то сигналами будут обмениваться, синхронизироваться... И все без строчки кода... Как сейчас ничего не надо переделывать для x64 и x86 - один и тот же EXE идет

Ну-ну...

ИМХО, вполне реально. GCC придется снова переделывать. :lol:
Top
User avatar
Flash-04
Уже с Приветом
Posts: 63430
Joined: 03 Nov 2004 05:31
Location: RU -> Toronto, ON

Post by Flash-04 »

да фиг там, насколько я помню для суперкомпьютеров с высокой степенью параллелизма (типа Крей) было важно написать правильный алгоритм, иначе получался затык, и вместо суперкомпьютера получался просто быстрый компьютер. Оптимизировать же произвольный код для параллельного исполнения, IMHO очень сложно.
Top
User avatar
Dmitry67
Уже с Приветом
Posts: 28294
Joined: 29 Aug 2000 09:01
Location: SPB --> Gloucester, MA, US --> SPB --> Paris

Post by Dmitry67 »

А что народ думает о такой идее

Сейчас есть отдельно память, отдельно процы. А что если делать их вместе в виде таких active cells: проц, небольшая память она же кеш, + энергонезависимая копия той же памяти

Такие cells объединяются в гриды с миллионами элементов и неким аналогом общей шины. Каждый cell хранит записи, типа отпечатков пальцев например, 10-1000 объектов. Индексов в такой базе нет

Делаем
select * from Fingerprints where matchlevel(FingerPrint,@Search)>0.99

Команда идет на все процы такой базы. Осталось подождать пару миллисекунд, какой проц поднимет руку - я нашел
Зарегистрированный нацпредатель, удостоверение N 19719876044787 от 22.09.2014
Top
User avatar
Flash-04
Уже с Приветом
Posts: 63430
Joined: 03 Nov 2004 05:31
Location: RU -> Toronto, ON

Post by Flash-04 »

довольно старая идея, насколько я знаю.
Top
User avatar
f_evgeny
Уже с Приветом
Posts: 10367
Joined: 12 Apr 2001 09:01
Location: Lithuania/UK

Post by f_evgeny »

KP580BE51 wrote:
f_evgeny wrote:
Dmitry67 wrote:Думаю в будущем одна и так же программа будет расползаться на имеющееся в наличие число процессоров сама, меняя степень парралелизма по ходу дела, процпессы эти сами как то сигналами будут обмениваться, синхронизироваться... И все без строчки кода... Как сейчас ничего не надо переделывать для x64 и x86 - один и тот же EXE идет

Ну-ну...

ИМХО, вполне реально. GCC придется снова переделывать. :lol:

Вышел релиз новой ветки набора компиляторов GCC 4.2.

Особенности новой версии:
......
# В компиляторы C, C++ и Fortran добавлена поддержка техники параллельного программирования OpenMP.
.....

Но, подавляющее большинство существующих программ написано, так, что их нельзя распараллелить. Для параллельного выполнения программы нужно писать специальным образом и гимора это добавляет немало. Хотя есть некоторые области, которые легко их хорошо распараллеливаются (ОС, компиляция и т.д.) Но не думаю, чтобы здесь были серьезные прорывы.
Top
User avatar
KP580BE51
Уже с Приветом
Posts: 15007
Joined: 14 Jun 2005 11:50
Location: Ukraine

Post by KP580BE51 »

Dmitry67 wrote:А что народ думает о такой идее

Сейчас есть отдельно память, отдельно процы. А что если делать их вместе в виде таких active cells: проц, небольшая память она же кеш, + энергонезависимая копия той же памяти

Такие cells объединяются в гриды с миллионами элементов и неким аналогом общей шины. Каждый cell хранит записи, типа отпечатков пальцев например, 10-1000 объектов. Индексов в такой базе нет

Делаем
select * from Fingerprints where matchlevel(FingerPrint,@Search)>0.99

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

Делают так. Broadcast UDP Message.
Top
User avatar
KP580BE51
Уже с Приветом
Posts: 15007
Joined: 14 Jun 2005 11:50
Location: Ukraine

Post by KP580BE51 »

f_evgeny wrote:Но, подавляющее большинство существующих программ написано, так, что их нельзя распараллелить. Для параллельного выполнения программы нужно писать специальным образом и гимора это добавляет немало. Хотя есть некоторые области, которые легко их хорошо распараллеливаются (ОС, компиляция и т.д.) Но не думаю, чтобы здесь были серьезные прорывы.

В подавляющем большинстве программ, 90 процентов времени, исполняется 10 процентов кода. И какие из существующих программ, нужно оптимизировать?
Top

Return to “Вопросы и новости IT”