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

[iDesperado]

Вы что-то путаете. Нет никакой заметной разницы при переключении потоков или процессов на Wintel и никогда не было.

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

[tengiz]

только сейчас, в дань моде, в версии 12с сделали параметер threaded_execution, который переключает на тхреды на unix/linux платформах, но кроме неудобства никто разницы не видит.

Думаю, Вы опять что-то путаете. Без переключения на потоки невозможно эффективно/удобно использовать epoll vs select/poll или как оно там в posix называется.

[Vladimir1440]

Что таким могучим БД нужно (в которыx куча тред по 4 ГБ памяти каждая ) - честно говоря не знаю: не мой масштаб.

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

...Up to a total of 40 processor cores with 80 threads (Intel® Hyper-Threading Technology) guarantee highest rendering performance (48 cores/96 threads with optional 12-Core CPUs)...

http://xi-machines.com/en/systems-render.php

[tengiz]

Вы что-то путаете. Нет никакой заметной разницы при переключении потоков или процессов на Wintel и никогда не было.

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

Причина была не в том, что процессы переключались якобы медленнее. А, например, упомянутый уже epoll или IO Completion Port в Wintel.

[iDesperado]

Думаю, Вы опять что-то путаете. Без переключения на потоки невозможно эффективно/удобно использовать epoll vs select/poll или как оно там в posix называется.

да кого это интересует на фоне 4гб на процесс ?

Vladimir1440
научитесь уже отличать тхреды ОС от гипертрединга процессора.

[tengiz]

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

Вы говорите о другом. Hyperthreading и os threads - совершенно разные вещи. Какой-то умник в Интел не подумал и создал ненужную путаницу с терминами. Зависит не столько от операционки, сколько от характерной нагрузки. В одних случаях есть явный выигрыш, в других - наоборот.

[tengiz]

Думаю, Вы опять что-то путаете. Без переключения на потоки невозможно эффективно/удобно использовать epoll vs select/poll или как оно там в posix называется.

да кого это интересует на фоне 4гб на процесс ?

Вы думаете кого-то интересует переходный период когда 32 бит стали начинать выдыхаться, а 64 бит были еще дороговаты/сыроваты? Это положение продлилось совсем недолго, с появлением amd64 все резко изменилось, для тех, кому нужны были 4гб+ проблемы уже не было. Возвращаясь к скорости переключения - никакой практической разницы нет. Почему орал выбрал потоки, могу только предполагать. А также для интереса могу спросить коллег, которые делали оракл. А я делал "майкрософтовскую базу", поэтому в чем было дело знаю сам.

[Vladimir1440]

Вы говорите о другом.

Угу.

Hyperthreading и os threads - совершенно разные вещи. Какой-то умник в Интел не подумал и создал ненужную путаницу с терминами. Зависит не столько от операционки, сколько от характерной нагрузки. В одних случаях есть явный выигрыш, в других - наоборот.

Ну вот. Не зря сегодня сюда зашёл. А путаница - действительно сильна: в свете этой ветки ("тут, на привете") вот такoе читаeтся теперь совершенно иначе (раньше - всё в подобныx текстаx было просто и понятно, блин):

...On a multiprocessor or multi-core system, threads can be truly concurrent, with every processor or core executing a separate thread simultaneously. The operating system uses hardware threads to implement multi processing...

Т.е. ОС может оказывается и использовать "хардваре тредс" процессорa, и иметь свои "софтваре тредс" (которые же тоже - "ОС тредс", блин).

[iDesperado]

Вы думаете кого-то интересует переходный период когда 32 бит стали начинать выдыхаться, а 64 бит были еще дороговаты/сыроваты?

издеваетесь ? вы совсем не представляете когда был windows NT и когда переход на x64 ? решение по ораклу на тхредах и x64 почти десятилетие разделяет.

[Сабина]

Вы думаете кого-то интересует переходный период когда 32 бит стали начинать выдыхаться, а 64 бит были еще дороговаты/сыроваты?

издеваетесь ? вы совсем не представляете когда был windows NT и когда переход на x64 ? решение по ораклу на тхредах и x64 почти десятилетие разделяет.

Попробую продемонстрировать знание истории . На MCSE по NT сдавала в 2000, на 64 бит помню переходили где то в 2009 на работе

[tengiz]

Вы думаете кого-то интересует переходный период когда 32 бит стали начинать выдыхаться, а 64 бит были еще дороговаты/сыроваты?

издеваетесь ? вы совсем не представляете когда был windows NT и когда переход на x64 ? решение по ораклу на тхредах и x64 почти десятилетие разделяет.

Напоминаю, что проблема, которую вы пытаетесь объяснить, это нехватка виртуального адресного пространства для адресации физического, т.е. когда физический памяти в системе заметно больше, чем предел VAS. Эта ситуация в мире PC продолжалась недолго и значительную часть времени между появлением NT до начала перехода на 64 бита такой проблемы не было. Причина по которой переход на NT без перехода на потоки часто приводил к замедлению - совсем не в скорости переключения, а в скорости запуска процесса в сравнении с запуском потока. Мы это уже здесь на привете обсудили лет 10 назад. Но, повторюсь, это не имеет отношения к переключения контекста.

[StrangerR]

ерунду рассказываете. когда портировали на винду выяснилось, что у винды переключение процессов работает чудовищно медленно, пришлось переделывать на тхреды, что бы хоть как-то конкурировать с другими. под линуксом и соляркой на интеле оставили процессы. только сейчас, в дань моде, в версии 12с сделали параметер threaded_execution, который переключает на тхреды на unix/linux платформах, но кроме неудобства никто разницы не видит.

Вы что-то путаете. Нет никакой заметной разницы при переключении потоков или процессов на Wintel и никогда не было.

Была всю жизнь. Я могу подтвердить что на Винде оракл ПЕРЕДЕЛЫВАЛИ на Треды именно из за невозможности там сделать по человечески на процессах. На других платформах все работает на процессах с общей памятью (все буфера и кэши в общей памяти но процессы независимые, по крайней мере в 10 и кажется в 11 версиях точно).

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

Реально 64 бита в виндах стало нормально работать в Windows7 и в Win2K3, не раньше. Много где до сих пор не перешли.

[iDesperado]

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

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

[tengiz]

Вы что-то путаете. Нет никакой заметной разницы при переключении потоков или процессов на Wintel и никогда не было.

Была всю жизнь. Я могу подтвердить что на Винде оракл ПЕРЕДЕЛЫВАЛИ на Треды именно из за невозможности там сделать по человечески на процессах. На других платформах все работает на процессах с общей памятью (все буфера и кэши в общей памяти но процессы независимые, по крайней мере в 10 и кажется в 11 версиях точно).

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

Реально 64 бита в виндах стало нормально работать в Windows7 и в Win2K3, не раньше. Много где до сих пор не перешли.

На Windows есть большая разница по времени для запуска процесса или запуска потока. Если приложение написано так, что при подключении нового пользователя нужно запускать процесс, тогда кранты, нужно переписывать на потоки, но не потому, что потоки переключатся быстрее если они в одном процессе. На потоках даже до наступления 64 битной эры все прекрасно работало когда машины использовались адекватно и приложения были написаны с расчетом на максимальную производительность. По производительности на одной и той же более-менее mainstream аппаратуре комбинации Windows/SQL Server когда речь шла о стандартных бенчмарках обычно не было равных. Где было видно отставание Windows, это когда Wintel брал очередную для себя вершину - например переход от архитектур с макс 4 процессорами на макс 32 процессора или, скажем, при переходе на NUMA и нужно было оптимизировать ядро ОС под "новые реалии", что на самом деле происходило довольно быстро, пока платформа не брала очередную высоту. Так как Wintel вгрызался в рынок снизу, соответственно в хайер-енде всегда было отставание, которое наверстывалось по мере приобретения практического опыта.

Итого: время переключения между потоками одного процесса или разных процессов отличается на практически незначимую величину сколько бы раз здесь не повторялось обратное. Если у Вас имеется информация, которую можно проверить, пожалуйста приведите. Будет интересно почитать или попробовать воспроизвести. Иначе я предлагаю просто зря здесь не тратить время на переливание из пустого в порожнее.

[tengiz]

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

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

Одно из самых успешных серверных приложений на Wintel - SQL Server прекрасно работало с рекордной производительностью на 32 битах и очень гладко перешло на 64 бита у тех, кто хотел. Посмотрите историю бенчмарков того времени.

[iDesperado]

Одно из самых успешных серверных приложений на Wintel - SQL Server прекрасно работало с рекордной производительностью на 32 битах и очень гладко перешло на 64 бита у тех, кто хотел. Посмотрите историю бенчмарков того времени.

вы наслушались маркетиного булшита от майкрософт, это единственно в чем был в тот момент действительно силен. реально же линукс уже в 2001 году имел x64, оракл где-то c 2003. майкрософт же в это время в муках рожало sql 2005, раза 4 перенося сроки, примерно в тот же момент устроив конец света с "прекрасно работавшим" сламмером, крупнейшей вирусной эпидемией на планете. sql 2005 с x64 вышел спустя многие годы, относительно x64 оракла. все то время сливал безбожно, в первую очередь из-за 32-бит.

[Dmitry67]

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

Думаю оппонет страдал именно от означенной проблемы
"worker threads" даже SQL старается иметь заранее в запасе
Так что "worker process" тем более надо стартовать заранее, а не при логине

[tengiz]

вы наслушались маркетиного булшита от майкрософт.

[Medium-rare]

Word of wisdom.

[StrangerR]

Одно из самых успешных серверных приложений на Wintel - SQL Server прекрасно работало с рекордной производительностью на 32 битах и очень гладко перешло на 64 бита у тех, кто хотел. Посмотрите историю бенчмарков того времени.

вы наслушались маркетиного булшита от майкрософт, это единственно в чем был в тот момент действительно силен. реально же линукс уже в 2001 году имел x64, оракл где-то c 2003. майкрософт же в это время в муках рожало sql 2005, раза 4 перенося сроки, примерно в тот же момент устроив конец света с "прекрасно работавшим" сламмером, крупнейшей вирусной эпидемией на планете. sql 2005 с x64 вышел спустя многие годы, относительно x64 оракла. все то время сливал безбожно, в первую очередь из-за 32-бит.

ДА, кстати, по масштабам той вирусной инфекции равных я не припомню.

И да, если мы с самого начала, как стали доступными серверы, все линуксы делали 64 битными, то опыты с 64 битными виндами кончались настолько хреново, что еще лет 6 их не использовали, кроме редких случаев (правда, MS SQL 2005 один из них).

Но - где те винтелы и где тема топика? Куда это нас всех занесло? Эльбрус был изначально 64 битным, еще в 70-х. Правда, какая там была адресация я не помню, но учитывая теговость во все стороны, там ограничений по адресуемой памяти могло бы и не быть.

[Мальчик-Одуванчик]

А кто расскажет от себя про Эльбрус? Вики читал, интересна отсебятина )

У него была кликуха Эль-Барроуз.
Сам не работал, так как успел попасть под обаяние CM-1420
Однокурсникам довелось - по их рассказам, если эта хрень работала хотя-бы десять минут без кирдыка, то это было супер.
А так, железяку всё время чинили.

[tengiz]

ДА, кстати, по масштабам той вирусной инфекции равных я не припомню.

Да, за это до сих бывает стыдно, "штаб по искоренению" работал на износ несколько дней. Это было досадно еще и потому, что проблема была во второстепенной компоненте, не имеющей прямого отношения к собственно движку. Люди ответственные за ситуацию (смехотворную, на самом деле, им в этой второстепенной компоненте всего лишь нужно было обращать внимание на предупреждения компилятора и для начала взять за правило считать любые предупреждения ошибками - как в движке) чуть погодя, все таки ушли. Хотя на степень проникновения на рынок это как бы и не повлияло. Примерно в то время MS SQL стал безусловным первым по числу лицензий среди платных.

Но действительно, где БЭСМ против ИБМ и где MS SQL.

[zVlad]

ДА, кстати, по масштабам той вирусной инфекции равных я не припомню.

Да, за это до сих бывает стыдно, "штаб по искоренению" работал на износ несколько дней. Это было досадно еще и потому, что проблема была во второстепенной компоненте, не имеющей прямого отношения к собственно движку. Люди ответственные за ситуацию (смехотворную, на самом деле, им в этой второстепенной компоненте всего лишь нужно было обращать внимание на предупреждения компилятора и для начала взять за правило считать любые предупреждения ошибками - как в движке) чуть погодя, все таки ушли. Хотя на степень проникновения на рынок это как бы и не повлияло. Примерно в то время MS SQL стал безусловным первым по числу лицензий среди платных.

Но действительно, где БЭСМ против ИБМ и где MS SQL.

Кстати БЭСМ 6 предшествовали 1, 2, 3 и т. д. а им предшествовала МЭСМ. И вот это гораздо интереснее чем сравнение двух скопированных с американских машин. И было еще такое имя Глушков Виктор Михайлович и была машина Мир-1, фактически первый ПК в 1966 году. Вот та линия и была отечественной, которую бы и следовало сохранять и развивать.

[zVlad]

Эльбрус был изначально 64 битным, еще в 70-х. Правда, какая там была адресация я не помню, но учитывая теговость во все стороны, там ограничений по адресуемой памяти могло бы и не быть.

Речь то идет именно об 64 битной адресации, а Вы говорите о размере слова. В Эльбрусе были также полуслова и слова двойной точности - 128 бит, а вот адрес был 24 битовый У Эльбрус 2, т.е. такой же как и у IBM S/360 (1964 год выпуска) в то время как IBM S/370 имела 31 битовый адрес и была аннонсирована в 1972-ом году.
Что еще интересно так это то, что БЭСМ изначально имел трёхадресный формат команд, а БЭСМ 6 одноадресный. IBM S/360 имел команды разных форматов и разных размеров соответственно.

[Dmitry67]

Где это одноадресный? Все бэсм имели трехадресный, начиная с предка бэсм, машины "стрела"

Что касается истории развития, то предком бэсм 6 является бэсм 4. До нее, игнорируя редкие 3 и переходные модели идут ламповые м220, а до нее м20. Наконец, самой ранней является Стрела, интересная тем что имела память на лучевых трубках. Но.структура команд у нее такая же