Опубликован (http://www.top500.org/blog/lists/2012/11/press-release/) 40 выпуск рейтинга (http://www.top500.org/lists/2012/11/) 500 самых высокопроизводительных компьютеров мира. Самым высокопроизвдительным суперкомпьютером, достигнувшим в тесте Linpack производительности в 17.59 Petaflop/s, признан построенный компанией Cray кластер Titan (http://www.top500.org/system/177975), недавно внедрённый в Национальной лаборатории Оук-Ридж (http://ru.wikipedia.org/wiki/%D0%9D%D0%B... (США). Кластер включает в себя 560640 16-ядреных процессоров Opteron 2.200GHz и 261632 вычислительных акселераторов на базе GPU NVIDIA Tesla K20x.
Прошлый лидер рейтинга, кластер Sequoia (http://www.top500.org/system/177556), базирующийся на платформе IBM BlueGene/Q и содержащий 1572864 процессоров Power, оказался на втором месте по производительности (16.32 Petaflop/s), но остался лидером с позиции энергоэффективности, а также является единственным кластером, включающим более миллиона процессоров. Со второго на третье место сместился созданный компанией Fujitsu японский кластер K computer (http://www.top500.org/system/177232), использующий 705024 восьмиядерных процессоров на базе архитектуры SPARC64. Четвёртое и пятое места в рейтинге заняли кластеры на базе платформы IBM BlueGene/Q - Mira (http://www.top500.org/system/177718) (США) и JUQUEEN (http://www.top500.org/system/177722) (Германия).
Наиболее интересные тенденции:
- Самый производительный из отечественных кластеров (http://top50.supercomputers.ru/?page=rating) Lomonosov (http://parallel.ru/cluster/lomonosov.html) за полгода переместился с 22 на 26 место в рейтинге. Всего в Top500 вошло 8 отечественных суперкомпьютеров, что на 3 больше, чем в прошлой редакции рейтинга (в прошлом и позапрошлом рейтинге было 5 отечественных систем, но полтора года назад их было 12);
- Общее распределение по количеству суперкомпьютеров в разных частях света выглядит следующим образом: 261 суперкомпьютер находятся в Америке (265 в предыдущем списке), 105 в Европе (ранее 106), 124 в Азии (ранее 112);
- Распределение по количеству суперкомпьютеров в разных странах:
- США: 250 (252 в прошлой редакции рейтинга);- Китай: 72 (68);
- Япония: 32 (35);
- Великобритания: 24 (25)
- Франция: 21 (22)
- Германия: 19 (20)
- Канада: 11 (10);
- Индия: 9 (5);
- Россия: 8 (5);
- Италия: 7 (8) ;
- Австралия 7 (6);
- Швеция: 6 (4);
Распределение по используемым на суперкомпьютерах операционным системам (в скобках изменение по сравнению с прошлой редакцией рейтинга):
- Linux - 469 (+7), 93.8%
- Unix - 20 (-4), 4%
- Windows - 3 (+1), 0.6%
- BSD - 1, 0.2%
- Смешанные - 7 (-4), 1.4%
- Суммарная производительность всех систем в рейтинге за 6 месяцев возросла со 123 до 162 петафлоп (год назад было 74 петафлоп, полтора - 59 петафлоп). В настоящее время 23 кластера демонстрируют производительность более петафлопа.
- В качестве процессорной основы лидируют CPU Intel - 76% (было 74.4%), AMD занимает второе место - 12% (было 12.6%), на третьем месте - Power - 10.6% (было 11.6%). 38.6 (47%) всех используемых процессоров имеют шесть ядер, 31.8 (15.2%) - восемь ядер, 13.8% (21.6%) - четыре ядра, 9.4% - 16 ядер, 4% - 20 ядер, 1.6% - 2 ядра;
- 62 из 500 систем дополнительно используют акселераторы или сопроцессоры, при этом в 50 системах задействованы чипы NVIDIA, в 7 - Intel Xeon Phi, в 3 - GPU ATI Radeon, в 2 - процессоры Cell;- Среди производителей кластеров на первом месте IBM 38.6% (42.6%), на втором Hewlett-Packard 29.2% (27.6%), на третьем Cray 6.2% (5.4%), на четвертом Appro - 4.8%, на пятом месте компания SGI 3.8% (3.6%);
- Минимальный порог пиковой производительности для вхождения в top500 вырос за 6 месяцев с 60.8 до 76.5 терафлопов, а для top100 с 172.7 до 241.3 терафлопов. Замыкающая нынешний рейтинг система в прошлом выпуске находилась на 337 месте;Одновременно вышел пятый выпуск альтернативного рейтинга кластерных систем Graph 500 (http://www.graph500.org/), ориентированного на оценку производительности суперкомпьютерных платформ, связанных с симулированием физических процессов и свойственных для данных систем задач по обработке огромных массивов данных. Также сформирована десятая редакция рейтинга Green500 (http://www.green500.org/lists/2011/06/top/list.php), в который включены наиболее энергоэффективные суперкомпьютеры. В Green500 в качестве критерия эффективности учитывается отношение LINPACK FLOPS к потребляемой мощности в ваттах.
URL: http://www.top500.org/blog/lists/2012/11/press-release/
Новость: http://www.opennet.me/opennews/art.shtml?num=35358
> Кластер включает в себя 560640 16-ядреных процессоров
> Opteron 2.200GHz и 261632 вычислительных акселераторов
> на базе GPU NVIDIA Tesla K20x.Это неправда. Процессоров там всего: 18688 16-тиядерных CPU + 18688 GPU, ядра которых вообще не поддаются подсчёту. Итого 299,008 CPU-шных ядер плюс тьма GPU-шных. Источник: http://www.olcf.ornl.gov/titan/
> Sequoia, базирующийся на платформе IBM BlueGene/Q и
> содержащий 1572864 процессоров PowerТа же ошибка. В Секвойе 98,304 16-тиядерных процессоров PowerPC A2. Итого 1572864 ядер.
Дальше:> Одновременно вышел пятый выпуск альтернативного рейтинга
> кластерных систем Graph 500, ориентированного на ...Список по версии Graph 500 устарел ещё до выхода -- вместо Titan-а из Оук-Риджа там ещё числится Jaguar (который в сентябре-октябре демонтировали, чтобы на его месте собрать Titan).
> Та же ошибка. В Секвойе 98,304 16-тиядерных процессоров PowerPC A2. Итого 1572864
> ядер.поправочка. A2 - так ядро называется, а чип называется Blue Gene/Q Compute Chip. В нем не 16 ядер A2, а 18 - одно т.н. сервисное, и еще одно резервное.
Ух ты, спасибо за уточнение. Я считал как 16, т.к. иначе не получается общее заявленное количество ядер.
> GPU, ядра которых вообще не поддаются подсчёту.Поддаются, чо нет-та.
18688 вычислительных модулей, на каждом 16 оптероновых ядер и 14 ядрер K20x, т.е. 299008+261632. На Top500 путаются в показаниях указывая то ядра, то процессоры, то переставляя из местами, а переводчик не заморачивался. В самом списке, кстати, указано правильно - 560640 ядер.
С Сейквоей в оригинале про процессоры вообще речи нет. Тут уже переводчик сам нафантазировал.
> Поддаются, чо нет-та.Я посмотрел на спеки K20 Tesla, увидел цифру "2496 thread processors" и не стал даже подсчитывать. А если их 14, то да, общее количество ядер сходится. Спасибо.
"2496 thread processors" у K20 (2688 для K20x) это ядра CUDA.
Они объединены по 192 штуки в SMX Cores. Туда же напиханы ядра двойной точности, регистры, прочий обвес.
Вот этих SMX Cores и получается 13 для K20 и 14 для K20x
А, да.
И правильная ссылка на последний (а не прошлогодний) Green500 - http://www.green500.org/lists/green201211
А что, SGI еще шевелится?
Почитай вот, http://ru.wikipedia.org/wiki/Silicon_Graphics
Я вот насчёт Green500 не понял. Там места распределяются по показателю ФЛОПС/кВт.
Посмотрел на кусок где наш "Ломоносов" (47 место):
http://www.green500.org/lists/green201106&green500from=1&gre...
...
46 место - 359.65 мегафлопс при 364.80 кВт
47 место - 355.78 мегафлопс при 1,894.75 кВт
48 место - 354.56 мегафлопс при 160.00 кВт
...
и так очень много где в этой таблице...
Почему так???
Опс... неправильно прочитал название столбца - MFLOPS/W
вопрос снят :)
Мне интересно у кого же все-таки из них винда стоит кто додумался??
Понимаете ли, дело в том, что винда по определению не может быть адекватной осью для суперкомпьютера. И чтобы догадаться ее туда вкорячить, нужно очень сильно злоупотребить психотропами.
А почему именно линукс, а не юникс? Юникс тоже лучше подходит для суперкомпов, чем винда (судя по рейтингу).
> Понимаете ли, дело в том, что винда по определению не может быть адекватной осью для суперкомпьютераобоснуйте
>> Понимаете ли, дело в том, что винда по определению
>> не может быть адекватной осью для суперкомпьютера
> обоснуйтеА можно я?
Только перед тем, как отвечать "да", поищите здесь shigorin winhpc (плюс по вкусу "Томск"). Может расхотеться.
> поищите здесь shigorin winhpcПоискал, но ничего кроме пары упоминаний о проблемах при её загрузке не нашёл.
Если подробнее раскроете тему, то можно.
>> поищите здесь shigorin winhpc
> Поискал, но ничего кроме пары упоминаний о проблемах при её загрузке не нашёл.Даже если бы это было всё, то его было бы достаточно -- поверьте или проверьте.
Надёжность, диагностируемость, технологичность, ресурсоёмкость Windows не идут ни в какое сравнение с линуксом.
Модель лицензирования на ядро/сокет/хост оказывается крайне несообразной таким установкам (где, например, замена вычислительных узлов является штатной операцией).
Вот и получается, что все виденные и слышанные проекты HPC на виндах -- имиджевые, к которым MS очень тщательно прилагала лапу и им это чистый операционный минус, а вовсе не заработок. Они пытаются рассказывать про то, как в индустрии важны унаследованные приложения на винде и их перенос на winhpc -- вот только *индустрия* в большой мере или на унаследованных приложениях UNIX и майнфреймов, или идёт на линукс стройными колоннами и башлять по ещё одному поводу за недоделку массово не собирается.
>> Если подробнее раскроете тему, то можно.Надёжность, диагностируемость и прочие, которых неизвестно как измеряли, это пустые маркетинговые слова.
Тема лицензирования не раскрыта.
Последний абзац к обоснованию рациональности использования винды относится весьма косвенно.
> Надёжность, диагностируемость и прочие, которых неизвестно как измеряли,
> это пустые маркетинговые слова.Для неспециалиста, который именно что по маркетингу и принимает "решения" -- видимо. А специалистам каждая из этих характеристик много говорит, особенно когда стыкуется с собственным опытом.
Возьмите уже приведённые ранее примеры по ссылке ключевыми словами и взвесьте ввиду предложенных характеристик.
> Тема лицензирования не раскрыта.
А я не смотрел, какие сейчас предлагаются условия -- поэтому ограничился упоминанием о том, что обычные некрософтовские не подходят вообще.
> Последний абзац к обоснованию рациональности использования винды
> относится весьма косвенно.Опять же только для неспециалиста.
Пожалуйста, имейте в виду, что тратить время на неспециалистов от некрософта или позволять им переливать тут из пустого в порожнее намерения нет; поэтому если намерены продолжать обсуждение, потрудитесь представиться в качестве специалиста в обсуждаемой предметной области. Спасибо.
Все вопросы к вам отпали, спасибо за содержательную беседу.
>Тема лицензирования не раскрыта.А ты как то займись поиском инфы по лицензированию их недо-sql серверу и самой оси. Много интересного узнаешь
Вы правы, но учитывая 93,6 vs 0.6, интересно было бы узнать что это за такие особенные задачи, если для них лучше всего подходит именно Windows.
С двумя из списка вроде бы ясно: это сама MS со своим "облаком" Azure, и правительство Австралии, у которого, вероятно, выбора не было.
Вот с третьим, который Dawning 5000A, нестыковочка. Пожалуйста, загляните на http://www.ssc.net.cn/en/resources_1.aspx
Китайцы заменили SLES на Windows и забыли упомянуть об этом на сайте? Настораживает то, что сам сайт крутится на IIS...
Сам никрософт и вкорячил
Мс хитрый.
Стопудово кому-то вкорячил. За отк... 10% скидку.
Я так думаю, МС сами еще и доплатили.
Думаю совет директоров так в этом и уверен.
Там нииириальную скидку на винду дали.
А то что в комплексе дороже любой парочки из топ10 получилось... ну дык, зато все довольны.
> Думаю совет директоров так в этом и уверен.
> Там нииириальную скидку на винду дали.
> А то что в комплексе дороже любой парочки из топ10 получилось... ну
> дык, зато все довольны.А я был прав про Никрософт - http://www.top500.org/system/177982
> Сам никрософт и вкорячилНаверное, купили себе пару суперкомпов, даже не распаковывая, поставили на них коробочки с виндой, и теперь всем говорят, что "в мире есть суперкомпьютеры, на которых стоит винда". На что не пойдешь ради пиара...
как же так у windows 35% серверного рынка, а в top500 всего 0.6%
http://w3techs.com/technologies/overview/operating_system/all
потому что по приведённой ссылке не "35% серверного рынка", а процент сайтов, которые работают под виндой и "юниксами".
Чуешь разницу?
Какое отношение имеют суперкомпьютеры к серверам?
> Какое отношение имеют суперкомпьютеры к серверам?Ты не поверишь - mov eax, ecx - это тоже вычисления!
> Ты не поверишь - mov eax, ecx - это тоже вычисления!Так какое отношение имеют суперкомпьютеры к серверам? И да, ты не поверишь, Крайзес 2 - это тоже вычисления.
Ключ в ответе на вопрос — а что такое сервер?
>> Ты не поверишь - mov eax, ecx - это тоже вычисления!
> Так какое отношение имеют суперкомпьютеры к серверам?На серверах и на СК используются инструкции MOV, CMP, ADD, JMP, RET, ...
Кстати, многие институты предоставляют доступ к ресурсам своих суперкомпов,
причем даже бесплатно. Уапрос: эти суперкомпы сервера или просто суперкомпы?
:)
> На серверах и на СК используются инструкции MOV, CMP, ADD, JMP, RET,А также на десктопах, да. А еще, в зависимости от архитектуры - на эмбеддовке и мобилках.
> Кстати, многие институты предоставляют доступ к ресурсам своих суперкомпов,
> причем даже бесплатно. Уапрос: эти суперкомпы сервера или просто суперкомпы?
> :)"Глючит ли программа, распечатывающая сама себя? Как выглядит программа, не записанная ни на одном носителе? Однажды ученик спросил учителя, как избавиться от глюков в программах, и учитель дал ему вирус CIH. Однажды другой ученик сказал учителю, что хочет программу без глюков. "Дурак! - крикнул учитель, - почему ты не просишь глюк без программы?" - и ударил его винчестером по голове. Если вы все еще не обрели просветление, с вами не о чем говорить." ©YuN
> Кстати, многие институты предоставляют доступ к ресурсам своих суперкомповО, это интересно.
> причем даже бесплатно.
А вот это решающе! Хотелось бы ссылок, чтобы попробовать попускать мои openmpi-проги.
>> Кстати, многие институты предоставляют доступ к ресурсам своих суперкомпов
> Хотелось бы ссылок, чтобы попробовать попускать мои openmpi-проги.Про институты толком не знаю, а вообще:
http://parallel.ru/russia
http://parallel.ru/service.html
> Какое отношение имеют суперкомпьютеры к серверам?Технологии первых за несколько лет докатываются до вторых в ДЦ. Системного ПО это тоже касается, как можно было наблюдать во времена Beowulf.
>> Какое отношение имеют суперкомпьютеры к серверам?
> Технологии первых за несколько лет докатываются до вторых в ДЦ. Системногоэто какие, например? примеры можно?
>>> Какое отношение имеют суперкомпьютеры к серверам?
>> Технологии первых за несколько лет докатываются до вторых в ДЦ.
> это какие, например? примеры можно?Интерконнект, плотность упаковки, охлаждение, мониторинг...
>>>> Какое отношение имеют суперкомпьютеры к серверам?
>>> Технологии первых за несколько лет докатываются до вторых в ДЦ.
>> это какие, например? примеры можно?
> Интерконнект, плотность упаковки, охлаждение, мониторинг...Инфинибенд (половина Топ500) попал в HPC из датацентра.
1GB езернет (вторая половина Топ500) попал в HPC из датацентра.Какой именно интерконнект пришел из HPC в general computing?
Плотность упаковки - не HPC специфичный фактор, а важный для любого, даже не очень крупного ДЦ.
Охлаждение - тут я не понял, что вы имеете в виду, что это за специфические технологии охлаждения для суперкомпьютеров, которые попали в датацентр и чем они отличается от охлаждения любого тепловыделяющего оборудования.
То же самое - про мониторинг.
> Инфинибенд (половина Топ500) попал в HPC из датацентра.Насколько я помню, ровно наоборот -- Myrinet и прочие дельфиниксы тоже пилились под HPC. Хотя нарыл и почитал http://www.networkworld.com/newsletters/stor/2006/0213stor1.... -- похоже, тут Вы более правы, хотя изначальная задумка поползла из лабораторий в жизнь всё-таки скорее через HPC-сайты, а в ДЦ тем временем хозяйничал FC.
> 1GB езернет (вторая половина Топ500) попал в HPC из датацентра.
Так это вообще вспомогательное или на нечувствительные к латентности задачи, о гигабите речь не шла.
> Плотность упаковки - не HPC специфичный фактор, а важный для любого, даже
> не очень крупного ДЦ.Специфичный, т.к. латентность зачастую критична.
> Охлаждение - тут я не понял, что вы имеете в виду, что это за специфические
> технологии охлаждения для суперкомпьютеров, которые попали в датацентр
> и чем они отличается от охлаждения любого тепловыделяющего оборудования.Средняя плотность выделения тепла AFAIK выше, т.к. группа активно считающих на полную узлов -- это нормально, а вот группа загруженных на 100% по CPU серверов -- нет.
> То же самое - про мониторинг.
Вытекает из плотности размещения -- в ДЦ более обычно одно-два блейд-шасси на стойку, а 100% заполнение.
e.g. http://ftp.linux.kiev.ua/pub/Linux/xpandrx/highload_2011.pdf
>> Инфинибенд (половина Топ500) попал в HPC из датацентра.
> Насколько я помню, ровно наоборот -- Myrinet и прочие дельфиниксы тоже пилились
> под HPC. Хотя нарыл и почитал http://www.networkworld.com/newsletters/stor/2006/0213stor1....
> -- похоже, тут Вы более правы, хотя изначальная задумка поползла из
> лабораторий в жизнь всё-таки скорее через HPC-сайты, а в ДЦ тем
> временем хозяйничал FC.инфинибенд пополз, как только появился в продаже по доступным ценам, и по-моему, не только в HPC, но и там, где просто нужен был толстый I/O. миринет до датацентров, по-моему, так и не дополз, и пилился ЕМНИП как замена эзернету. чисто суперовские интерконнекты типа торусов в обычный ДЦ вряд ли попадут.
>> 1GB езернет (вторая половина Топ500) попал в HPC из датацентра.
> Так это вообще вспомогательное или на нечувствительные к латентности задачи, о гигабите
> речь не шла.поправочка, 10G. я присмотрелся повнимательнее, сотня из 190 помеченных как гигабит эзернет это хьюлетовские кластера, у которых может быть интерконнект как инфинибенд так и 10G эзернет, то же самое датаплексы; на чем интерконнект у тьмы китайских кластеров на х3650М3 - одному императору известно.
>> Плотность упаковки - не HPC специфичный фактор, а важный для любого, даже
>> не очень крупного ДЦ.
> Специфичный, т.к. латентность зачастую критична.тогда мы говорим о разных факторах; при проектировке general computing ДЦ желание разместить как можно больше ядер и памяти в юните далеко не всегда диктуется требованиями латентности.
>> Охлаждение - тут я не понял, что вы имеете в виду, что это за специфические
>> технологии охлаждения для суперкомпьютеров, которые попали в датацентр
>> и чем они отличается от охлаждения любого тепловыделяющего оборудования.
> Средняя плотность выделения тепла AFAIK выше,иии что?
т.к. группа активно считающих на полную
> узлов -- это нормально, а вот группа загруженных на 100% по
> CPU серверов -- нет.во-первых, не загруженные на 100% серверы в ДЦ - это не нормально, КМК, а во-вторых, вы вроде говорили про технологии охлаждения. что полностью загруженная стойка греется сильнее, чем ненагруженная, я в курсе.
>> То же самое - про мониторинг.
> Вытекает из плотности размещения -- в ДЦ более обычно одно-два блейд-шасси на
> стойку, а 100% заполнение.ага, спасибо, интересная штука. а бывает и так:
#!/usr/bin/perl#################################################################################################
# File Name: check_bg_node_event.pl #
# Author: Blue Gene Speed Team, Summer 2007 #
# Date: 7/24/2007 #
# Description: This event handler runs on a state change for the BG Node service. On a #
# WARNING or CRITICAL state, it will call build_html.pl to build an HTML file that will help in #
# viewing the plugin's log file using Nagios. #
# Parameters: #
# ARGV[0]: Service State ($SERVICESTATE$ within Nagios) #
# ARGV[1]: Hostname ($HOSTNAME$ within Nagios) #
# ARGV[2]: Service Name ($SERVICEDESC$ within Nagios) #
# ARGV[3]: Host Address ($HOSTADDRESS$ within Nagios) #
#################################################################################################
# Other: This script is triggered when BG Node service enters a new state. Conditionals #
# that this script process by default are OK, WARNING, CRITICAL, and UNKNOWN. Upon a warning #
# or critical state, the file build_html.pl will be called with the correct arguments and #
# it will create an html file for viewing log files and making external commands on a service. #
################################################################################################## Edit the below variables as needed for your plugin.
my $pluginName = "check_bg_node"; # ie 'check_ping'
my $logName = "node.log"; # ie criticalerror.log
my $htmlName = "node.html"; # ie criticalerror.html
my $relativeLogPath = "/nagios/logs/";
my $htmlFile="/srv/www/htdocs/nagios/logs/";остаток кода поскипан, но вы поняли идею :)))
что касается той системы, на которую вы кинули ссылку, то у меня на второй странице сложилось четкое ощущение, что система предназначена для мониторинга любой системы, генерящей большое количество ивентов, будь то суперкластер, или например какой-нибудь 5ess. там есть какая-то HPC специфика, которую я упустил?
>> Средняя плотность выделения тепла AFAIK выше
> иии что?Иии соответственно охлаждать приходится интенсивней[, мониторить оперативней].
> во-первых, не загруженные на 100% серверы в ДЦ - это не нормально, КМК
Интересно, я до сих пор сталкивался только с народом, который предпочитает оперативный запас порядка хотя бы 10--20%. (без подковырок, сам-то не ДЦ-шник)
> ага, спасибо, интересная штука. а бывает и так:
Сурово :)
> что касается той системы, на которую вы кинули ссылку, то у меня
> на второй странице сложилось четкое ощущение, что система предназначена для мониторинга
> любой системы, генерящей большое количество ивентов, будь то суперкластер, или например
> какой-нибудь 5ess.В принципе да; см. тж. слайд 12 вот здесь: http://ftp.linux.kiev.ua/pub/conference/peers/foss-sea/2011/...
> там есть какая-то HPC специфика, которую я упустил?
Возможно, имеющая отношение -- в модели установки описываются платформы, которые в точности (до сенсора) соответствуют установленному оборудованию.Соответственно если оно относительно однообразное (на "Ломоносове" в итоге набралось штук пять или шесть вариаций, помнится -- благодаря шестиядерникам и теслам), то ещё более-менее; а если совсем разношёрстное, то подход придётся в лучшем случае адаптировать.
Ещё одна специфика (не HPC-, а данной реализации) -- кодирование физического положения объекта (location); здесь лучше Валика расспросить, но изначальная задумка оперировала стойками/коридорами/рядами, помнится.
Ну и опосредованная -- через латентность -> длину линков -> плотность размещения -> плотность тепловыделения: при ~70 кВт на шкаф типичная минута на реакцию оказывается непозволительной роскошью, здесь решение об аварийном складывании установки по IPMI/на UPS может быть принято за единицы секунд.
>>> Средняя плотность выделения тепла AFAIK выше
>> иии что?
> Иии соответственно охлаждать приходится интенсивней[, мониторить оперативней].охлаждать интенсивнее - да, мониторить оперативнее - не обязательно. конечно, можно превратить систему мониторинга в АСУ, но АСУ заметно дороже.
>> во-первых, не загруженные на 100% серверы в ДЦ - это не нормально, КМК
> Интересно, я до сих пор сталкивался только с народом, который предпочитает оперативный
> запас порядка хотя бы 10--20%. (без подковырок, сам-то не ДЦ-шник)не вижу в этом ничего плохого. LA 3-5 это нормально, главное, чтобы оно не прыгало непредсказуемо и не упиралось в i/o. конечно, следует смотреть, как такая нагрузка выглядит со стороны клиента; виндовым терминальным серверам может поплохеть и при загрузке меньше 80%. и без вопросов, закладываться на полную нагрузку, не имея в ферме резервных машин в стендбае это плохо.
>> там есть какая-то HPC специфика, которую я упустил?
> Ну и опосредованная -- через латентность -> длину линков -> плотность размещения
> -> плотность тепловыделения: при ~70 кВт на шкаф типичная минута на
> реакцию оказывается непозволительной роскошью, здесь решение об аварийном складывании
> установки по IPMI/на UPS может быть принято за единицы секунд.эм. 70 ква на шкаф и единицы десятки секунд на решение. Я бы сказал, что что-то всерьез не так с охлаждением. я бы даже сказал, что у вас там пожар. в такой ситуации нужен не мониторинг, а баллончик с таблом "ГАЗ УХОДИ".
1 блейдцентр под полной нагрузкой - это грубо 10 ква. при максимальной набивке четыре шасси в стойке. они начинают орать о высокой температуре при 35-40 кому как нравится и погасятся менеджмент модулем при 50 безо всяких команд. Серьезно, если они проскочат температуру от 35 до 50 в течение десятков секунд, это или пожар в ДЦ или одновременный отказ всей вентиляции внутри шасси. з
а счет чего там у вас такой быстрый рост температуры?
мой домашний СК "Плазма-Атом" выдает 9.3 Petaflop/s
А почему "Ломоносова" называют отечественным, если все комплектующие в нём произведены в других странах (не входящих в СНГ)? Там ведь даже стойки сделаны в Тайване, как и все соединительные кабели и тому подобные вещи. Разве это честно - присваивать себе разработки других людей? Вот если бы в "Ломоносове" были процессоры с разработанной в России архитектурой, а управлялись бы они ОС, созданной у нас же, то это был бы "отечественный" компьютер.А так выходит, что просто взяли чужие наработки, насовали их в корпуса в соответствии с рекомендациями зарубежных специалистов и теперь гордятся чем-то.
Или я не понимаю сути всех этих рейтингов?
> А почему "Ломоносова" называют отечественнымПо принадлежности этому "отечеству".
> Там ведь даже стойки сделаны в Тайване
Кстати, что-то типа стоек (или корпусов?) - разрабатывалось "здесь".
> Вот если бы в "Ломоносове" были процессоры с разработанной в России архитектурой, а управлялись бы они ОС, созданной у нас же
Не дай Б-г. Это социалистический Китай может себе позволить разработку процессоров, а не эта банановая республика. А "ОС создавать" - даже Китай пока не отважился.
> гордятся чем-то
Сделали нечто, на чем можно считать. То, что при этом не стали велосипеды изобретать, а развивали существующие технические решения - нормальная практика.
PS: Конечно, лучше было бы гордиться тем, что там считается. Вот с этим, как я подозреваю, до сих пор есть проблемы (лет 6 назад старый кластер простаивал, а с получением доступа из МГУ была нехилая волокита).
google KOMDIV-32
> google KOMDIV-32Китайские аналоги, в отличие от - можно купить.
>> google KOMDIV-32
> Китайские аналоги, в отличие от - можно купить.Речь была о наличии, а не о покупке. Конечно, комдив купить нельзя, это для отечественной оборонки железка.
В своё время покопаться удалось с ней, отчёт тут: http://kibab.ya.ru/replies.xml?item_no=307
> Речь была о наличии, а не о покупке.Речь шла о разработке. Что-то, полученное на бумаге или в крошечной серии для испытаний - бесконечно далеко от разработанного продукта.
Как думаете, много было бы проку от "разработанного" т-34 без проведенной до этого индустриализации?
> Конечно, комдив купить нельзя, это для отечественной оборонки железка.
Звучит довольно жалко...
>> Речь была о наличии, а не о покупке.
> Речь шла о разработке. Что-то, полученное на бумаге или в крошечной
> серии для испытаний - бесконечно далеко от разработанного продукта.
> Как думаете, много было бы проку от "разработанного" т-34 без проведенной до
> этого индустриализации?Я и не спорю ;-)
>> Конечно, комдив купить нельзя, это для отечественной оборонки железка.
> Звучит довольно жалко...Ну так вообще состояние российской микроэлектроники сейчас иначе как жалким не назовёшь, это да.
Конечно не понимаете. Это рейтинг суперкомпьютеров, а не комплектующих для них. На досуге подумайте, почему при известных общих принципах и наличии доступных комплектующих создать ядерное оружие смогли всего несколько стран, аналогично с космической программой.
О как! В мухосранске оружейный плутоний бабки на базаре продают? И меланж в самагонных бутылях?
> Конечно не понимаете. Это рейтинг суперкомпьютеров, а не комплектующих для них. На
> досуге подумайте, почему при известных общих принципах и наличии доступных комплектующих
> создать ядерное оружие смогли всего несколько странПричем совок все скопипастил
> А так выходит, что просто взяли чужие наработки, насовали их в корпуса
> в соответствии с рекомендациями зарубежных специалистов и теперь гордятся чем-то.
> Или я не понимаю сути всех этих рейтингов?Вы не понимаете ещё и той инженерной работы, которая была проделана тогдашним техническим составом Т-Платформ. К сожалению, сейчас у них такое повторить AFAIK просто некому.
> А так выходит, что просто взяли чужие наработки, насовали их в корпуса
> в соответствии с рекомендациями зарубежных специалистов и теперь гордятся чем-то.я тебе больше скажу - первоначально "Ломоносов" назывался "Ораниенбаум", и спроектировали его в Интеле/Хайфа.
Власти просто скрывают.
Вряд ли найдётся хоть один суперкомп, который полностью в одной стране сделан. Даже если все фабрики в Китае, то это совсем не обязательно китайский комп ;) - мозги у одних, управленцы и деньги у вторых, руки у третьих...
Это не показатель технологической развитости.
Это рейтинг денежных и вычислительных возможностей.
почему используют в основном linux? а не freebsd? чем его преимущества?
Тсссс! :)
Как бы холивар не случился... :)
хехе, никогда бы не подумал что я троль=)
на самом деле, было интересно узнать, в технических подробностях, за счет чего на линуксе можно построить суперкомпьютер, а на фрибсд нельзя, а тут развели воды только одной с криками "Докажи,докажи"Единственное по теме только написал AlexAT, и то не аргументировано, надо копаться еще разбираться
> на самом деле, было интересно узнать, в технических подробностях, за счет чего
> на линуксе можно построить суперкомпьютер, а на фрибсд нельзяПочему нельзя -- можно, просто незачем.
> а тут развели воды только одной с криками "Докажи,докажи"
Критические части:
- умение современного железа вместе с управлением энергопотреблением;
- умение специфического железа (IB, HBA, в случае того же "Ломоносова" -- барьерная сеть);
- доступность подходящих технологий распределённого хранения данных;
- хорошая масштабируемость (в т.ч. по RAM/CPU cores);
- пригодность для тонкого тюнинга разумными усилиями;
- пригодность для фиксации доработок в воспроизводимом виде.Желающие могут пригласить в тред netch@, у него могут найтись ещё более предметные пункты.
> Критические части:
> - умение современного железа вместе с управлением энергопотреблением;
> - умение специфического железа (IB, HBA, в случае того же "Ломоносова" --
> барьерная сеть);
> - доступность подходящих технологий распределённого хранения данных;
> - хорошая масштабируемость (в т.ч. по RAM/CPU cores);
> - пригодность для тонкого тюнинга разумными усилиями;
> - пригодность для фиксации доработок в воспроизводимом виде.
> Желающие могут пригласить в тред netch@, у него могут найтись ещё более
> предметные пункты.Я думаю, все дело проще; скорее всего, в SGI и у Крея (и кому там еще мы должны говорить спасибо, что линь попал на суперы) в тот момент времени, когда старые операционки стали не справляться, нашлось больше девелоперов, которые умели линукс, чем девелоперов, которые умели айрикс или что там за ОС применялась. И они стоили, думаю, немного дешевле. а все остальное, о чем вы говорите - это уже следствие, благодаря патчам от SGI в том числе.
> Я думаю, все дело проще; скорее всего, в SGI и у КреяНачалось-то до них, помнится.
Для начала расскажите о преимуществах FreeBSD в этом вопросе. При прочих равных всегда лучше использовать более распространенную ОС.
ты че думаешь линукс прям "дикарём" запускают?
не чувак её допилит или активировать нужные куски ядра нужно, а что до фяхи - пели себе на здоровье, а линусом надо допил выложить, конечно благодоря этому, есть некая публичная база, но выкладыватся далеко не всё(в тихомолку использовать можно "а у нас это работает"), но невсегда использут публичный хлам, так что.. просто более известна и есть кодовая база в отличии от мак оса и винды уиксов всяких и ириксов.
> пели себе на здоровьекакие песни хоть пели?
> а линусом надо допил
> выложить, конечно благодоря этому, есть некая публичная база, но выкладыватся далеко
> не всё(в тихомолку использовать можно "а у нас это работает")Да можно и громко трубить: на нашем суперкомпе у нас то-то и то-то, а вот не дадим: мы ведь не распространяем ядро в двоичном виде, поэтому не обязаны и в исходниках.
я не знаю, поэтому и спрашиваю, чтобы узнать преимущества
> При прочих равных всегда лучше использовать более распространенную ОС.То Apple боролась с большими IBM, потом они сами стали самыми-самыми по весу на бирже.
То линукс боролся с юниксами и виндой, а теперь сам стал самым распространённым и начал препятствовать нормальному развитию других.
Потому что брэнд "Linux" коммерчески раскручен и у всех на слуху, а FreeBSD — нет.Преимущества у GNU/Linux относительно FreeBSD только в популярности и практической ориентированности на бизнес-схемы поддержки и сопровождения программно-аппратного комплекса предприятия. Спроси любого директора IT любой компании, какие серверные ОС ему известны, он скажет: "Windows и Linux, ещё Solaris, но последнюю мы не используем за неимением средств на сопровождение". Эта операционная система прежде всего известна в основном как альтернатива Windows на серверах и сетевом оборудовании. Стоит столько же.
Бренд "Деревянная телега" хуже коммерчески раскручен чем "современный грузовик", только это и ведет к повсеместному доминированию грузовиков вместо телег.
> Потому что брэнд "Linux" коммерчески раскручен и у всех на слуху, а
> FreeBSD — нет.
> Преимущества у GNU/Linux относительно FreeBSD только в популярности и практической ориентированности
> на бизнес-схемы поддержки и сопровождения программно-аппратного комплекса предприятия.И, как следствие, в большем числе заинтересованных в развитии GNU/Linux, чем в развитии FreeBSD. Читай больше разработчиков, больше спонсоров, лучше поддержка.
>Читай больше разработчиков, больше спонсоров, лучше поддержка....""crammed in a record-breaking 176.73 changes per day (7.36 changes per hour.)
...""1,195 different developers contributing patches to the 3.5 kernel;Это посвежее бутет, чем dwheeler.com/oss_fs_why.html . яЗен :/любит свеженькое. Приятного!
Так от скольких разрабов были коммиты в последнем релизе _ядра_ FreeBSD? ...и да, можете посчитать коммиты во всей [базовой] cистеме -- за релиз!?
Как там с 170+ в день? Ну, с 1000+ разрабов хотя бы??
Во всём виноват Ай-Би-Эм, адназначна. Да!
> Потому что брэнд "Linux" коммерчески раскручен и у всех на слуху, а
> FreeBSD — нет.Когда я пользовался фряхой (а пользовался я ей побольше и пораньше тебя), то с поддержкой SMP у нее был полный швах. И файловая система гогно-гогном.
Изень не позорь нормальных бсдшников своим бздунством.
не хочу подливать, конечно, но с параллелизмом у BSD "баааааааальшие проблемы"
в кластерах где есть по 16 ядер на x86 - оно упрется в блокировки внутри ядра
ну а там, где нет x86 - там понятное дело, что нет и BSDв ядре линухов разработчиками уделяется огромное внимание параллелизму - то там, то сям в пролетающих коммитах постоянно можно видеть оптимизации блокировок
> какая разница че у них в голове, ты мне скажи че там
> не так.Там... там до сих пор _везде_ спинлоки/мютексы вместо RCU. Приговор, в общем-то.
>> какая разница че у них в голове, ты мне скажи че там
>> не так.
> Там... там до сих пор _везде_ спинлоки/мютексы вместо RCU. Приговор, в общем-то.и? ты хочес сказать в линуксе локов нет? вы ходь вики бы по читал RCU - сказал в лужу пернул.
In computer operating systems, read-copy-update (RCU) is a synchronization mechanism implementing a kind of mutual exclusion[note 1] which can sometimes be used as an alternative to a readers-writer lock. It allows extremely low overhead, wait-free reads. However, RCU updates can be expensive, as they must leave the old versions of the data structure in place to accommodate pre-existing readers. These old versions are reclaimed after all pre-existing readers finish their accesses.
короче можно спецовое ядро сделать и т.п. но нах это на ос кторая запускатся обычно на компах с 8 ядрами и иногда от силы с 32 ядрами?
> и? ты хочес сказать в линуксе локов нет? вы ходь вики бы
> по читал RCU - сказал в лужу пернул.Ты бы хоть читать научился, прежде чем писал. Я хочу сказать, что RCU в огромном числе случаев оптимальнее классических блокировок. В линухах RCU используется наряду со спинлоками (от которых тихонько избавляются), а вот в бзд вариантов нет.
Причем где-то на мейлинглистах бзд в 2011 пролетало об острой необходимости перехода на RCU в ядре, но идею быстро и благополучно замяли.
>> и? ты хочес сказать в линуксе локов нет? вы ходь вики бы
>> по читал RCU - сказал в лужу пернул.
> Ты бы хоть читать научился, прежде чем писал. Я хочу сказать, что
> RCU в огромном числе случаев оптимальнее классических блокировок. В линухах RCU
> используется наряду со спинлоками (от которых тихонько избавляются), а вот в
> бзд вариантов нет.
> Причем где-то на мейлинглистах у бздунов в 2011 пролетало об острой необходимости
> перехода на RCU в ядре, но идею быстро и благополучно замяли.
> Так вот до сих пор и живут.на десктопе то это зачем? мне например очень понятно почему замяли. кусок листа найди.
> на десктопе то это зачем?Одного ядра хватит всем? К слову говоря, сильнее всего в спинлоки упирается сетевой стек... и подсистема распределения памяти.
И - да - мы разве о десктопах? ОС именно серверные, и применение их очевидно. К чему тут десктоп?
потомучто ось десктопная/серверы начального/седнего уровня. о суперкомах - их ваще 1000 установок на весь земной шар и че кто-то будет этим парится... я тебе сто раз сказал серне количество ядер на серва штук 6-10. и не нада думать о 1024х или 65535х процах.
> я тебе сто раз сказал серне количество ядер на серва штук
> 6-10. и не нада думать о 1024х или 65535х процах.И чего? Оно даже на 2 ядрах при определенных ворклоадах колом встанет, если грамотно не сделать.
К слову - эти "65xxx" достигаются пачками мелкохостов по 16/256/... ядер. Причем >16 - только в случае не-x86.Пример - ну блин, снова подливаю... пример - всё тот же пресловутый несчастный pf. Верещали-верещали о PF/SMP, оптимизациях, и иже с ними - а избавиться от showstopper блокировок так и не получилось. Потому, что defective by design, и чтобы поднять до SMP - надо с нуля переписывать.
> Пример - ну блин,Да не парься ты тут. Это как перед свиньями бисер. Не видишь, чувачок не в теме, максимум что может - на википедию сходить!
>[оверквотинг удален]
>> 6-10. и не нада думать о 1024х или 65535х процах.
> И чего? Оно даже на 2 ядрах при определенных ворклоадах колом встанет,
> если грамотно не сделать.
> К слову - эти "65xxx" достигаются пачками мелкохостов по 16/256/... ядер. Причем
> >16 - только в случае не-x86.
> Пример - ну блин, снова подливаю... пример - всё тот же пресловутый
> несчастный pf. Верещали-верещали о PF/SMP, оптимизациях, и иже с ними -
> а избавиться от showstopper блокировок так и не получилось. Потому, что
> defective by design, и чтобы поднять до SMP - надо с
> нуля переписывать.:) а он мне нужен? я его не разу не пользовал - сказали тебе он на смп не помошник да и зачем мне не родной филтр? че там такого, че я сделать так не могу?
вот все про нат помню терли что кучу адресов добавить можно - типа крута не все так могут.
а я делал по тупому - конфигурил 16 ng_nat лепил их к виртуальному фейсу и пораскидывал по подсетем исходящий траф, 0.xx в один 1.xx в другой и , и было все ок входяшщий по адресу назначения...
опиши задачу - интересно даже стариной трехнуть.я вобще считаю с фряхи выкинуть его надо к ядрене фене может в опенке оставить - пусть фанаты ковыряются... но мне он не нужен. вместе с альтку я шейпил ng_car прям на сервере pppoe - отдавая атрибуты радиусом
> потомучто ось десктопная/серверы начального/седнего уровняЕсли смотреть правде в глаза -- то "потому что никому не упёрлась завтра".
hint: в этом завтра производительность обеспечивается скорее количеством ядер, чем их индивидуальной мощностью и тем более частотой, насколько пока получается судить.
> о суперкомах - их ваще 1000 установок на весь земной шар
Немножко больше, и это передовой край _серверных_ технологий.
> я тебе сто раз сказал серне количество ядер на серва штук 6-10.
Заведите на восьми ядрах четвёртую фрю из эпохи, когда "среднее количество один процессор, ну если круто -- то два".
> и не нада думать о 1024х или 65535х процах.
А тем временем линукс на хостах о тысяче-другой CPU под управлением одного ядра ОС ездит уже много лет -- спасибо SuSE и SGI.
Вам не надо -- вы не думайте. Только завтра не удивляйтесь, почему старая работа накрылась, а на новую таких не берут.
Ничего личного, мне эти прогрессы тоже не по ноздре.
уперлось уперлось
все упирается в некие парамы:
например сейчас будем считать амд 16 ядерным хотя конешно ядер там 8 ну фиг с ним потребляет это чудо точно не мене 125 ват (в руках не держал) и та в самом оптиместичном случае получаем 7 ват на ядроедим дальше ну пусть у нас "а риск машин" ну блин сколько на ядро в 3 раза меньше пойдет? берем 2 вата - легче считать че там тер про 256? ну крутото пол кила чип покушал. это ты хоческазать ты справишься с тепловыделением? мало того что ком откушал как паравоз от разетки так ему еще и криогенную систему охлаждения нада.
ну короче понял да? все му есть граници и в существующих техно процессах количествоядер ОГРАНИЧЕНО. единственный выход это какойнибуть квантовый или опческий комп но не транзисторный.
а ты думаешь производительность на ядро тоже не играет рояли? не можно сделать эергитически мелки ядра с очень пиримитивной функционалом угу ипрлучится GPU
крута заче в одной системе GPU и GPU? может лучше CPU и GPU ну короче сико там топовые гпу ужирают? больше 250 ват на чип? ага дву процова радеон или нвидия - полкила - кульно.а вреальности ситуация круче ток утекает, магнитные поля сцепляются, задержки тоже рояль начинают играть ну короче делим минимум на два.
> на десктопе то это зачем? мне например очень понятно почему замяли. кусок листа найди.так весь спор пошел почему линукс предпочитают бсде на суперкомпьютерах, не на десктопе
> В линухах RCU используется наряду со спинлоками
> (от которых тихонько избавляются), а вот в бзд вариантов нет.http://netbsd.gw.com/cgi-bin/man-cgi?pcq++NetBSD-current
http://netbsd.gw.com/cgi-bin/man-cgi?atomic_cas++NetBSD-current
http://wiki.netbsd.org/projects/project/atomic_pcq/
http://wiki.netbsd.org/projects/project/atomic_radix_patrici.../
http://wiki.netbsd.org/projects/project/atomic_fifo_lifo_queues/
>> В линухах RCU используется наряду со спинлоками
>> (от которых тихонько избавляются), а вот в бзд вариантов нет.К счастью, есть хотя бы проекты. От проекта до реализации - уйма времени. От NetBSD до остальных BSD - не меньше. А в ядре линуксов всё это уже есть и нормально работает - более того - пилится дальше, в сторону бОльшей эффективности. Это не к теме холивара, это просто о том, что очень сильно опаздываете, товарищи.
> Это не к теме холивара, это просто о том, что очень сильно опаздываете, товарищи.Не надо этого пафоса. Твоих личных заслуг в ядре линукса нет.
Но если тебе интересно что-нибудь кроме твоих личных преставлений о,
сходи лучше пообщайся в tech-pkg@. Порой твои знания сильно далеки
от того, о чем ты рассуждаешь.
Да, моих коммитов в ядре нет. Часть модулей отдам после релиза проекта, но не ранее.Тем не менее, вполне себе ориентируюсь в коде ядра, подходах, блокировках, etc. - в силу специфики задачи.
А вот в твоем сообщении - действительно - полно пафоса, и ни одной здравой мысли.
точно раскажи нам про спин локи почему такие откуда название, как можно приметивно реализовать, как можно улучшить, что значит "концепция владения".
> точно раскажи нам про спин локи почему такие откуда название, как можно
> приметивно реализовать, как можно улучшить, что значит "концепция владения".любые персональные рассказы за Ваши деньги, 30$/час, устроит?
а для не желающих платить за воздух - минимальный ликбез есть тут:
http://en.wikipedia.org/wiki/Spinlockосновной фокус в том, что RCU - это не блокировка - это механизм, позволяющий в отдельных случаях обойтись вообще без блокировок при чтении
> любые персональные рассказы за Ваши деньги, 30$/час, устроит?
> а для не желающих платить за воздух - минимальный ликбез есть тут:
> http://en.wikipedia.org/wiki/Spinlockустроит начинай
а вообще
давай я тебе бесплатно расскажу:
спинлок циклическая блокировка - реализация - иксклюзивнаяч команда проца (пише в иксклюзивнго в память) дале цикл - постоянно читаем память можно эксклюзивно но тогда стопать процессор кучу раз в секунду - так никто не делает обычно экклюзивно пишут, а читают обычной командой - так увеличивается производительность системы. дале...как еше убыстрить? ну логично применят команду блокирующую проц на фиг как можно реже, а как? очень просто дело втом что у потока есть ID как и у процесса, значит можно сделать если у тебя верный ID блок можно снять если другой - фиг.
> устроит начинайПредоплату в студию.
>> устроит начинай
> Предоплату в студию.ушла на емайл
> ушла на емайлне вижу
>> ушла на емайл
> не вижуда пофиг начинай.
> как еше убыстрить? ну логично применят команду блокирующую проц на фиг как
> можно реже, а как?А вот так - использовать менее блокирующие механизмы. Типа RCU.
> очень просто дело втом что у потока есть ID как и у процесса, значит можно сделать если у тебя верный ID блок можно снять если другой - фиг.
Ты вообще сам-то понимаешь, что несешь? Блокировки для того и служат, чтобы никто их не "снял" в момент исполнения критической секции.
>>> реализация - иксклюзивнаяч команда проца (пише в иксклюзивнго в память)
какая-какая команда? быть может, атомарная?
>> как еше убыстрить? ну логично применят команду блокирующую проц на фиг как
>> можно реже, а как?
> А вот так - использовать менее блокирующие механизмы. Типа RCU.
>> очень просто дело втом что у потока есть ID как и у процесса, значит можно сделать если у тебя верный ID блок можно снять если другой - фиг.
> Ты вообще сам-то понимаешь, что несешь? Блокировки для того и служат, чтобы
> никто их не "снял" в момент исполнения критической секции.да да.... посмотри, в том то и дело что можно выдумать id можно взять существующий. тебе надо стопать проц как можно реже в этом то и суть а конкретно там пипец как сложно. у блокировок естьиерархия где сверху обычно "всем боятся я блок ставлю" а остальные блокирующих операци не используют.
Есть мандатные блокировки в Linux - "ticket spinlocks" - но там вовсе не ID потока, а просто сериализация доступа к спинлоку - очень интересный ход, кстати."Пипец как сложно" - это дилетантам рассказывайте. А здесь будьте добры по теме: что такое "всем боятся" - BKL что-ли? Дык выпилили его, и теперь в ядре множество мелких блокировок, которые более к месту, и друг с другом они пересекаются только по большой нужде.
> какая-какая команда? быть может, атомарная?а дело вкуса я атомарной оп-цией называю кучу команд которая выполняется как одна. а если одна команда - эксклюзивной.
> а дело вкуса я атомарной оп-цией называю кучу команд которая выполняется как
> одна. а если одна команда - эксклюзивной.Это не дело вкуса, а вполне определенная терминология, списывание которой на "дело вкуса" говорит о непрофессионализме списывающего, не более.
Эксклюзивный доступ - это де-факто "монопольный доступ" - не разделяемая ни с кем операция доступа к ресурсу (в нашем случае - памяти). Операция эксклюзивной быть не может. Может быть операция с эксклюзивным доступом, см. ниже.
Атомарная операция - это операция, которая выполняется единым целым, без возможности прерывания в процессе исполнения. Для реализации атомарности+эксклюзивности со многими ядрами на x86 используется префикс LOCK - эксклюзивно блокирующий на железе доступ в память для текущего ядра (в пределах одной операции). Очень дорогостоящая в тактах, к слову, вещь.
К слову говоря, в рамках современных CPU, которые микрокодовые и конвеерные, "атомарность" - весьма верное определение.
>[оверквотинг удален]
> кем операция доступа к ресурсу (в нашем случае - памяти). Операция
> эксклюзивной быть не может. Может быть операция с эксклюзивным доступом, см.
> ниже.
> Атомарная операция - это операция, которая выполняется единым целым, без возможности прерывания
> в процессе исполнения. Для реализации атомарности со многими ядрами на x86
> используется префикс LOCK - эксклюзивно блокирующий на железе доступ в память
> для текущего ядра (в пределах одной операции). Очень дорогостоящая в тактах,
> к слову, вещь.
> К слову говоря, в рамках современных CPU, которые микрокодовые и конвеерные, "атомарность"
> - весьма верное определение.тебе лишь бы по орать? сам же пишеь:
> Эксклюзивный доступ - это де-факто "монопольный доступ"
>> как еше убыстрить? ну логично применят команду блокирующую проц на фиг как
>> можно реже, а как?
> А вот так - использовать менее блокирующие механизмы. Типа RCU.у тебя любой механизм должен стопопать проц хоть раз, идея именно в том чтобы делать это реже вот концепция владения это и есть что-то типа RCU тоже надо перелопатить все ID чтобы выяснить а можноли блок снимать. - при огромном числе блокировок на поиск уйдет много времени - выход? логочно разделит блоки на категории чтоб легче искать сужая область поиска. ну корочек все любимое бинарное дерево.
> у тебя любой механизм должен стопопать проц хоть раз, идея именно в
> том чтобы делать это реже вот концепция владения это и есть
> что-то типа RCU тоже надо перелопатить все ID чтобы выяснить а
> можноли блок снимать. - при огромном числе блокировок на поиск уйдет
> много времени - выход? логочно разделит блоки на категории чтоб легче
> искать сужая область поиска. ну корочек все любимое бинарное дерево.Какие ID, какое бинарное дерево, о чём ты вообще? RCU - механизм доступа к спискам, при котором запись (C-U) не влияет на читающих (R), а для удаления требуется ожидание завершения чтения.
> Какие ID, какое бинарное дерево, о чём ты вообще? RCU - механизм
> доступа к спискам, при котором запись (C-U) не влияет на читающих
> (R), а для удаления требуется ожидание завершения чтения.ты читаь что сам пишешь? ага буду искать блокировку тупо обходя все.
> ты читаь что сам пишешь? ага буду искать блокировку тупо обходя все.Извини, но ты совершенно не понимаешь, о чём речь. Дальше дискутировать смысла не вижу.
>> ты читаь что сам пишешь? ага буду искать блокировку тупо обходя все.
> Извини, но ты совершенно не понимаешь, о чём речь. Дальше дискутировать смысла
> не вижу.я уже понял
> я уже понялНичего ты не понял. Атомарные блокировки не требуют никаких обходов, в общем случае.
>> я уже понял
> Ничего ты не понял. Атомарные блокировки не требуют никаких обходов, в общем
> случае.да лан вот горишь все неправильно во объясни простой случай - две нити 2*память и 3*память запитсать тудаже. как быть?
> да лан вот горишь все неправильно во объясни простой случай - две
> нити 2*память и 3*память запитсать тудаже. как быть?А можно по-русски. Или хотя бы по-английски? Что за 2*/3*?
И - да. Что записать? Куда записать? Зачем записать? Вид структуры, куда пишем?
>> да лан вот горишь все неправильно во объясни простой случай - две
>> нити 2*память и 3*память запитсать тудаже. как быть?
> А можно по-русски. Или хотя бы по-английски? Что за 2*/3*?да магические числа какя разнаца ? возми одна нить умнозает на 10 другая на 20 результат в память. место в памяти одно.
> да магические числа какя разнаца ? возми одна нить умнозает на 10
> другая на 20 результат в память.И зачем? Ирреал кейс.
Если необходимо, чтобы каждый тред все время умножал значение, полученное каким-либо другим тредом - то только полные блокировки (вероятно мандатные спинлоки, с сериализацией).
Если нас интересует, чтобы при этом читатели смогли работать быстро, и не критична последовательность чтения-записи - лучше всего RCU.
Читаем старое значение (входим в критическую секцию читателя RCU), умножаем, пишем новое значение отдельно, заменяем поинтер на новое значение. "Старые" читатели, которые выполняются в этот момент - видят 10, новые, которые успеют запуститься - 20.
Все отработают. После этого писатель, дождавшийсь освобождения указателя, удалит старое значение полностью. Можно даже в отдельном треде.
Но для точного приложения надо знать реальный юзкейс, а вот так "один тред - 10, другой - 20" - это слишком абстрактно.
нуда нуда
> Но для точного приложения надо знать реальный юзкейс, а вот так "один
> тред - 10, другой - 20" - это слишком абстрактно.ну че опять рассказу
создали два треда один или родительский создает id потоков или блокировки - тупа спопает проц выполняется эксклюзивно.
дале один один ппоток хватает блокировку (какой там олгоритм очереди и т.п. неважно) схватил кульно записал в нееё что это он, далее выволнил чтение из памяти и мат оп-цию
другой проток долбится на эту же блокировку но взять её не может т.к. блоком владет другой поток, первый заканчивает оп-цию и блокирову снимает, её хватает другой поток. и т.д. процессор при этом не стопается позволя работать каждому потоку "почти обычно"
> создали два треда один или родительский создает id потоков или блокировки -
> тупа спопает проц выполняется эксклюзивно.Зачем тебе ID? Такие блокировки не требуют никаких ID.
>> создали два треда один или родительский создает id потоков или блокировки -
>> тупа спопает проц выполняется эксклюзивно.
> Зачем тебе ID? Такие блокировки не требуют никаких ID.ты прикалываешь? чтобы проц не стопать один поток записал ту да что это он, а ддальше долбтится другой - ему говоря а представьтесь? он ковори я 567uhuiop - я ему в ответ ой обожите - занято и проц при это не стопают.
> ты прикалываешь? чтобы проц не стопать один поток записал ту да что
> это он, а ддальше долбтится другой - ему говоря а представьтесь?
> он ковори я 567uhuiop - я ему в ответ ой обожите
> - занято и проц при это не стопают.Это нафига, простите? Что проц не стопает? Поток останавливается. В это время могут выполняться другие потоки. Или вы считаете, что спинлок реально останавливает проц?
>> ты прикалываешь? чтобы проц не стопать один поток записал ту да что
>> это он, а ддальше долбтится другой - ему говоря а представьтесь?
>> он ковори я 567uhuiop - я ему в ответ ой обожите
>> - занято и проц при это не стопают.
> Это нафига, простите? Что проц не стопает? Поток останавливается. В это время
> могут выполняться другие потоки. Или вы считаете, что спинлок реально останавливает
> проц?конешно мининум один раз останавливает, дальше можно в цикле круть че хош.
тебе говорят даже спино должно быт как можно меньше а не через вызов.
> конешно мининум один раз останавливает, дальше можно в цикле круть че хош.Это, простите, как?
че такой тупой?
эксклюзивно впамять 5rt8hnj-90jp[m[ik] дальше постояно читаем блок который снять может тот кто знает 5rt8hnj-90jp[m[ik] осталные пробуют захватить им - скажи волшебное слово - тот в ответ ой а не знаю - ему в ответ ну постой полодумай и попробуй еще.
> че такой тупой?
> эксклюзивно впамять 5rt8hnj-90jp[m[ik] дальше постояно читаем блок который снять может
> тот кто знает 5rt8hnj-90jp[m[ik] осталные пробуют захватить им - скажи волшебноеНАХРЕНА???!!! Снять лок может только тот контекст, который знает поинтер на структуру лока, и имеет доступ к памяти структуры лока. Тчк. Какие еще "волшебные"?
Судя по всему - вы путаете клиентский API IPC-блокировок винды или еще чего с собственно механизмами блокировки. Это совершенно разные уровни работы и реализации. Те IPC-локи, о которых вы говорите, обычно реализуются в контексте лок-менеджера как раз на базе того, о чём говорю я. А судя по "ключевым словам" - точно винда...
>[оверквотинг удален]
>> эксклюзивно впамять 5rt8hnj-90jp[m[ik] дальше постояно читаем блок который снять может
>> тот кто знает 5rt8hnj-90jp[m[ik] осталные пробуют захватить им - скажи волшебное
> НАХРЕНА???!!! Снять лок может только тот контекст, который знает поинтер на структуру
> лока, и имеет доступ к памяти структуры лока. Тчк. Какие еще
> "волшебные"?
> Судя по всему - вы путаете клиентский API IPC-блокировок винды или еще
> чего с собственно механизмами блокировки. Это совершенно разные уровни работы и
> реализации. Те IPC-локи, о которых вы говорите, обычно реализуются в контексте
> лок-менеджера как раз на базе того, о чём говорю я. А
> судя по "ключевым словам" - точно винда...нуда.... а поинтер на роль "канаречного слова" не катит, только тогда а ели в другой лок попал?
> нуда.... а поинтер на роль "канаречного слова" не катит, только тогда
> а ели в другой лок попал?Что такое "если"? Никаких "если" быть не может - такие "если" - это ошибка программирования. На нижнем уровне лок однозначно идентифицируется поинтером на структуру лока, безо всяких "если".
>> нуда.... а поинтер на роль "канаречного слова" не катит, только тогда
>> а ели в другой лок попал?
> Что такое "если"? Никаких "если" быть не может - такие "если" -
> это ошибка программирования. На нижнем уровне лок однозначно идентифицируется поинтером
> на структуру лока, безо всяких "если".а почему "если" не катит? на роль блока предлагагал пожизненно процессор стопать - пипа чтоб никто не мог тогда нада чета лепить в ответ что "не знаю" например 0.
> а почему "если" не катит? на роль блока предлагагал пожизненно процессор стопать
> - пипа чтоб никто не мог тогда нада чета лепить в
> ответ что "не знаю" например 0.nagual, залогинься
зачем в юзерских приложениях стопать проц, если достаточно стопнуть тред?
в случае кода ядра Linux всё хитрее - там такого понятия, как тред, нет в принципе, и поэтому реально может стопнуться целое ядро проца - а посему в ядре от спинлоков усиленно избавляются
в случае BSD, как уже говорил, вариантов не особо...
>> а почему "если" не катит? на роль блока предлагагал пожизненно процессор стопать
>> - пипа чтоб никто не мог тогда нада чета лепить в
>> ответ что "не знаю" например 0.
> nagual, залогинься
> зачем в юзерских приложениях стопать проц, если достаточно стопнуть тред?
> в случае ядра Linux всё хитрее - там тредов нет, и поэтому
> реально может стопнуться целое ядро проца - поэтому в ядре от
> спинлоков усиленно избавляютсяя не втеме как это в линукс называется, да же во фре не теме. для того чтобы писать потоки этого ненада сказал хватай и всё.
> я не втеме как это в линукс называется, да же во фре
> не теме. для того чтобы писать потоки этого ненада сказал хватай
> и всё.xD ну вот, еще один признался
раз совершенно не в теме - чего лезешь?
> тред, нет в принципе, и поэтому реально может стопнуться целое ядростопаеся проц для обеспечения целостности про "стопнуться целое ядро " это в другом месте затирай.
> стопаеся проц для обеспечения целостности про "стопнуться целое ядро " это в
> другом месте затирай.слушай - если не догоняешь - либо проси объяснить вкратце, либо не лезь. развелось недоспециалистов, блин... зато все с гонором...
о боже....как может стопнуца ядоро целиком? по-моему только остановить проц, или че оно в один поток его прижал и в дамках?
> как может стопнуца ядоро целиком? по-моему только остановить проц, или че оно
> в один поток его прижал и в дамках?прикинь, каждое ядро выполняет код независимо xD
и "стопается" исполнение полностью только на время выполнения команды с префиксом LOCK, а не на время ожидания спинлока, и то только в том случае, если адресуется один и тот же адрес :)в случае ядра Linux/BSD - на время ожидания спинлока в ядре ОС замрёт всё ядро CPU (за исключением возникновения прерываний, если не заблокированы), остальные ядра продолжат исполнять код
в случае пользовательского приложения, ждущего неядерный спинлок, вообще ничего не произойдёт - поток будет сидеть в idle
> как может стопнуца ядоро целиком? по-моему только остановить проц, или че оно
> в один поток его прижал и в дамках?кста в тему а что если прерывание пришло? че делать выполнят обработчик или забить? всеструктуры ядра вроде как в блоке "ядерном" :).
> кста в тему а что если прерывание пришло? че делать выполнят обработчик
> или забить? всеструктуры ядра вроде как в блоке "ядерном" :).вот тут уже будет зависеть от того - выключены прерывания или включены
если включены - произойдёт переход в обработчик прерывания. если по несчастью он захочет одного из занятых локов - всё, будет дэдлок в пределах ядра проца (фатальная, в общем-то, ситуация)...
именно поэтому в ядре тех же линухов существуют разные варианты спинлоков - с блокировкой IRQ или без
ну не все заблокировано без "если" а это сетевка буфер переполнится и данные пропадут - нада быро в зад за новой порцией ну карта тупая без dma.
> ну не все заблокировано без "если" а это сетевка буфер переполнится и
> данные пропадут - нада быро в зад за новой порцией ну
> карта тупая без dma.не все ядерные спинлоки требуют блокировки прерываний. если мы знаем, что в обработчике прерывания данный лок не понадобится с вероятностью 101% (1% добавлен для исключения самоуверенности пишущего код :), то мы можем смело использовать лок с включенными прерываниями. контекст свитчинг в ядре внутри спинлоков выключается
кроме того - как уже обсуждали - общая рекомендация по любым исключительным блокировкам - минимальное время просиживания в оных. либо уход от оных на другие механизмы сериализации
>> ну не все заблокировано без "если" а это сетевка буфер переполнится и
>> данные пропадут - нада быро в зад за новой порцией ну
>> карта тупая без dma.
> не все ядерные спинлоки требуют блокировки прерываний. если мы знаем, что в
> обработчике прерывания данный лок не понадобится с вероятностью 101% (1% добавлен
> для исключения самоуверенности пишущего код :), то мы можем смело использовать
> лок с включенными прерываниями. контекст свитчинг в ядре внутри спинлоков выключается
> кроме того - как уже обсуждали - общая рекомендация по любым исключительным
> блокировкам - минимальное время просиживания в оных. либо уход от оных
> на другие механизмыво начианаешь понимать почему один блок на всё плохо? мы все структуры ядра заблокировали на "почесаться" а могут происходит процессы которые тоже внимания требуют, и без оного могут терять данные, без относительно что разрешал ты прерывания или нет. ну короче в этом суть, но блин а что если прерывания не запрешал и оно произошло? круто а нужен тод же ресурс? причем казалось просто востанови данные а если востановить затратно? тоже чначит частить не надо.
> во начианаешь понимать почему один блок на всё плохо?А где я предлагал "один блок на всё"? Вроде бы склерозом и маразмом не страдаю...
> мы все структуры ядра заблокировали на "почесаться"
"Мы" - так не делаем.
> не хочу подливать, конечно, но с параллелизмом у BSD "баааааааальшие проблемы"Это после того, как FreeBSD 7.x с новым планировщиком ULE3 обогнала Linux на многоядерных системах? Да, знатный был срач. Но линаксоеды подсуетились: что же это они с BKL будут сидеть, когда у бздишнегов полным ходом уже шла работа по выпиливанию GIANT LOCK?
Навалились всем миром, выкатили несколько планировщиков, но... на десктопах вдруг появился пресловутый Bug #12309 — злосчастный баг заморозки "Рабочего стола" убунтухомячка при интенсивном I/O и такой же неуловимый, как ковбой Джо. http://www.linux.org.ru/forum/linux-hardware/4893907
#12309 - больше проблема дискового контроллера и шин, нежели ядра. В виндах тоже проявляется на 82801 сполна. Да и BSD, имхо, будет, если бы юзали...
> #12309 - больше проблема дискового контроллера и шин, нежели ядра. В виндах
> тоже проявляется на 82801 сполна. Да и BSD, имхо, будет, если
> бы юзали...:) т.е. ты с ней сталкиваешься на пример на многоядерной UP машине? представь себе
на там 6 ядер.FreeBSD tt 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #2: Fri Aug 24 13:33:03 MSK 2012 root@tt:/usr/obj/usr/src/sys/my amd64
не проявляется. и вобще не надо аналогии проводить с хренью на 1024 процесора по 16 ядер со свои м домашним компом.
> не проявляется. и вобще не надо аналогии проводить с хренью на 1024
> процесора по 16 ядер со свои м домашним компом.А ты прочитай, о чём чудик выше пишет, и пойми, к чему я это.
На пресловутых 1024*16 не проявится с высокой долей вероятности, там совершенно другие узкие места, да и железо другое совершенно.
#12309 вообще - это страшилка для хомячков, на нормальном серверном железе - не сталкивался.
а ты чудик прочитай внимательней - ПРОЯВЛЯЕТСЯ.
> а ты чудик прочитай внимательней - ПРОЯВЛЯЕТСЯ.На 16к ядер? xD Пруфлинк будет, или снова в лужу пёрнул не подумав?
>> а ты чудик прочитай внимательней - ПРОЯВЛЯЕТСЯ.
> На 16к ядер? xD Пруфлинк будет, или снова в лужу пёрнул не
> подумав?:) 16к - если я так сказал - опечатался, я какраз тер о том, что это исключение а не правило. ктому же это кернел орг говоришь на фре есть? я найти не могу ищи сам если тебе это надо.
я хотел сказать что в системе с одним 6-ядерным процессором у меня всё хорошо, а что там на 16к ядрах меня не сношает.
как всегда всё потерел - где о чем трепался - но вобще вы будете удивлены но вот как думат один из разрабов:http://blogerator.ru/page/freebsd-core-team-interview-2
ключевое от треде касательно темы:
И ещё, сюда же: у FreeBSD нет поддержки NUMA, это правда? Если нету — причины?
Нет, в том смысле, что нет специального allocator’ a, который бы пытался активно угадывать будущее. В HEAD появился примитивный NUMA-aware allocator, который, насколько я понимаю, пытается выделить страницу на той ноде, на которой выполняется нитка. К сожалению, — от него больше вреда, чем пользы.
Что касается NUMA вообще, то правильно подобранный benchmark может показать, по-моему, 2-х кратное превосходство NUMA-aware планировщика и allocator’ a. В реальных же нагрузках, на обычных x86 SMP машинах, поверьте, вся разница теряется в погрешностях измерений.
........................
Хорошо, теперь давайте сыграем наоборот. В чем сейчас FreeBSD 8 технологически и объективно очень сильна по сравнению с другими ОС?Сейчас «ядро» в очень хорошем состоянии, глубоко отлажено и содержит массу очень правильных и продвинутых архитектурных решений. Как частные примеры, можно упомянуть interrupt threads, крайне малое количество spinlock'ов в системе (это все предмет ещё предстоящих RT-патчей для Linux’a, по крайней мере я об этом читал).
........................
ну и кстати мне еще никто не объясни чем плохи локи на ыьз система толкоо ненадо гнать, про мУльЁн процов.
> локи на ыьзспин локи на smp.
>линаксоедыНеплохо. Еще аватарку надо где мужественный гордый отважный дьяволенок трахает Тукса. Давай, поднатужся, еще немного усилий и гениальная но посему то не понятая быдлом FreeBSD завоюет этот мир.
> же это они с BKL будут сидеть, когда у бздишнегов полным
> ходом уже шла работа по выпиливанию GIANT LOCK?FYI, к тому времени BKL был только в TTY'ях.
>> же это они с BKL будут сидеть, когда у бздишнегов полным
>> ходом уже шла работа по выпиливанию GIANT LOCK?
> FYI, к тому времени BKL был только в TTY'ях.о да... u32 не держит в TTY'ях
> BKLВы бы хоть изучили вопрос, прежде чем так изя-щно вляпываться.
http://kernelnewbies.org/BigKernelLock
PS: выпиливать BKL из линукса начали уже не помню точно, когда -- в 2.2 или 2.4, что ли.
>> BKL
> Вы бы хоть изучили вопрос, прежде чем так изя-щно вляпываться.
> http://kernelnewbies.org/BigKernelLockBKL "безвозвратно удалён" в мае 2011 года в ядре Linux 2.6.39.
> PS: выпиливать BKL из линукса начали уже не помню точно, когда -- в 2.2 или 2.4, что ли.
Начали, да что-то туго продолжили, если Ingo Molnar за три года до "безвозвратного удаления" основательно принялся за дело. ;)
> BKL "безвозвратно удалён" в мае 2011 года в ядре Linux 2.6.39.Еще раз: где-то с 2006 года начиная, он оставался только в минорных подсистемах, типа TTY и NFS. Плюс огромная работа проделана по переводу сетевого стека и некоторых других подсистем со спинлоков на RCU. Идет уже 3-4 года тоже, и конца и края пока еще не видно. В BSD её даже не начинали.
> пресловутый Bug #12309 — злосчастный баг заморозки "Рабочего стола" убунтухомячкаНи на старом athlon64 не наблюдал, ни на новом core-i7 3770k.
Сомневаюсь что изень наблюдал. Потому что класический бздун. Я то хоть с фряхой работал несколько лет, а этот теоретик линукс только в анонсах видит и новостях.
> Ни на старом athlon64 не наблюдал, ни на новом core-i7 3770k.Я, похоже, наблюдал на X61t и флэшке.
это ошибка, не вникая в детали, называть софт внутри такого железа линуксом.то, что там внутри, иногда может быть похоже на линукс, как медуза на черепаху. пооследний раз, как я проверял, ОС на вычислительных узлах бимеровского блюджина, который, если верить всем восторженным изданиям, бежит линукс, не имела таких мелочей, как MMU и диспетчер задач.
> это ошибка, не вникая в детали, называть софт внутри такого железа линуксомОшибка - считать это не линуксом. Ядро - думается, что почти ванильное. На раздаче - запросто OpenMP и свои собственные компоненты.
>> это ошибка, не вникая в детали, называть софт внутри такого железа линуксом
> Ошибка - считать это не линуксом. Ядро - думается, что почти ванильное.
> На раздаче - запросто OpenMP и свои собственные компоненты.вы внимательно прочли то, что я написал? вы правда считаете, что ядро без виртуальной памяти и диспетчера "почти ванильное"?
то, что я читал про ядро вычузлов в блюджине - описывалось ядро заточенное под выполнение одной задачи со статической памятью.
при чем тут openmp вообще?
> то, что я читал про ядро вычузлов в блюджине - описывалось ядро
> заточенное под выполнение одной задачи со статической памятью.Это единичные решения.
> при чем тут openmp вообще?
При том, что это де-факто стандарт для кластеров.
MPI вообще-то, а OpenMP костыль и вообще отдалённое отношение имеет к топику.
> MPI вообще-то, а OpenMP костыль и вообще отдалённое отношение имеет к топику.Да, прошу прощения, перепутал. MPI.
Но тем не менее, CLE (который как раз на Titan в роли RTE) - умеет и официально поддержвает как MPI, так и OpenMP.
> так и OpenMP.Как такое возможно? Оно ж не видит распределённых процов и памяти.
Разве что компилятор хитро превращает MP в MPI. Но с производительностью тогда - пальцем в небо.
>> то, что я читал про ядро вычузлов в блюджине - описывалось ядро
>> заточенное под выполнение одной задачи со статической памятью.
> Это единичные решения.мы говорим о списке, в котором _любая_ система "единичное решение". и блюджинов там 15 штук в первой сотне. и это уже не первый год.
>> при чем тут openmp вообще?
> При том, что это де-факто стандарт для кластеров.я вам за ядро, которое не есть линукс, а вы мне за линуксовый юзерленд. беседа начинает напоминать разговор тунгуса с эфиопом.
Если я у велосипеда оторву багажник или даже руль, он перестанет быть велосипедом и превратится в самолет? Ядра rhel очень сильно отличаются от ванильных - это делает rhel не линуксом? Ядра в embed очень далеки от ядра на десктопе, но это по прежнему линукс. Аналогично с суперкомпьютерами, за основу взят линукс, не ядро бзди или винды, а линукс. После всех обрезаний и допиливаний все равно остается линукс.
конечно он перестанет им быть если ты сказжеь ввиду усовершенствования "А" педали и колёса больше не нужны.
> конечно он перестанет им быть если ты сказжеь ввиду усовершенствования "А" педали
> и колёса больше не нужны.Предлагаешь к орбитальной станции прикрутить педали с колесами? Напуркуа они ей?
// тьфу ты, и "Мир" тоже утонул :(
во... начинаешь понимать это разные вещи и служат разным целям.
> во... начинаешь понимать это разные вещи и служат разным целям.Нет, это ты перестаешь понимать. Есть модульное ядро - от которого можно открутить одно, и прикрутить другое. Эдакий трансформер. Это лучше станции - хочешь - по дороге, хочешь - в атмосфере, хочешь - за пределами. Любая специфика, а начинка - одна и та же, только в разной комбинации.
Я тебе поближе пример из жизни приведу, раз уж трудно с осознанием:
Есть x86 с огромной блобятиной ядра на несколько метров в памяти и многими метрами обвязки. А есть маленький сохошный роутер на MIPS, с ядрышком в 300-400 КБ и бизибоксом, всё это спокойно вмещается в два метра флеша. Совершенно разные классы применения - собственно мотоцикл и самолёт, а ядро - одно - Linux. И прекрасно масштабируется хоть на MIPS с одним ядром, хоть на x86 с вагоном ядер. Функциональность почти та же.А есть еще Tilera с 48-64 ядрами, на которой крутится всё то же ядро Linux, слегка допиленное и подрихтованное под специфику проца. Но Linux'ом оно от этого быть не перестало.
не гони пургу можно конечно спроектировать "швейцарский нож" на 30000 инструментов, был у меня похожий - с пасатижами, но когда у меня есть пасатижи - в мыслях нибудет найти эту хрень
> не гони пургу можно конечно спроектировать "швейцарский нож" на 30000 инструментов, был
> у меня похожий - с пасатижами, но когда у меня есть
> пасатижи - в мыслях нибудет найти эту хреньА ты спроектируй разборный швейцарский нож, от которого при желании можно оставить только собственно нож и отвертку, а при желании - все 30000 фич прикрутить. И тогда - хочешь дома, хочешь в походе, хочешь на производстве - тебе будет удобно. Вот только в материальном мире такие вещи чуток сложнее, чем в алгоритмическом.
Ядро Linux этой своей универсальностью и выиграло - оно одно для всего, с единой "ручкой" для применения.
бугага, слилсоа теперь подумай: ты что предпочтешь - смартфон, или комплект из: телефона (тупого телефона, без всего, кроме звонилки), записной книжки в кармане, GPS-навигатора, КПК для документов и интернета, Playstation Portable для игр, и еще горы кабелей для связи всего этого между собой?
то-то и оно, что смартфон. при желании даже можно найти смартфон без GPS, или без поддержки навороченных игр - но он от этого смартфоном быть не перестанет. и платформа внутри с вероятностью 70-80% ныне уже будет одна и та же :) - легко масштабирующаяся на весь класс устройств.
> не проше не пытаться обьять необятное и зделать _что-то типа_ андройда, опенврт, федориногоКоря и т.п.Еще проще вообще ничего не делать, с шаблонным ответом "нет ресурсов"...
>[оверквотинг удален]
> Есть x86 с огромной блобятиной ядра на несколько метров в памяти и
> многими метрами обвязки. А есть маленький сохошный роутер на MIPS, с
> ядрышком в 300-400 КБ и бизибоксом, всё это спокойно вмещается в
> два метра флеша. Совершенно разные классы применения - собственно мотоцикл и
> самолёт, а ядро - одно - Linux. И прекрасно масштабируется хоть
> на MIPS с одним ядром, хоть на x86 с вагоном ядер.
> Функциональность почти та же.
> А есть еще Tilera с 48-64 ядрами, на которой крутится всё то
> же ядро Linux, слегка допиленное и подрихтованное под специфику проца. Но
> Linux'ом оно от этого быть не перестало.вместо того, чтобы приводить дивные аналогии, лучше почитайте доки, вот, например http://www.redbooks.ibm.com/abstracts/redp4453.html?Open в которых ясно описано где какие ядра применяются. это правда интереснее, чем болтать ерундой.
> Если я у велосипеда оторву багажник или даже руль, он перестанет быть
> велосипедом и превратится в самолет? Ядра rhel очень сильно отличаются от
> ванильных - это делает rhel не линуксом? Ядра в embed очень
> далеки от ядра на десктопе, но это по прежнему линукс. Аналогично
> с суперкомпьютерами, за основу взят линукс, не ядро бзди или винды,
> а линукс. После всех обрезаний и допиливаний все равно остается линукс.вы не можете в аналогии. серьезно.
извините, если задел ваши религиозные чувства.
> это ошибка, не вникая в детали, называть софт внутри такого железа линуксом.
> то, что там внутри, иногда может быть похоже на линукс, как медуза
> на черепаху.Вы ошибаетесь.
>> это ошибка, не вникая в детали, называть софт внутри такого железа линуксом.
>> то, что там внутри, иногда может быть похоже на линукс, как медуза
>> на черепаху.
> Вы ошибаетесь.*устало* вы тоже хотите рассказать мне, что ядро, в котором нет, например, fork(), mmap(), read() и write() - является таким себе "модульным линуксом"?
>>> это ошибка, не вникая в детали, называть софт внутри такого железа линуксом.
>>> то, что там внутри, иногда может быть похоже на линукс, как медуза
>>> на черепаху.
>> Вы ошибаетесь.
> *устало* вы тоже хотите рассказать мне, что ядро, в котором нет, например,
> fork(), mmap(), read() и write() - является таким себе "модульным линуксом"?Я могу рассказать вам, как делается дистрибутив для кластера из топ-500. Но это будет вам стоить дорого - без обид, но "на шару" не выйдет.
>> *устало* вы тоже хотите рассказать мне, что ядро, в котором нет, например,
>> fork(), mmap(), read() и write() - является таким себе "модульным линуксом"?
> Я могу рассказать вам, как делается дистрибутив для кластера из топ-500. Но
> это будет вам стоить дорого - без обид, но "на шару"
> не выйдет.а бесплатно рассказать, почему бимеровское CNK ядро для блюджина является линуксом, можете? ну или хотя бы пальчиком показать, чтобы я уже успокоился?
> а бесплатно рассказать, почему бимеровское CNK ядро для блюджина является линуксомДумаю, это про #define linux
PS: полухинт: а ядро вообще без свопа (не хост, а ядро) -- линукс? :)
>> а бесплатно рассказать, почему бимеровское CNK ядро для блюджина является линуксом
> Думаю, это про #define linux
> PS: полухинт: а ядро вообще без свопа (не хост, а ядро) --
> линукс? :)"Папа, а наша кошка тоже еврей?" (с)
вот мне тоже интересно. Сколько я помню, в CNK виртуальной памяти нет, диспетчера нет, реализовано с полсотни посиксовых сисколлов и 20 своих собственных, I/O нет, эти сисколлы через хитрую шину перебрасывается на I/O ноды и выполняются оттуда. это считается за "почти ванильный" линукс?
Нет, это считается за линукс, а не за "почти ванильный линукс". Могу предположить, что ООП ты тоже не понимаешь.
> Нет, это считается за линукс, а не за "почти ванильный линукс". Могу
> предположить, что ООП ты тоже не понимаешь.о, еще один. в очередь, сукины дети, в очередь.
кто еще хочет объяснить мне, что написанный IBM с нуля миникернел - ЕТА ЛИНУКС?
PS ведь написал же в начале треда: "это ошибка, не вникая в детали, называть софт внутри такого железа линуксом." нет, мыши будут плакать, колоться, но пока весь кактус не сожрут не успокоятся. Пойти выяснить, что это такое ни один не пойдет.
> вот мне тоже интересно. Сколько я помню, в CNK виртуальной памяти нет,
> диспетчера нет, реализовано с полсотни посиксовых сисколлов и 20 своих собственных,
> I/O нет, эти сисколлы через хитрую шину перебрасывается на I/O ноды
> и выполняются оттуда. это считается за "почти ванильный" линукс?ИБМ вроде бы называет ее линукс-подобной проприетарной ОС.
>> вот мне тоже интересно. Сколько я помню, в CNK виртуальной памяти нет,
>> диспетчера нет, реализовано с полсотни посиксовых сисколлов и 20 своих собственных,
>> I/O нет, эти сисколлы через хитрую шину перебрасывается на I/O ноды
>> и выполняются оттуда. это считается за "почти ванильный" линукс?
> ИБМ вроде бы называет ее линукс-подобной проприетарной ОС.ну правильно, сейчас же любое ядро реализующее сотню POSIX коллов, немедленно становится линуксоподобным ггг
там на самом деле отдельные образы на всякие случаи жизни.
сервис и I/O узлы RHEL заточенный под блюджин
вычислительные узлы - миниядро, написанное бимерами с нуля, несколько тысяч LOC, которое умеет только запустить один тред на ядро, нарезать ему памяти, прокидывать на I/O узлы I/O сисколлы - и больше не мешается под ногами.если машинного времени не жалко или программа жить не может без плюшек типа много-много тредов, динамической линковки или шелл-скриптов, тогда грузится имидж I/O узла, и имеем почти настоящую машину с редхатом на борту, и соответственно большим оверхедом.
у бсди дерьмовый юзерспейс, не для людей он сделан
> у бсди дерьмовый юзерспейс, не для людей он сделан:) это пипа шута - смтри собщение 61.
В опрвданиях "почему почти бздей нет в топ500" нодобздишнегов больше, чем во взломе фряхи...
Забавно.
> В опрвданиях "почему почти бздей нет в топ500" нодобздишнегов больше, чем во
> взломе фряхи...
> Забавно.а разве надо за это оправдоватся? че хоть какая-нибуть BSD позиционирует себя как ось для супер компов?
а что там использовали в качестве базы - мне пофиг.
> В опрвданиях "почему почти бздей нет в топ500"Почему "Почти"? БЗДи вообще нет, 1 штука не считается,
это даже меньше чем статистическая погрешность!
И ваще, фриБЗДя - это тренажёр для студентов Беркли,
они на нем свои курсовые отрабатывают.Если уж смотреть на BSD как на что-то способное, так это на NetBSD
---
Кстати, почему нет суперпроцессоров от Оракала,
которые все такие супер-пупер-много-поточно-ядерные?!
> Кстати, почему нет суперпроцессоров от Оракала,
> которые все такие супер-пупер-много-поточно-ядерные?!их хозяева от IRS шифруются, им не до славы ггг