IT в России и мире в реалиях мирового кризиса
1,404,898 8,482
 

  AndreyK-AV ( Слушатель )
01 фев 2010 17:47:12

Тред №185817

новая дискуссия Дискуссия  354

Цитата: Сидоров
Когда у заказчика денег нет - это очень хорошо - Заказчик не покупает "линии под ключ" от Сименса.



Эх нифига Вы не поняли.
И ПМСМ Вы сейчас только заняты продвижением как образа жизни долины, так и продуктов от MS.
Так бы сразу и сказали что специалист по ПИАРу и маркетингу, а то хайтек, технологии.Грустный
И подход раз надцать, только Вы с упорством истиного обмикрософченого все продаете нам и продаете.

Я Вам раз надцать уже написал что сейчас моя сфера деятельности чуток пониже в этой пирамиде, чем приведеные Вами названия. Да MS использую, там где удобней, это так к слову.

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

Цитата: Сидоров
И не тратит дурных денег на боготворимые товарищем Андреем Ораклы и SAP. Потому что под тот же Microsoft Dynamics в России есть очень приличные коллективы, стоит это на порядки дешевле, делается быстрее, да и куча денег остается в России у подрядчика.


А вот это говорит, что Вы вообще нифига в проблеме не понимаете. Саму суть проблему управления ресурсами, сводите к тупому пилению бабла, короче "пилите Шура, пилите.."(с)
Отредактировано: AndreyK - 01 фев 2010 17:54:34
  • +0.17 / 2
  • АУ
ОТВЕТЫ (18)
 
 
  Сидоров 2-й ( Слушатель )
02 фев 2010 18:01:13


Дорогой Андрей, после Ваших заявлений про то, что по интеллектуальному наполнению ОС - дерьмо, а SAP - наше все, мне без смехуечков на эти темы не пишется...Подмигивающий

Что до Долины и ПЕАРА - Майкрософт платит налоги в Сиэтле, а Сан, Оракл и Гугл - в Долине. Я же озвучиваю свое собственное мнение человека с 15 годами опыта деятельности в Долине - консалгинга от Firmware и до самых до Зияющих Вершин. И моих заказчиков на мякине не проведешь - не тот уровень владения сущностями.

Кстати, сейчас в Долине 90% открытых контрактов - всевозможные джавы-линуксы. И не потому, что Майкрософта мало - Майкрософта в разы больше, только для Майкрософта человеко-часов нужно в разы меньше. Умный человек над этим задумывается, иные гонят лабуду про Wintel. С пинка-подачи отделов маркетинга Клуба Больших Лузеров типа IBM с Саном.

Но это все лирика, внимать не неволю.

Применительно к решениям для производства "под ключ" от Сименса (штатовский аналог - General Electric) - они "золотые" часто даже для Америки, ибо обе компании отбивают инвестмент, пущенный давным-давно на автоматику для АЭС. А решения для производства требуют еще кучи дополнительных работ по интеграции оборудования, желательно силами местных ребят, и требующих как бы не больших финансов. Но ребята, принимающие решения про "под ключ", либо об этом как-то забывают, либо приглашают варягов - как Вы приводили пример с Вашим выписанным из Оракла спецом. Между тем, коли Вы работаете в нефтянке, то точно знаете, что починку трубы на трассе лучше сделает местная ремонтная бригала, чем выписанный из главка бумажный червь.

А для АЭС у России есть свой аналог Сименса или GE - Атоммаш. И чем киндерсюрпризу сопли жевать над инвестпрограмми - проще просто освоить проектирование и выпуск средств автоматики для конкретной отрасли.

То же и с SAP. Вот у меня есть такой мужик из местной ремонтной бригады, лет 10 (в Долине) сидящий и на Оракле, и на MS SQL, и на SAP, и на Dynamics. Когда мне чего-нибудь серьезное нужно в базах - задействую его, делает идеально. Это его слова как-то я озвучил - "Внедрение SAP - это не процесс, это состояние; компания бывает в трех состояниях - до SAP, в процессе ее внедрения и мертвой" - он ни разу за свои 10 лет опыта в Долине при общих 25-ти не видел окончания этого процесса.

И я знаю чем "проблема управления ресурсами" отличается от пиления бабла - поэтому и решаюсь что-то советовать - Что для России, а что - для попила. И даже утверждаю - есть уже в России опыт создания коллективов, решающих такие проблемы.

ПС. Касаемо "образа жизни" Долины. Вы бы лучше не "образ жизни" в моих постах искали, а отличия Долины от российских бутафорий-технопарков - я ведь даже даю примеры и какие-то объяснения, отчего это даже в Штатах больше нигде не работает.

Может, лучше вообще не обезьянничать с технопарками, коль скоро Вам "образ жизни" не по душе? ???
  • +0.01 / 4
  • АУ
 
 
  AndreyK-AV ( Слушатель )
02 фев 2010 18:42:29
Дорогой Сидоров, Ваш пост слишком разномастный чтоб так ответить, "смешались в кучу кони люди".
Начнем с середины. Какое к черту супер интеллектуальное наполнение у ОС? Что интеллектуального в иконках и форточках и чем они интеллектуальней того же МАСа? А намного интеллектуальней, чем в свое время RSX, OS/2 или VAX/VMS.
Любая ОС это не конечный инструмент, а скорее платформа под инструменты. А инструменты они разные.
Вы наезжаете на СУБД Oracle, а Вы не сталкивались с ситуацией, когда MS SQL просто висло, а Oracle пахало? Я это видел и часто, но однако MS SQL не посылаю, у нее достоинств хватает, только это малость другой инструмент.
Про САП разговор вообще отдельный, и он не про САП а про АСУП Понимаете каждый инструмент служит для решения своих задач, так вот инструменты класса САП или БААН или Галактика и т.д., они имеют уже внутреннее наполнение технологиями и бизнес-процессами кучи производств, и в этом их ценность и недостаток. Ценность в том, что есть схема решения большинства проблем, недостаток в сложности настроек и крайней дороговизне как обратной стороне этих достоинств.  Только поймите наполнением не гаджектами, а отлаженными бизнес-процессами.
Вы сами вынудили на пример: когда разговор зашел об тестировании разузлования xnj САП xnj БААНОМ просто начали обсуждать как это лучше показать, а Микрософт начал задавать вопросы что это такое и с чем его едят. Вот где разница.
И если для небольших и средних фирм чаще нужен Микрософт или 1С, то для крупных картина скорее обратная, наоборот. Кстати этих наоборот достаточно много, а не только те что здесь перечисляются.

По решениям под ключ, тоже нет однозначности. Про атомную отрасль идите на соответствующую ветку, там Вас с вашим  штатовским Вестингаузен Добряк быстро в чувство приведет.
А я, больше вижу соревнование Сименса с Роквелом или Иокогавой, и чаще всего там где поделки наколенные дают быстрый эффект, но долгосрочный убыток. Я не против местных решений, и сейчас именно этим занимаюсь, но не везде это лучше. Поверить не прошу, хотя опыт имею тоже немаленький, но "лучше отвечать за свои ошибки, чем за чужие советы".
  • +0.00 / 0
  • АУ
 
 
 
  Сидоров 2-й ( Слушатель )
05 фев 2010 12:37:19

Уважаемы Андрей, давайте мы прекратим обсуждение ОС в терминах "иконок" и "форточек" - я профессионал, а не впариватель маркетолог, а Вы, судя по выраженному мнению - всего-навсего представитель окучиваемой паствы.

ПС. Минусующих знатоков ядер ОС - милости просим к обсуждению.Подмигивающий
  • -0.24 / 3
  • АУ
 
 
 
  Сидоров 2-й ( Слушатель )
05 фев 2010 13:12:59

Я не наезжаю на Оракл. Я формулирую различия между Порше и Тойотой, особенно важные в условиях российского бездорожья. Даже безотносительно к тому, что Порше, как и Оракл сливают, а MS и Тойота - растут.

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

Про "висло-не висло" - это лирика. Разумные люди приводят конкретную информацию на предмет "что, где, когда и сколько".
  • -0.16 / 2
  • АУ
 
 
 
  Сидоров 2-й ( Слушатель )
05 фев 2010 13:22:09


Про SAP у людей знающих (свидомых, хе-хеВеселый) мнение одно - это куча дерьма, живущая сама по себе и не поддающаяся ни анализу, ни рефакторингу, ни даже адекватному тестированию. 99% которой составляют многочисленные перемычки от OS/370 до наших дней. Существует также многчисленный слой Оракулов, способных догадаться, как оно себя поведет в некотрых, уже случавшихся в ее истории стечениях обстоятельств. Есть еще куча лохов, финансирующих этих оракулов.
  • -0.09 / 1
  • АУ
 
 
 
  Сидоров 2-й ( Слушатель )
05 фев 2010 13:38:42

Под решениями "под ключ" я понимаю разводку лохов, когда толстый дядя притащит и впарит кучу всяких-разных Филдбасов с Профибасами под всеобщий "одобрямс" туземцев.

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

Я не знаю, что Вы там себе видите (и крайне удивлен поминанем Алан-Бредли для русских просторов). PLC вообще позавчерашний день и используются по историческим причинам там, где долго до того использовались. Если говорить серьезно про Factory Floor и частично MES, то существуют только два заслуживающих внимания интегратора - Wonderware и GE Fanuc (в девичестве Intellution). И оба основаны людьми, принимавшими самое деятельное участие в создании стандарта OPC (основанного на столь нелюбимых Вами MS технологиях). Все Вами перечисленные - вынуждены создавать переходники (OPC-сервера), чтобы хоть как-то успеть за стандартами.
  • -0.08 / 1
  • АУ
 
 
  mrt789 ( Слушатель )
02 фев 2010 19:49:47


Ниче, ща мы переведем разговор в практическую плоскость (надо же и мне в минуса уходить  :D ). Я тут несколько страницы назад упоминал Сингулярити... и упомянул я ее не для красного словца.

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

Почему так получилось, очень хорошо написано в этом стааааром топике:

http://www.rsdn.ru/f…px#2688246

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

Выход: создать ОС с отличным от мейнстримовского методом взаимодействия между потоками.

Не скажу что в Сингуларити есть какой-то прорыв - асинхронный обмен сообщениями существовал с лохматых годов. В качестве современного рабочего решения целиком построенного на таком взаимодействии можно привести тот же Erlang. В чем тогда новизна Сингулярити? А в том, что именно современная попытка оформить такую штуку в виде ОС, то есть реализовать в данной парадигме не просто платформу для прикладного ПО, но сами внутренние механизмы ОС и сделать это на современной программной платформе (.NET).

Среднестатистическая домохозяйка об этих проблемах разумеется не знает, но они уже начинают довольно широко обсуждаться, примером тому может стать вновь поднимающаяся волна интереса к функциональным и гибридным языкам (например, Scala - императивно-функциональный, с акторами в стандартной библиотеке - "Превед, Erlang!!"). Тот же Haskell вроде может распараллеливать задачи, но увы не все: в реальном мире главная священная корова ФП (детерменированная функция без побочных эффектов) мало применима. Хотя для сферических коней в вакууме в ФП есть ооочень интересные вещи, например, "мемоизация" (по сути, кеширование результатов функции) и пр. Однако же сингулярити используются не вся эта экзотика, а специально созданный Sing#:

http://ru.wikipedia.org/wiki/Sing_Sharp

Фишки которые дает такой подход огромны: начиная от того что каждый такой "нод" (в терминах Erlang'а) может обрабатываться как произвольным количеством ядер (при условии независимости сообщений в потоке), так и вообще располагаться на другом конце света, причем транспорт может быть любым - хоть асинхронный вызов веб-сервиса, и здравствуй SOA на уровне ОС.

Причем, что самое интересное, в готовом к употреблению виде такие системы появятся лет через 5-10 (возможно как костыль к существующим - бабло-то заколачивать надо!). Сейчас ИХ НЕТ!! Это я к тому, что наш уважаемый модератор тут утверждал, что нужно сосредотачиваться на незанятых направлениях - вот оно;)

Вот это все для меня является хайтеком: ОС - хайтек, виртуальная машина - хайтек, ЯП общего назначения получивший признание во всем мире - хайтек, новый способ взаимодействия - хайтек. Так же как хайтеком является и самолетостроение и космос и микроэлектронника, биотех и пр.

А жопогрейка - это всего лишь продукт, который вся эта пирамида производит (от микроэлектронники до ОС и прикладного софта). Без жопогрейки человек разумеется не умрет с голода, но если мы хотим чтобы соответствующие отрасли развивались - их нужно обеспечить массовым спросом, по другому просто не получится (или получится как в Союзе).
  • +0.37 / 5
  • АУ
 
 
 
  zh17. ( Слушатель )
05 фев 2010 06:29:45


                 
Architecture
Count
Share %
Rmax Sum (GF)
Rpeak Sum (GF)
Processor Sum
Constellations
2
0.40 %
94970
112947
17648
MPP
 81
 16.20 %
 10939467
 13614091
 2090251
Cluster
 417
 83.40 %
 16943065
 27223084
 2556728
Totals
 500
 100%
 27977501.79
 40950122.01
 4664627

MPP (многопроцессорные) - 16.20%, Cluster (кластерные) - 83.40%  :D источник
Разницу между многоядерными и многопроцессорными архитектурами Вам объяснят на 3 курсе. Если кратко, узкое место - шина до памяти. Для эффективного использования ядер, надо всё держать в кеше. Хорошо параллелится на многоядерности обработка звука, графики, объёмного моделирования и т.д. То есть то, что затащил в кеш и считай, считай, считай...




           
         
Operating system Family
Count
Share %
Rmax Sum (GF)
Rpeak Sum (GF)
Processor Sum
Linux
446
89.20 %
22521676
34255641
3253501
Windows
 5
 1.00 %
 412590
 509350
 59072
Unix
 25
 5.00 %
 1509809
 1925284
 124274
BSD Based
 1
 0.20 %
 122400
 131072
 1280
Mixed
 23
 4.60 %
 3411026
 4128774
 1226500
Totals
 500
 100%
 27977501.79
 40950122.01
4664627

99% ОС - отличаются от мейнстрима  :P источник
Ключевое слово "многопоточность"! ИБМ-овцы ниасилили многопроцессность (взаимодействие процессов) при разработке ОС/2 и придумали потоки, которые через ВинНТ попали в современную винду.
Впрочем, многопроцессность, хоть и лучше многопоточности, не устраняет проблемы многоядерности.  :(


Назовите хоть одну идею для ОС, виртуализации, ЯП, компиляторов, придуманную после 1975г.  ??? Именно, придуманную, а не дожидающуюся подходящего железа. Ну, хоть одну.  ::)
В книге "Ассоциативные запоминающие устройства" 1978г (название не точное, как и год, издательство точно не "Мир"), расписана принципиальная схема, где каждая ячейка памяти является примитивным процессором. На задачах определённого класса, например СУБД, выигрыш в быстродействии 3-5 порядков! Лет через 15-20, когда смогут реализовать такую плотность размещения элементов, выдадут за новое слово в архитектуре.  ;)


Это да, а область ПО - рутина.


PS В САП-е (в самом САП-е) хайтека не больше, чем в 1С или блокноте. Если залить на винт Британскую Энциклопедию, файловая система интеллектуальнее не станет.

PSS Параллельные ЯП обтеоретизированы к концу 60-х. Единственная проблема - у программиста плавится мозг от распараллеливания.

PSSS Сингуларити - очередной бред маркетологов, навроде ВинФС.
  • +0.43 / 2
  • АУ
 
 
 
 
  mrt789 ( Слушатель )
05 фев 2010 11:25:12


А в многопроцессорной системе ШД не является узким местом? Или может быть оно там даже более узкое (кеша-то общего нету)?



И это вы меня отсылаете на 3 курс? Я вам открою страшную тайну: процессы в винде ЕСТЬ!!!! А их аппаратная поддержка появилась в i386 вместе с защищенным режимом и gdtr/ldtr. Главное же отличие "процессов" от "потоков" в наличии у каждого процесса своего виртуального адресного пространства. Процессы - это абстракция уровня ОС, и именно ими ОС и управляет. А вот потоки, это уже нити выполнения В РАМКАХ процесса.
Строить параллельную программу на процессах не очень умно (чтобы понять почему, почитайте про то, что происходит с адресным пространством при fork'е, и copy-on-write не спасает - пример Апача приводить не надо, ибо там обработка одного и того же клиента с точки зрения сервера ничем не отличается, а вот если они потом нарвутся на блокировку в БД, хе-хе...). Именно поэтому массово используются потоки, но и у них есть недостаток - у каждого потока есть свой стек выполнения, в результате 100к потоков породить довольно затруднительно. Поэтому в пределе появляется такая абстракция как "green threads" (названий там много может быть), когда N абстрактных "задач" отображается на M реальных потоков,которые выполняются в K реальных процессах, которые выполняются в рамках операционной системы на Z вычислителях (ядрах). Но проблема-то остается! В виде общих ресурсов, к которым надо обеспечивать общий доступ, и именно это портит всю малину с отображением N->M->K->Z.

А теперь вернемся к многопроцессорной система, у которой нет такого "узкого места" (по вашим словам) как кеш... на процессоре 2 у нас в момент X1 выполняется процесс P1, в виде его потока T1, при это он блокирует некий разделяемый ресурс, который нужен потоку T2 того же процесса, затем в момент времени X2 управление передается на шедулер ОС и на процессоре 2 начинается выполнять процесс P2 (всю механику переключения оставим за скобками), а в момент X3 на процессоре 1 начинает выполнятся процесс P1, и конкретно поток T2, который как мы помним зависит от общего ресурса, который в свою очередь заблокировал поток T1. Вот именно такая вермишель происходит в Вашем ЦП и ЦП всех обитателей форума, при этом процесс знать не знает, что ресурс заблокирован и предсказать это он не может. Из этого довольно-таки сумбурного примера видно, что основная проблема не в ядрах и процессорах, а в блокировке ресурса. Получается что все телодвижения на процессоре 1 были зря... Сингулярити как и Erlang решают именно эту проблему, через введение обмена сообщениям в качестве основного механизма: отпадает блокировка, отпадает необходимость в общем адресном пространстве. Хотя все равно какие-то синхронные механизмы там потребуются. И именно такая программная оптимизация является выгодной, потому что как бы Вы там ни крутились с сообщениями, это все равно окажется быстрее чем ждать отклик от удаленной системы, которой в свою очередь может быть нагруженная СУБД-блокировочник или еще какой тормоз.

Про "ниасилили взаимодействие процессов"... кхм, я перечислю, что придумано на сегодняшний день:
1. Разделяемая память
2. Семафоры
3. Сигналы
4. Пайпы/именованная каналы/общие файлы с блокировкой
5. Сокеты (AF_INET и AF_UNIX) - как универсальная коммуникационная абcтракция, если мне изменяет память появилась в BSD Unix (они даже в винде со временем появились, и именно их используют все посетители этого сайта).
6. Очереди сообщений
Я скажу боле того! Страшные и ужасные потоки есть даже в кошерном юниксе!

Ну а по-поводу ТОП 500, это уже откровенная демагогия - все равно что делать выводы о развитии массового автомобилестроения по формуле 1, или (что более похоже) по карьерным самосвалам.



Леонардо нарисовал дельтаплан и вертолет 500 лет назад! Создатели ПАК ФЫ могут массово идти убиваться об стену!



В направлении той же стены могут идти создатели ядерного двигателя - его уже обтеоретизировали, и даже построли в виде РД-чего-то-там. В направлении той же стены может идти Росатом и пр.

ЗЫ А кто Вам сказал, что ВинФС это бред? Рано или поздно от современной иерархической (В)ФС придется уходить.
  • +0.01 / 2
  • АУ
 
 
 
 
 
  zh17. ( Слушатель )
06 фев 2010 18:39:38
ШД является узким местом в любой системе, подчиняющейся законам физики.Веселый Сколько времени понадобится сигналу на прохождения длиннющего пути от микросхемы памяти до процессора? При такой длине оказывают влияние паразитные ёмкости и прочие наводки. Сравните в внутрикристальными условиями, где можно увеличить и разрядность (скажем дублировать, триплировать) шин.
Кеш, хоть общий, хоть раздельный, позволяет компенсировать проблемы ШД на ограниченном круге задач.



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


Будьте так добры, не откажите в любезности, соблаговолите ткнуть пальцем в моё предложение из которого Вы сделали столь глубокомысленное заключение. ???
Ваша неспособность понять смысл нескольких простых предложений, свидетельствует об отсутствии элементарной логики. Черта несовместимая с занятием программированием. Бегите из этого ВУЗа не дожидаясь 3го курса.



Сам то понял чё сказал? (ц)
Если вы что-то не можете объяснить 6-летнему ребёнку, вы сами этого не понимаете (ц) Альберт Эйнштейн


Из авторитетнейшей для Вас вики
ЦитатаПо мнению разработчиков, важным преимуществом языка является принцип работы процесса «let it crash» («пускай падает»). Вместо перехвата ошибок и попытки продолжения работы, часть программы, содержащая рискованный код, выделяется в отдельный «процесс-смертник», который система завершает в случае возникновения ошибки, а процесс-родитель получает соответствующие сообщения и обрабатывает их. Это позволяет избавиться от многочисленных проверок.

Сорвавшийся телефонный разговор (Эрланг), мелкая неприятность - можно перезвонить. Сингулярити нам обещает
ЦитатаРакетный крейсер Йорктаун (Yorktown) потерял управление на 2.75 часа из-за ошибки в Windows NT
От меня до АЭС меньше 100км. Что будет если Сингулярити направит графитовые стержни в "неправильную сторону"?Грустный



Не придумано, а реализовано.
Сокеты появились в Юниксе, остальное было проработано ещё в ОС Мультикс, которая и послужила идеей написания Юникс.


Я скажу боле того! Порой возникает мысль: "лучше бы их там не было".


Вот это правильно! А то, процессы, блокировки.... Не специалисту не понять сходу.
Сравним серийную продукцию участвующих в Ф1 Мерседеса, БМВ и Тойоты с серийной продукцией не участвующего в Ф1 ВАЗа.Подмигивающий Причём, у ВАЗа есть извинение. Он не занимает а мировом автопроме положения, как МС в сфере ОС.
А почему по карьерным самосвалам, а не по умению плеваться вишнёвыми косточками? ???


Теория ассоциатиативных ЗУ проработана до вентиля. Покажите рисунок Леонардо  с которого создатели ПАК ФА содрали, например, компоновку двигателя и отсека вооружения.Строит глазки


Я сказал. И со мной согласны все понимающие разницу между ФС и БД.  :P



PS
Цитата: mrt789Давайте что ли переключимся, вот что щас висит на главной странице Ленты:

http://lenta.ru/arti…2/05/down/

------------------------------
Хайтек?  :D

После такого "шедевра", Вас в тот же игнор, что и Сидорова, уверяющего в превосходстве МС над ИБМ.Веселый
С маркетологами или журналистами, нахватавшимися "умных" слов общаться не интересно.
  • +0.33 / 4
  • АУ
 
 
 
 
 
 
  mrt789 ( Слушатель )
06 фев 2010 22:26:29


Господин хороший, вы бы меньше демагогией занимались и мелкими передергиваниями. Чего ж это вы не процитировали полностью мой абзац? А вот что там было написано:

http://glav.su/forum…9.800.html

Сообщение от 11:25

И это вы меня отсылаете на 3 курс? Я вам открою страшную тайну: процессы в винде ЕСТЬ!!!! А их аппаратная поддержка появилась в i386 вместе с защищенным режимом и gdtr/ldtr. Главное же отличие "процессов" от "потоков" в наличии у каждого процесса своего виртуального адресного пространства. Процессы - это абстракция уровня ОС, и именно ими ОС и управляет. А вот потоки, это уже нити выполнения В РАМКАХ процесса.

Или много букав? Читалка отваливается?

Так на каком это основании вы мне собираетесь открывать страшную тайну, которую я же и озвучил?

А если бы вы удосужились прочитать еще один абзац, то увидели и бы и разбор недостатков:

Строить параллельную программу на процессах не очень умно (чтобы понять почему, почитайте про то, что происходит с адресным пространством при fork'е, и copy-on-write не спасает .......



Оттуда же, первый абзац:

>Erlang (Эрла́нг) — функциональный язык программирования с динамической типизацией, предназначенный для создания распределённых вычислительных систем. Разработан и поддерживается компанией Ericsson. Язык включает в себя средства порождения параллельных процессов и их коммуникации с помощью асинхронных сообщений. Программа транслируется в байт-код, исполняемый виртуальной машиной, что обеспечивает переносимость. Кратко формулу языка можно выразить как Erlang=функциональный язык + процессы.


Так что, каждый видит то, что он хочет...


ЗЫ Нижайше прошу объяснить неучу (мне) разницу между БД и ФС (с точки зрения предназначения). Заодно можете рассказать про страшный оверхед, который дает единственный поток, который есть в любом процессе.

ЗЗЫ Тут надо заметить, что процессы винды (и юникса) и процессы эрланга это несколько разные вещи ("легковесные процессы"), а то щас может еще одна демагогия родиться.

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

Ну а насчет "процессов-смертников", вам не приходило в голову, что у них есть одна замечательная особенность - их падение не приводит к падению всего остального, да и никто не мешает родителю породить еще один, при получении сообщения.

Ну и конечно же мой оппонент не процитировал самую интересную часть из вики (видимо понадеявшись на леность почтенной публики):

>Программы написанные на Erlang способны работать на нескольких узлах. Узлами могут быть процессоры, многие ядра одного процессора либо целый кластер машин. Чем сложнее приложение и чем больше оно создаёт процессов, тем легче его масштабировать. И наоборот, если не используются преимущества функционального программирования, то можно ограничиться единственным процессом.


ЗЗЗЫ Вот маркетолухом меня еще никто не называл....  :D Хм... может еще не поздно задуматься о второй вышке, буду разводить лохов продвигать инновационные продукты на перспективные рынки и набивать карман Сидорову с Гиком способоствовать неумолимому продвижению новых технологий  Веселый  :P
  • +0.02 / 5
  • АУ
 
 
 
 
 
 
 
  AndreyK-AV ( Слушатель )
07 фев 2010 00:52:15
лет дважды по надцать было со мной два случая,
Я восхищено говорил: "c этого спутника можно увидеть звездочку на погоне!". Мне ответили - ты сперва найди этот погон.
Я возмущено говорил, "мы шьем память на магнитных сердечниках, а уже давно БИС". Мне сказали - ядерный взрыв, думай.
Я это к тому что Вы много написали и привели вики сылки, это хорошо. Но вики не истина в последней инстанции, и когда Вы начинаете про "легковесные процесы", "процесы смертники" и маштабируемость узлов вы подумайте про стол засыпаный песком и возможность найти на нем песчинку.
Вам zh17 описал узкие места, Вы и Сидоров в ответ, это круто, все ОК. А есть песок, и проблема найти песчинку.

Чем больше наворачиваете, тем меньше гарантия результата. А MS без гарантии не может, и отсюда прблемы.
  • +0.38 / 4
  • АУ
 
 
 
 
 
 
 
 
  Сидоров 2-й ( Слушатель )
07 фев 2010 13:23:47


Знаете, уважаемый Андрей, я даже не спрашиваю, зачем Вы так много написали, в сущности, ниочем.

Мне крайне интересна мотивация плюсующих этот Ваш пост. А Вам, как модератору, наверное, небезинтересно исследовать, как и почему нормальный аналитический критицизм ГА падает под плинтус, заменяясь абстрактным одобрямсом.

ПыСы. Одобрямс не дремлет +2 -2 = 0. Вот только не мычит это самый одобрямс и не телится...ВеселыйВеселыйВеселый
  • -0.47 / 8
  • АУ
 
 
 
 
 
 
  Сидоров 2-й ( Слушатель )
06 фев 2010 23:46:22


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

Но вместе с тем Вы принялись его поучать, излагая тавтологии, к сути дела не относящиеся. Вам что, не терпится кого-нибудь чему-нибудь научить? Может, Вам меня попробовать? ???



Вы тут как-то очень лихо задвинули, что в OS/2 процессов не было. Я Вас спросил - какую из OS/2 Вы имели ввиду - ответа не дождался. Теперь выясняется, что "процессы это абстракция ОС" и еще более интересное "в винде процесс является лишь контейнером потока" - интересно, что бы это значило?

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

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

Основным предназначением придуманных потоков было и есть сокращение непроизводительных простоев процессоров во время ввода-вывода и оптимизация этого самого ввода-вывода в рамках работы одного приложения. Следствием - значительно более простые схемы обработки асинхронного ввода-вывода.

Садитесь, два.

И я бы порекомендовал Вам отправиться туда, куда Вы посылали товарища - на 3-й курс.
  • -0.07 / 3
  • АУ
 
 
 
 
 
 
  Сидоров 2-й ( Слушатель )
07 фев 2010 00:24:25


"Я Пастернака не читал..." (c)ВеселыйВеселыйВеселый

Для альтернативно одаренных - у Майкрософта исходный код лежит на Singularity - рекомендую посмотреть перед началом художественного свиста.



Слив засчитан. И вправду, как можно Сидорова не в игноре держать, когда он все время норовит за вымя ухватить. Тем более, по теме OS/2 от той самой IBM.Веселый
  • -0.17 / 5
  • АУ
 
 
 
 
  Сидоров 2-й ( Слушатель )
05 фев 2010 14:53:08


Потоки придумали достаточно давно, а стандартизовали впервые в POSIX в 1979-м году.

OS/2 было много (если подразумевать PM под OS/2). В свое время проектирование OS/2 было отягощено массой уже выпущенных PS/2 на 286, для которых нельзя было сделать нормальный процесс (то же с MS Xenix). Реально известная нормальная OS/2 Warp имела (и имеет) все, включая процессы.

Ядро NT было разработано на базе ОС DEC и включало в себя (и включает), наряду с Win32, подсистему POSIX в рамках стандартов, требуемых Пентагоном. Ваш треп про потоки OS/2 vs NT - просто отголоски маркетинговых баталий той поры, не имеющие связи с реальностью.

Вообще говорить, что IBM "ниасилила" то, что было ею создано для OS/360-370, а потом вошло в i386 на аппаратном уровне - нонсенс.
  • -0.04 / 2
  • АУ
 
 
 
 
  Сидоров 2-й ( Слушатель )
05 фев 2010 15:06:43


Называю - JIT compilation. И последующая концепция Singularity (объединившая далеко не только это), в въехать в которую Вам, похоже что-то мешает.

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

И это ни плавит мой мозг от "распараллеливания" ни даже не мешает ему воспринимать новые концепции, типа Singularity.
  • -0.08 / 1
  • АУ
 
 
 
  Сидоров 2-й ( Слушатель )
05 фев 2010 14:13:48


Вы дважды помянули, я уже трижды обратил внимание на Ваши слова о новой концепции - не в коня корм. ИМХО - многим до понимания еще дорасти надо.
  • -0.09 / 1
  • АУ
 
<< Тред №185816
Тред №185818 >>