Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Microsoft added fibers to Windows to make it easy to port existing UNIX server applications to Windows. UNIX server applications are single-threaded (by the Windows definition) but can serve multiple clients. In other words, the developers of UNIX applications have created their own threading architecture library, which they use to simulate pure threads. This threading package creates multiple stacks, saves certain CPU registers, and switches among them to service the client requests.
Pzz>О как. Интересно, где это они нашли для UNIX'а такую threading library, и серверные аппликации, на ней написаные, которые имеет смысл "make it easy to port"?
Pzz>Все-таки по-моему у виндовсных людей UNIX — это такая легенда, типа лешего, который живет (или жил когда-то) в лесу, и про него столько же примерно известно.
Сказать аналогичное про юниксоидов несложно. Вот только зачем?
Меня всегда удивляли заявления "виндузятники — не люди, а лемминги" и "юниксоиды — задроты". Этакие обобщения с нескольких встреченных особей на всех. Господа, смею напомнить, в общем случае, индукция — не метод доказательства.
Здравствуйте, Aen Sidhe, Вы писали:
AS>Меня всегда удивляли заявления "виндузятники — не люди, а лемминги" и "юниксоиды — задроты". Этакие обобщения с нескольких встреченных особей на всех. Господа, смею напомнить, в общем случае, индукция — не метод доказательства.
Я не сказал, что виндузятники лемминги. Я сказал, что виндузятники мало чего знают про UNIX.
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, Aen Sidhe, Вы писали:
AS>>Меня всегда удивляли заявления "виндузятники — не люди, а лемминги" и "юниксоиды — задроты". Этакие обобщения с нескольких встреченных особей на всех. Господа, смею напомнить, в общем случае, индукция — не метод доказательства.
Pzz>Я не сказал, что виндузятники лемминги. Я сказал, что виндузятники мало чего знают про UNIX.
А я сказал, что индукция — неверный способ доказательства.
И, да, я не говорил, что ты сказал, что виндузятники — лемминги. Я сказал, что такие заявления существуют. Поиском по форуму вполне находятся.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Ну-ну. Предложи разработчиками Windows заменить потоки в процессе System на файберы. То-то весело будет
Видишь ли Павел... Напомню тебе, что речь у вас шла об эффективности. И здесь Антон абсолютно прав, конкурентная многозадачность показывает существенно большую эффективность, чем вытесняющая.
В Windows планировщик вытесняющий не потому что он производительнее, а потому, что это безопаснее. При вытесняющей многозадачности у неправильно написанного кода меньше шансов уронить все приложение, вместе с OS, и исключительно по этой причине в OS реализована именно она. То есть, производительность приносится в жертву безопастности, как раз тот расклад, который тебе так не нравится.
В тех же случаях, когда безопасность можно обеспечить каким-либо другим способом, например, когда заранее известно все множество возможных операций и можно гарантировать, что никакая комбинация этих операций не приведет к зависаню всего приложения, включая планировщик, кооперативная многозадачность демонстрирует себя во всей красе. Характерные примеры Антон как раз и привел — lightttpd, SQL Server.
MS SQL Server — вообще, классический пример. Там внутри реализована практически полноценная операционка для управления нагрузкой, собственно, эта часть сиквельного движка так и называется — SQL OS, и одна из основных задач этой OS, обеспечивать non-preemptive schedulind. Опять-таки, ты же любишь ссылаться на операционки? Вот тебе пример OS с кооперативной многозадачностью, как раз из тех соображений, чтобы выжать максимум производительности.
PD>Читать классиков надо. Вдумчиво, не спеша. С толком, с расстановкой.
Так вот Павел, не торопись и задумайся, из каких соображений они дают именно такие советы.
Здравствуйте, Pzz, Вы писали:
Pzz>О как. Интересно, где это они нашли для UNIX'а такую threading library, и серверные аппликации, на ней написаные, которые имеет смысл "make it easy to port"?
Здравствуйте, AndrewVK, Вы писали:
Pzz>>О как. Интересно, где это они нашли для UNIX'а такую threading library, и серверные аппликации, на ней написаные, которые имеет смысл "make it easy to port"?
AVK>http://en.wikipedia.org/wiki/Setcontext
В унихе есть, конечно, загадочный API. Но я не слышал ни об одной полезной программе, которая им бы пользовалась. Впрочем, возможно что мне просто повезло.
Вообще, POSIX threads существуют уже давно, и их модель мира примерно такая же, как у вендовых потоков. Под капотом они могут использовать ручное переключение контекстов полностью в user space, полностью полагаться на ядро или использовать смешанную модель, но если программа корректно использует примитивы синхронизации, ей должно быть все равно. Ранние имплементации обходились без помощи ядра, но по-моему рост популярности посиксных потоков как раз совпал с появлением и широким распостранением соответствующей поддержки в ядре.
Кроме того, если кому уж очень приперло сэмулировать в венде setcontext, то сделать это несложно и безо всяких фиберов.
В общем, я думаю, фиберы в венду попали не для эмуляции setcontext/getcontext. А как альтернатива потокам, которая 1) дешевая 2) с ручным управлением, что бывает удобно — не обязательно защищаться критическими секциями.
Здравствуйте, IB, Вы писали:
IB>В Windows планировщик вытесняющий не потому что он производительнее, а потому, что это безопаснее. При вытесняющей многозадачности у неправильно написанного кода меньше шансов уронить все приложение, вместе с OS, и исключительно по этой причине в OS реализована именно она. То есть, производительность приносится в жертву безопастности, как раз тот расклад, который тебе так не нравится.
Гм... Вообще-то шансы уронить ОС (насчет того, чтобы уронить приложение , промолчу — это не так уж сложно сделать при обоих видах многозадачности определяются не тем, какая многозадачность, а тем, отделен ли код ядра от кода пользователя. В корректно написанной системе шансы нулевые, независимо от того, какая тут многозадачность. Я, признаться, никак не вижу связи между тем, как приложения (потоки и т.д.) уступают друг другу процессор и защищенностью OS. Более того, ИМХО кооперативная модель является более защищенной, так как передача управления происходит в строго фиксированных местах, а не где угодно.
И второй момент. Кооперативная многозадачность в Windows ведь была, 3.1. Но в NT от нее полностью отказались. И дело тут не в Windows. И OS IBM/360-370 всех сортов, и RT-11 — RSX-11, и VAX VMS, и другие OS — используют именно вытесняющую многозадачность. Я вообще до Windows 3.x о кооперативной мультизадачности не слышал, а узнав — был, просто скажу, удивлен. Кто-то, кстати, назвал ее "решением для бедных".
Видишь ли, суть проблемы в том, что мы о разных вещах говорим. Если внутри MS SQL и есть некая псевдо- OS, и если эта псевдо-OS работает именно так, как я сказал — это означает, что для тех задач, которые там решаются, авторы признали кооперативную мультизадачность лучшим решением. Причин для этого может быть много. Но все же это не OS, а лишь приложение, хоть и сколь угодно сложное. В настоящей ОС твое требование "например, когда заранее известно все множество возможных операций и можно гарантировать, что никакая комбинация этих операций не приведет к зависаню всего приложения, включая планировщик" — просто вряд ли выполнимо.
То, что кооперативная мультизадачность может быть эффективнее — согласен, в общем-то, я тут погорячился. Но только для определенного круга задач. В общем случае нет.
Блин, я вас читал-читал, а как все банально заканчивается
Понятно, что не все на свете задачи можно решить с помощью дотнета — хотя бы потому, что не везде этот самый дотнет "влезет". Но разве вы об этом спорили?
Правда жизни в том, что таких задач становится все меньше и меньше. Вон, помнится, была статья — причем год или два назад — даже луноход какой-то под управлением джавы работал. Все-таки сейчас немного меняются представления о производительности, оптимизации и пр.
Сейчас в большинстве случаев не надо байты и тики считать — приложения тормозят не потому что какой-то алгоритм на си-шарпе написан, а не асме, а из-за кривой архитектуры. Что в осном народ-то пишет? Бизнес-приложения, распределенные приложения, всякие там корпоративные шины и проч., веб-сервисы и другую подобную дрянь. Там совсем другие проблемы возникают, на другом уровне. Если, к примеру, у тебя плохо продумана связь с каким-нибудь нодом, идет слишком частый обмен пакетами, некорректно обрабатывается таймаут нода, нет кэширования и пр. — тебе тут не поможет переделка твоего приложения на более низкоуровневый асм.
А теперь представь — вот люди пишут всякие ESB, передают тонны ХМЛя (ХМЛя, понимаешь? ), а ты их пытаешься убедить, что "существуют задачи, для решения которых использование высокоуровневых средств... неэффективно и нецелесообразно". Как на фиг высокоуровневые средства, у нас сплошной ХМЛ, блин
И в итоге чего ты хочешь добиться? Никто не отрицает, что в принципе да, есть задачи для которых подходят более низкоуровневые средства. Но вы разве это обсуждаете? Статистику использования технологий что ли составляете? Речь-то о перспективах, о развитии, о тенденциях. И тенденция такова, что таких задач становится все меньше. Гораздно меньше. Причем в тех областях, в которых использования какого-нибудь дотнета раньше даже помыслить было нельзя.
И будет еще меньше. Сейчас у банальной игровой приставки — под которую игры выпускают, кстати, в "обрезанном" по сравнению с PC варианте — прозводительность терафлопами мерится. О чем тут можно говорить-то? Какой асм?
Собственно, такова позиция твоих оппонентов, как я ее понимаю. И я с ней согласен. А вот твою позицию я не очень понимаю. Какой смысл все сводить к тому, что "есть задачи для к-х асм подходит"? Ну да, пока еще есть. Но мне действительно кажется, что ты переоцениваешь роль и количество таких задач. Им недолго осталось жить. Через пять-десят лет китайская кофеварка с многоядерным процессором производительностью в несколько терафлоп будет доставать мне из интернета рецепты кофе. Это реальность
А я понимаю эту дискуссию несколько иначе.
Оппоненты Дворкина утверждают, что высокоуровневый код вроде такого:
[1 .. 5]
легче оптимизировать, чем низкоуровневый код вроде такого:
+>++>+++>++++>+++++<<<<
потому, что семантика в высокоуровневом коде явно выражена. В первом случае, например, мы (и компилятор) видим последовательность чисел от 1 до 5и, во втором же случае за деревьями перемещений ленты и инкрементов не видно леса.
... << RSDN@Home 1.2.0 alpha 4 rev. 1110>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
По поводу оптимизации мне кажется интереснее пример, к-й Sinclair приводил. Переписали приложение на Java/MSSQL, и оно заработало быстрее, чем на более низкоуровневом С++. Выбор правильной архитектуры гораздо важнее того, насколько оптимально реализованы отдельные ее части.
А так — высокоуровневый код во всех в смыслах писать и поддерживать проще. И гораздо дешевле. Более того, многие современные системы практически невозможно писать на "низком уровне", потому что это выльется в такие сотни тысяч человекочасов — даже если речь идет просто о разработке — что окажется в принципе неподъемным.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>А так — высокоуровневый код во всех в смыслах писать и поддерживать проще. И гораздо дешевле. Более того, многие современные системы практически невозможно писать на "низком уровне", потому что это выльется в такие сотни тысяч человекочасов — даже если речь идет просто о разработке — что окажется в принципе неподъемным.
Ну так то, что высокоуровневость дает выигрыш при написании и поддержке — давно общепринято. Обсуждается то, что помимо abstraction penalty есть еще и abstraction gains, когда речь идет о производительности приложения. Дворкин же считает, что есть только penalty.
... << RSDN@Home 1.2.0 alpha 4 rev. 1110>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Klapaucius, Вы писали:
K>Ну так то, что высокоуровневость дает выигрыш при написании и поддержке — давно общепринято. Обсуждается то, что помимо abstraction penalty есть еще и abstraction gains, когда речь идет о производительности приложения. Дворкин же считает, что есть только penalty.
Abstraction gain — в сущности всегда один — код более высокоуровневый, оперируется более высокоуровневыми понятиями, соответственно, в него проще "въехать" и как результат проще поддерживать. Это как раз и есть то, что "общепринято".
На это, конечно, всегда можно возразить, что я типа насколько глубоко разбираюсь в Х, что мне не нужен дополнительный уровень абстракции, чтобы я мог легко оптимизировать код на Х.
Теоретически это может быть правдой (если представить себе человека с таким имплантом в мозгах... в Систем Шок не играли? ) — потому что по факту дополнительные уровни абстракции неизбежно вносят оверхед, тут спорить нечего.
Но на практике имплантов для мозгов еще не изобрели Более того ИМХО на практике большинство оптимизаций ограничится изменением архитектуры, даже без вникания в то, что собственно происходит внутри методов (что косвенно и подводит нас к изначальной теме топика).
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Теоретически это может быть правдой (если представить себе человека с таким имплантом в мозгах... в Систем Шок не играли? ) — потому что по факту дополнительные уровни абстракции неизбежно вносят оверхед, тут спорить нечего.
Скажи это суперкомпиляторам...
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Воронков Василий, Вы писали:
ВВ>А что "суперкомпилятор" сможет сделать с таким уровнем абстракции как делегат? Или с виртуальным вызовом?
Если ясно что именно будет вызвано то заинлайнить.
А искать что когда и зачем делают он умеет очень хорошо.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Вон, помнится, была статья — причем год или два назад — даже луноход какой-то под управлением джавы работал.
Здравствуйте, WolfHound, Вы писали:
ВВ>>А что "суперкомпилятор" сможет сделать с таким уровнем абстракции как делегат? Или с виртуальным вызовом? WH>Если ясно что именно будет вызвано то заинлайнить. WH>А искать что когда и зачем делают он умеет очень хорошо.
Ну давай все-таки конкретнее говорить. Ты какой-то конкретный "суперкомплятор" имеешь в виду? Или может быть в свете здешних дискуссий уместнее сказать "суперджит"?
Мало того, что такая "хардкорная" оптимизация возможна даже теоретически далеко не всегда, так в для языков на .NET ее ведь все равно никто не делает.
Здравствуйте, D. Mon, Вы писали:
DM>Не было такого. Софт для всяких луно/марсо-ходов сейчас пишут на чистом С, даже от Ады отказались. Джава использовалась на Земле в какой-то утилитке, но в космос никогда не летала. DM>http://se-radio.net/podcast/2008-06/episode-100-software-space
Как я и сказал:
"The places where NASA scientists have used Java for this mission is all on the ground side right now."
"The Rover itself has a computer onboard. There's no Java in that computer now."
Мы уже победили, просто это еще не так заметно...
определяются не тем, какая многозадачность, а тем, отделен ли код ядра от кода пользователя. В корректно написанной системе шансы нулевые, независимо от того, какая тут многозадачность. Я, признаться, никак не вижу связи между тем, как приложения (потоки и т.д.) уступают друг другу процессор и защищенностью OS. Более того, ИМХО кооперативная модель является более защищенной, так как передача управления происходит в строго фиксированных местах, а не где угодно.
), а ты их пытаешься убедить, что "существуют задачи, для решения которых использование высокоуровневых средств... неэффективно и нецелесообразно". Как на фиг высокоуровневые средства, у нас сплошной ХМЛ, блин 
) — потому что по факту дополнительные уровни абстракции неизбежно вносят оверхед, тут спорить нечего. 
