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

User avatar
Medium-rare
Уже с Приветом
Posts: 9157
Joined: 04 Mar 2011 03:04
Location: SFBA

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

Post by Medium-rare »

StrangerR wrote: Да нет, тред легко заменяется процессами с общей памятью. По сути это почти одно и тоже, с некоторыми отличиями (у тредов общего больше чем просто общая память данных при самостоятельной памяти стеков).
Ежедневно мутя с потоками, такая радость, их заменить на процессы с общей памятью, не так просто приходит в голову. Лучше сразу убиццо апстену. Деформация такая. Тупеем потихоньку. :)
... and even then it's rare that you'll be going there...
User avatar
Dmitry67
Уже с Приветом
Posts: 28233
Joined: 29 Aug 2000 09:01
Location: SPB --> Gloucester, MA, US --> SPB --> Paris

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

Post by Dmitry67 »

Ну вот Оракл по моему написан большими процессами с общей памятью. Но на запуск большого процесса overhead больше
Зарегистрированный нацпредатель, удостоверение N 19719876044787 от 22.09.2014
User avatar
tengiz
Уже с Приветом
Posts: 4468
Joined: 21 Sep 2000 09:01
Location: Sammamish, WA

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

Post by tengiz »

Dmitry67 wrote:Кстати, когда то попробовал в ms sql "fibers". Разницы не почувствовал, разве что перестали работать distributed transactions
Это потому, что во-первых, MS SQL и так работал с "настоящими" threads, как если бы они были почти "fibers", во-вторых, они имеют смысл для очень высокопроизводительных сценариев (много процессоров, много их утилизации). Ну и таки да, ошибки были - и в MS SQL и в библиотеке файберов в ОС.
Cheers
User avatar
tengiz
Уже с Приветом
Posts: 4468
Joined: 21 Sep 2000 09:01
Location: Sammamish, WA

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

Post by tengiz »

Dmitry67 wrote:Ну вот Оракл по моему написан большими процессами с общей памятью.
Это уже давно не совсем так у Оракла.
Cheers
User avatar
Dmitry67
Уже с Приветом
Posts: 28233
Joined: 29 Aug 2000 09:01
Location: SPB --> Gloucester, MA, US --> SPB --> Paris

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

Post by Dmitry67 »

Угу, но начинали они по моему с этого.
Зарегистрированный нацпредатель, удостоверение N 19719876044787 от 22.09.2014
User avatar
tengiz
Уже с Приветом
Posts: 4468
Joined: 21 Sep 2000 09:01
Location: Sammamish, WA

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

Post by tengiz »

Dmitry67 wrote:Угу, но начинали они по моему с этого.
Yes, indeed.
Cheers
User avatar
Dmitry67
Уже с Приветом
Posts: 28233
Joined: 29 Aug 2000 09:01
Location: SPB --> Gloucester, MA, US --> SPB --> Paris

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

Post by Dmitry67 »

Хотелось бы вернуться к нашим баранам. Как я говорил, в бэсм была очень неудобная работа со строками. А как в эльбрусе? Там ведь тоже только огромные слова адресуются вроде бы
Зарегистрированный нацпредатель, удостоверение N 19719876044787 от 22.09.2014
zVlad
Уже с Приветом
Posts: 14939
Joined: 30 Apr 2003 16:43

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

Post by zVlad »

Dmitry67 wrote:....
А сейчас threads на z/OS конечно есть, в виртуалках

...
Мне об этом ничего не известно. Поделитесь откуда дровишки.
Сочетание z/OS и виртуалки тоже режет слух мне, системному прогаммисту z/OS. Поясните что имелось Вами в виду.
User avatar
Dmitry67
Уже с Приветом
Posts: 28233
Joined: 29 Aug 2000 09:01
Location: SPB --> Gloucester, MA, US --> SPB --> Paris

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

Post by Dmitry67 »

Ну так в виртуалках у вас юникс, правильно?
Зарегистрированный нацпредатель, удостоверение N 19719876044787 от 22.09.2014
StrangerR
Уже с Приветом
Posts: 37214
Joined: 14 Dec 2006 20:13
Location: USA

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

Post by StrangerR »

Вот еще по Эльбрусу. Эль-76 - Ада+Java в одном флаконе, в 70-е годы, с полной динамикой объектов.

http://forum.oberoncore.ru/viewtopic.ph ... 3&start=60
zVlad
Уже с Приветом
Posts: 14939
Joined: 30 Apr 2003 16:43

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

Post by zVlad »

Да туману вы здесь по поводу thread нагнали много. И никто не привел ни одного определения. Я пока буду (если вы не возражаете) понимать это как:
Multithreading is the ability for a program to multitask within itself. The program can split itself into
separate "threads" of execution that also seem to run concurrently. This concept might at first seem
barely useful, but it turns out that programs can use multithreading to perform lengthy jobs in the
background without requiring the user to take an extended break away from their machines. Of course,
sometimes this may not be desired: an excuse to take a journey to the watercooler or refrigerator is
often welcome! But the user should always be able to do something on the machine, even when it's
busy doing something else.
На МФ для этого используется два механизма - создание такого же unit of work как и основная задача (TCB), и SRB, о котором я уже говорил (не совсем корретно честно говоря). SRB - это облегченный вариант TCB с некоторыми ограничениями (например в них не допускаются операции ввода выводы и обращения к супервизору т.е. SVC (API по вашему). Т.е. строго говоря SRB не есть средство доступное бизнес программистам и вряд ли доступно на языках высокого уровня. Это среддтво для системного програмирования только. Таким образом на МФ есть один единый способ распаллеливания задачи - это создание новых задач, с точки зрения системы таких же как и основная.
zVlad
Уже с Приветом
Posts: 14939
Joined: 30 Apr 2003 16:43

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

Post by zVlad »

Dmitry67 wrote:Ну так в виртуалках у вас юникс, правильно?

Линукс на виртуалках созданных z/VM выполняется. А в z/OS есть Юникс и не на виртуалке а как неотемлимая часть ядра системы. MVS и Юникс в z/OS образуют одно целое и могут использоваться одновремено одной и той же программой. При этом программы могут запускатьися как MVS так и Юникс программы. E'to sovershenno ravnoznachno. Я могу, например, запистить ftp в TSO, или из Юникса. Работать будет одинаково.
StrangerR
Уже с Приветом
Posts: 37214
Joined: 14 Dec 2006 20:13
Location: USA

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

Post by StrangerR »

tengiz wrote:
Dmitry67 wrote:Ну вот Оракл по моему написан большими процессами с общей памятью.
Это уже давно не совсем так у Оракла.
Это до сих пор почти так. А начиналось с _только так_.

Для программы вообще почти без разницы. Для ОС - треды имеют меньше повторяющейся информации, и по сути это та же общая память но с разделением системной информации о процессах (все треды по сути - процессы, у которых однако общий контекст вроде доступа, внешних объектов, прав, ексепшенов, и вся память shared но стеки в разных местах).
StrangerR
Уже с Приветом
Posts: 37214
Joined: 14 Dec 2006 20:13
Location: USA

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

Post by StrangerR »

Dmitry67 wrote:Хотелось бы вернуться к нашим баранам. Как я говорил, в бэсм была очень неудобная работа со строками. А как в эльбрусе? Там ведь тоже только огромные слова адресуются вроде бы
А там же нет ассемблера а только языки уровня жавы и выше (по сути Эль 76 - смесь Алгола 68 и Ады). Плюс теги. Вполне там удобно все могло программироваться, как я понимаю.

Ссылку я вроде уже кидал, там и примеры есть

http://forum.oberoncore.ru/viewtopic.ph ... 3&start=60

Code: Select all

для i от 2 до n
   цикл
      ф64 x;
      x := a[0] := a[i];
      до найденменьшеx
         для j от i - 1 вниздо 0
         цикл
            если a[j] <= x то найденменьшеx!(j)
            иначе a[j+1] := a[j]
            всё
         повторить
      при
         найденменьшеx(k): a[k+1] := x
      всёсит
   повторить
StrangerR
Уже с Приветом
Posts: 37214
Joined: 14 Dec 2006 20:13
Location: USA

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

Post by StrangerR »

Medium-rare wrote:
StrangerR wrote: Да нет, тред легко заменяется процессами с общей памятью. По сути это почти одно и тоже, с некоторыми отличиями (у тредов общего больше чем просто общая память данных при самостоятельной памяти стеков).
Ежедневно мутя с потоками, такая радость, их заменить на процессы с общей памятью, не так просто приходит в голову. Лучше сразу убиццо апстену. Деформация такая. Тупеем потихоньку. :)
Чувствуется, что писалось сразу после _замутнения потоков_.

На самом деле если компилятор поддерживает, то разницы почти никакой. Вот для ОС разница есть, для процессов куда больше информации надо хранить. Но речь не про то, а про факт, что асинхронные обработки начинались с мульти-процессов с разделяемой памятью а потом плавно перетекли в треды.
StrangerR
Уже с Приветом
Posts: 37214
Joined: 14 Dec 2006 20:13
Location: USA

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

Post by StrangerR »

zVlad wrote:
Palych wrote:zVlad, по-моему Вы что-то путаете.
Threads работают без аппаратной поддержки где угодно.
Это всего лишь абстракция...
А почему же тогда в списке параметров неких процессоров приводится число этих самых threads?
Потому что это абсолютно независимые понятия. Тред на процессорах - означает что там можно создать несколько КОНТЕКСТОВ и процессор будет делать вид, что у него больше коров чем на самом деле. Экономия будет на переключении контекстов а возможно еще на том что какие то элементы процессора могут раздельно использоваться разными тредами.

Тред в процессе - как правило просто
- общая память (вся)
- стек в другом месте
- отдельный контекст для исполнения на процессоре

Никакой связи между тредами в корове и тредами в процессе нету, кроме некоторой схожести части понятий.
Переключение между "процессами" и "потоками" (или "нитями" или "легкими процессами") стоит примерно одинаково.
Это не так точнее совсем не так

Переключение процесса
- полностью поменять меппинг памяти (ну да, в новом часть может совпадать если там шеред сторейдж)
- поменять контекст прав доступа
- поменять контекст внешних объектов (fd и прочего)
- взять регистры и прочее для процесса включая положение стека
- запуститься

Переключение треда
- взять регистры для процесса, выставить новое положение стека
- запуститься

Намного меньше так как не меняется меппинг памяти, права и внешние объекты.
zVlad
Уже с Приветом
Posts: 14939
Joined: 30 Apr 2003 16:43

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

Post by zVlad »

StrangerR wrote:
zVlad wrote:....
А почему же тогда в списке параметров неких процессоров приводится число этих самых threads?
Потому что это абсолютно независимые понятия. Тред на процессорах - означает что там можно создать несколько КОНТЕКСТОВ и процессор будет делать вид, что у него больше коров чем на самом деле. Экономия будет на переключении контекстов а возможно еще на том что какие то элементы процессора могут раздельно использоваться разными тредами.
....
Никакой связи между тредами в корове и тредами в процессе нету, кроме некоторой схожести части понятий.
Спасибо. Я тоже склонялся к токому же обьяснению. Теперь все вроде сходится - просто использовали одно слово в разных фирмах вложив в него разный смысл. А интерeсно все таки - ОС в курсе threads процессора или это ей не доступно знать и использовать? Логично было бы предположить что это недоступно ОС хотя ....
User avatar
Dmitry67
Уже с Приветом
Posts: 28233
Joined: 29 Aug 2000 09:01
Location: SPB --> Gloucester, MA, US --> SPB --> Paris

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

Post by Dmitry67 »

Ну так понятно что на языке пишется a = b[j];

Но если для каждого a i делится на число символов в слове, читается слово, нужный байт побитно сдвигатся и выделяется, а при записи еще сложнее, то вы представляете какой overhead?
Зарегистрированный нацпредатель, удостоверение N 19719876044787 от 22.09.2014
User avatar
Vladimir1440
Уже с Приветом
Posts: 2085
Joined: 14 Sep 2013 13:07

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

Post by Vladimir1440 »

StrangerR wrote:Переключение треда
- взять регистры для процесса, выставить новое положение стека
- запуститься

Намного меньше так как не меняется меппинг памяти, права и внешние объекты.
Там основной выигрыш через "memory bank interleaving": если у вас - несколько "банков памяти".

Процессор-то имеет тактовую частоту сколько-то гигагерц, а память - сколько-то сотен мегагерц. Процессор просто "ждёт" память на каждой команде.

Если память нарезана на bank0, bank1, и так далeе (физически - каждый банк под своим независимым управлением мемори-контроллера), то разные банки работают одновременно. Шина адреса и шина данныx - одна, но память с ней работает "чаще" потому, что "все служебное" - мемори-контроллер делает "в фоновом режиме" как бы (пока процессор читает/пишет в другой банк памяти). Есть проверенная но сплетня что разным тредам - операционка старается нарезать разные банки (ей-то не все равно, какую "физически" память отдать), именно чтобы быстрее работало.

Поэтому кстaти мульти-процессорные машины (два-четыре процессорa) "быстрее" при том же числe "коре" и той же "тактовой частотe". У каждого из процессоров тогда впридачу "свои" шины адреса и данныx (к "своим" банкам - физически расположенным рядом с каждым из процессоров), т.е. не только интерливинг работает но и параллельный дoступ к разным адресам памяти (разными процессорами), впридачу.
Last edited by Vladimir1440 on 12 Oct 2014 19:50, edited 2 times in total.
User avatar
Vladimir1440
Уже с Приветом
Posts: 2085
Joined: 14 Sep 2013 13:07

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

Post by Vladimir1440 »

zVlad wrote: А интерeсно все таки - ОС в курсе threads процессора или это ей не доступно знать и использовать? Логично было бы предположить что это недоступно ОС хотя ....
Видит операционка иx ("это - доступно ОС"). Посмотрите "перформанс монитор" в Виндоус xоть. Если тредов больше чем коре - она за каждым "следит" по отдельности (каждый "тред" для Виндоус - логический процессор, "внешне не отличимый" от физического коре - который тоже логический процессор если число тредов равно числу коре).

Вот, аттачнул: коре - два, а тредов - четыре (разрешен мульти-трединг или нет, если они реализованы на процессоре - это просто сеттинг в CMOS).

PS Есть разница ("ОС в курсе threads процессора или это ей не доступно"), если у вас ОС - это гипервизор, и куча виртуалок. ИМXО конечно, но очень часто разным виртуалкам "нарезается данное число коре", а вот нарезать виртуалке "конкретный тред" - нельзя (можно только указать "до сколькиx процентов ютилизейшн она может загружать коре"). Извиняюсь, с 48-корными 96-тредными монстрами на которыx виртуалок по 30 дела не имел, а на всеx "мелкиx" - так (так - "просто проще всё сделать", может, на могучиx - и иначе режут ресурсы, а на мелкиx - "просто незачем").
You do not have the required permissions to view the files attached to this post.
Last edited by Vladimir1440 on 12 Oct 2014 18:57, edited 2 times in total.
User avatar
tengiz
Уже с Приветом
Posts: 4468
Joined: 21 Sep 2000 09:01
Location: Sammamish, WA

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

Post by tengiz »

StrangerR wrote:
Переключение между "процессами" и "потоками" (или "нитями" или "легкими процессами") стоит примерно одинаково.
Это не так точнее совсем не так

Переключение процесса
- полностью поменять меппинг памяти (ну да, в новом часть может совпадать если там шеред сторейдж)
- поменять контекст прав доступа
- поменять контекст внешних объектов (fd и прочего)
- взять регистры и прочее для процесса включая положение стека
- запуститься

Переключение треда
- взять регистры для процесса, выставить новое положение стека
- запуститься

Намного меньше так как не меняется меппинг памяти, права и внешние объекты.
Я полагаю, Ваши сведения устарели для популярных цпу и ОС. На современных процессорах "mapping памяти" переключается тривиально (загрузка нескольких регистров, самое дорогое при этом - некоторые внутренние процессорные кеши обнуляются, но на "совсем современных" процессорах даже это уже незаметно), права доступа у тредов даже в одном процессе бывают разные, кроме того, эти самые права и контексты внешних объектов в современных популярных ОС - это всего лишь данные в памяти - при переключении маппинга памяти автоматически все переключается.

В итоге, заметить разницу между переключением процесса и переключением потока очень сложно. А в некоторых операционных системах, например Windows, планировщик вообще не делает (и никогда не делал разницы - для всех версий NT, аж с 1991 года) разницы между процессами или потоками так как "видит" только "потоки", более того, "процесс" в обязательном порядке имеет хотя бы один "поток", иначе он просто не будет выполняться.

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

А вот где начинается существенная разница - это при использовании "user mode threads" или как оно там называется для разных ОС.
Cheers
User avatar
tengiz
Уже с Приветом
Posts: 4468
Joined: 21 Sep 2000 09:01
Location: Sammamish, WA

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

Post by tengiz »

StrangerR wrote:
tengiz wrote:Это уже давно не совсем так у Оракла.
Это до сих пор почти так. А начиналось с _только так_.
Конечно, когда в те времена, когда Оракл работала на всем, кроме кирогаза (десятки прогаммно-аппаратных платформ) было не до изысков. А вот когда его портировали на Wintel, удобство многопотоковой архитектуры тут же оказалось к месту. Поэтому как минимум на Wintel Оракл - многопотоковый, хотя и большие куски изначальной архитектуры с несколькими процессами разного назначения до сих пор имеются, хотя за что у них там в самых последних версиях я уже не в курсе.
Cheers
iDesperado
Уже с Приветом
Posts: 1304
Joined: 28 Nov 2008 17:50

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

Post by iDesperado »

tengiz wrote:Конечно, когда в те времена, когда Оракл работала на всем, кроме кирогаза (десятки прогаммно-аппаратных платформ) было не до изысков. А вот когда его портировали на Wintel, удобство многопотоковой архитектуры тут же оказалось к месту. Поэтому как минимум на Wintel Оракл - многопотоковый, хотя и большие куски изначальной архитектуры с несколькими процессами разного назначения до сих пор имеются, хотя за что у них там в самых последних версиях я уже не в курсе.
ерунду рассказываете. когда портировали на винду выяснилось, что у винды переключение процессов работает чудовищно медленно, пришлось переделывать на тхреды, что бы хоть как-то конкурировать с другими. под линуксом и соляркой на интеле оставили процессы. только сейчас, в дань моде, в версии 12с сделали параметер threaded_execution, который переключает на тхреды на unix/linux платформах, но кроме неудобства никто разницы не видит.
User avatar
tengiz
Уже с Приветом
Posts: 4468
Joined: 21 Sep 2000 09:01
Location: Sammamish, WA

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

Post by tengiz »

iDesperado wrote:ерунду рассказываете. когда портировали на винду выяснилось, что у винды переключение процессов работает чудовищно медленно, пришлось переделывать на тхреды, что бы хоть как-то конкурировать с другими. под линуксом и соляркой на интеле оставили процессы. только сейчас, в дань моде, в версии 12с сделали параметер threaded_execution, который переключает на тхреды на unix/linux платформах, но кроме неудобства никто разницы не видит.
Вы что-то путаете. Нет никакой заметной разницы при переключении потоков или процессов на Wintel и никогда не было.
Cheers
User avatar
Vladimir1440
Уже с Приветом
Posts: 2085
Joined: 14 Sep 2013 13:07

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

Post by Vladimir1440 »

tengiz wrote:
iDesperado wrote:ерунду рассказываете. когда портировали на винду выяснилось, что у винды переключение процессов работает чудовищно медленно, пришлось переделывать на тхреды, что бы хоть как-то конкурировать с другими. под линуксом и соляркой на интеле оставили процессы. только сейчас, в дань моде, в версии 12с сделали параметер threaded_execution, который переключает на тхреды на unix/linux платформах, но кроме неудобства никто разницы не видит.
Вы что-то путаете. Нет никакой заметной разницы при переключении потоков или процессов на Wintel и никогда не было.
Во всяком случае какая-то зависимость от ОС - точно есть. У меня в CMOS-сеттингаx на Dell Dimension 3100 например написано: "если энейблнуть треды т.е. дать возможность операционке видеть больше логическиx процессоров - для некоторыx ОС может улучшиться перформанс". Раз "сделали регулируемым" - значит, от операционки - зависит (на заводе же "не знают, какую ОС юзер поставит на иx железо"). Логично? Скриншот сделать не могу: в BIOS же Принт-скрин, ессно, не работает.

На воркстейшнаx - одно могу сказать точно: если это энейблнуто - энергопотребление заметно растёт (просто если воркстейшн - лаптоп, то батарея - заметно раньше садится). Но для воркстейшна же как правило баттленеки - это диск и нетворк (если воркстейшн "домашняя" - то баттленек это вообще Интернет-провайдер), так что сильно (кроме энергопотребвления) - не заметно. На сервераx - по всякому (бывает, заказчик требует чтобы "все треды - были энейблнуты" - нo он же лучше меня гораздо знает потребности софта котором он грузит свой сервер).

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