Re[22]: Зачем Майкрософту рубить сук, на котором он сидит? - Компьютерные священные войны

Здравствуйте, alexanderfedin, Вы писали:

A>Многие посетители КЫВТ-а регулярно пишут вещи, которые показывают полное непонимание мотивации компании, стоящей за теми или иными решениями.
A>Мне кажется, настала пора приоткрыть этим людям глаза на происходящее.

A>Итак, зачем Майкрософту рубить сук, на котором он сидит?

Потому что MS нужно как-то выживать.

1) Прошли те времена когда win занимала 85% на рынке ОС. Наступили времена, когда основные конкуренты Apple и Google захватили уже более половины рынка. И каждый из них продвигает свою платформу (objC & java соответственно), которая отбирает разработчиков у MS. В конце концов MS придется идти по пути oracle мигрируя свои флагманские продукты под наиболее famous операционное окружение, если они хотят выжить. И потребуется платформа для разработки под эти продукты. Винда кстати приносит лишь четверть доходов MS.

2) c# становится неконкурентоспособен относительно java. На заре соперничества это действительно был первоклассный продукт на платформе MS, но сейчас он "сливает" за счет отсутствия должной производительности (по отношению к оракловому хотспоту) и концептуальных фич (типа кроссплатформенности). Если это будет продолжаться, в течение 5 лет шарп скатится до уровня какого-нибудь паршивого clojure, а java будет наиболее популярной платформой.

На самом деле MS очевидно сильно проигрывает борьбу за платформу Oracle/Google и сообществу С++ благодаря отсутствию грамотных разработчиков платформы с одной стороны и тупого ожиревшего менеджемента с другой.

Здравствуйте, a_g_99, Вы писали:

__>2) c# становится неконкурентоспособен относительно java. На заре соперничества это действительно был первоклассный продукт на платформе MS, но сейчас он "сливает" за счет отсутствия должной производительности (по отношению к оракловому хотспоту) и концептуальных фич (типа кроссплатформенности). Если это будет продолжаться, в течение 5 лет шарп скатится до уровня какого-нибудь паршивого clojure, а java будет наиболее популярной платформой.

А есть какие-то тесты, доказывающие выделенное? Я как-то плохо себе представляю, что нужно сделать в джава, чтобы компенсировать отсутствие типов, хранящихся по значению.

Здравствуйте, alxrie, Вы писали:

a>Есть разработчики Mono. И в первую очередь от них зависит совместимость Mono с .NET.

Да? И как скоро обещают WPF под Mono?

avalon 1.0rc3 build 432, zlib 1.2.5

Здравствуйте, Евгений Акиньшин, Вы писали:

ЕА>Я как-то плохо себе представляю, что нужно сделать в джава, чтобы компенсировать отсутствие типов, хранящихся по значению.

А не так часто они и нужны для повышения перфоманса:
1) Для коллекций есть всякие костыли типа trove
2) Со всякими локальными наворотами отлично справляется escape-анализ

Здравствуйте, a_g_99, Вы писали:

__>Здравствуйте, alexanderfedin, Вы писали:

A>>Многие посетители КЫВТ-а регулярно пишут вещи, которые показывают полное непонимание мотивации компании, стоящей за теми или иными решениями.
A>>Мне кажется, настала пора приоткрыть этим людям глаза на происходящее.

A>>Итак, зачем Майкрософту рубить сук, на котором он сидит?

__>Потому что MS нужно как-то выживать.

__>1) Прошли те времена когда win занимала 85% на рынке ОС. Наступили времена, когда основные конкуренты Apple и Google захватили уже более половины рынка. И каждый из них продвигает свою платформу (objC & java соответственно), которая отбирает разработчиков у MS. В конце концов MS придется идти по пути oracle мигрируя свои флагманские продукты под наиболее famous операционное окружение, если они хотят выжить. И потребуется платформа для разработки под эти продукты. Винда кстати приносит лишь четверть доходов MS.

Зато MS умеет жать, где не сеяла. С каждого (ну почти каждого) андроид-девайса есть капает $10-$15 за патенты на алгоритмы. А у Apple они имеют сейчас точно неизвестно какой, но вроде довольно заметный процент акций.

Здравствуйте, Michael7, Вы писали:

M>Зато MS умеет жать, где не сеяла. С каждого (ну почти каждого) андроид-девайса есть капает $10-$15 за патенты на алгоритмы.
Навозные черви, что ещё сказать.

M>А у Apple они имеют сейчас точно неизвестно какой, но вроде довольно заметный процент акций.
Не имеют, они их давно продали. И процент известен был — они обязаны его в SEC filings писать.

Здравствуйте, xvost, Вы писали:

X>Здравствуйте, Евгений Акиньшин, Вы писали:

ЕА>>Я как-то плохо себе представляю, что нужно сделать в джава, чтобы компенсировать отсутствие типов, хранящихся по значению.

X>А не так часто они и нужны для повышения перфоманса:
X>1) Для коллекций есть всякие костыли типа trove
X>2) Со всякими локальными наворотами отлично справляется escape-анализ

А есть какие-то тесты или какие-то иные численные показатели этого "отлично"?
Я вот например в си-шарпе частенько использую структуры типа вектора, и преобразований с ними производится очень много, и глубина стека вызовов бывает приличная.

Здравствуйте, a_g_99, Вы писали:

__>2) c# становится неконкурентоспособен относительно java. На заре соперничества это действительно был первоклассный продукт на платформе MS, но сейчас он "сливает" за счет отсутствия должной производительности (по отношению к оракловому хотспоту) и концептуальных фич (типа кроссплатформенности).

Я вот смотрю на список игр на XNA в AppStore, Android Мarketplace и Сhrome Web Store и недоумеваю — о каком отсутствии производительности и концептуальных фичах типа кроссполатформенности идёт речь?

Здравствуйте, Yoriсk, Вы писали:

Y>Я вот смотрю на список игр на XNA в AppStore, Android Мarketplace и Сhrome Web Store и недоумеваю — о каком отсутствии производительности и концептуальных фичах типа кроссполатформенности идёт речь?

И много ты видишь бизнес-приложений под XNA ?

Здравствуйте, Ikemefula, Вы писали:

Y>>Я вот смотрю на список игр на XNA в AppStore, Android Мarketplace и Сhrome Web Store и недоумеваю — о каком отсутствии производительности и концептуальных фичах типа кроссполатформенности идёт речь?
I>И много ты видишь бизнес-приложений под XNA ?

И много ты видишь бизнес-приложений с требованием концептуальных фич типа кроссплатформенности?

Здравствуйте, Yoriсk, Вы писали:

Y>>>Я вот смотрю на список игр на XNA в AppStore, Android Мarketplace и Сhrome Web Store и недоумеваю — о каком отсутствии производительности и концептуальных фичах типа кроссполатформенности идёт речь?
I>>И много ты видишь бизнес-приложений под XNA ?

Y>И много ты видишь бизнес-приложений с требованием концептуальных фич типа кроссплатформенности?

Практически все сталкиваются с этой необходимостью.

Здравствуйте, Ikemefula, Вы писали:

Y>>>>Я вот смотрю на список игр на XNA в AppStore, Android Мarketplace и Сhrome Web Store и недоумеваю — о каком отсутствии производительности и концептуальных фичах типа кроссполатформенности идёт речь?
I>>>И много ты видишь бизнес-приложений под XNA ?
Y>>И много ты видишь бизнес-приложений с требованием концептуальных фич типа кроссплатформенности?
I>Практически все сталкиваются с этой необходимостью.

Очевидно что никто не сталкивается.

Вот игроделы — сталкиваются, результаты видны. Сталкивались бы разработчики "бизнес-приложений"(кстати, уточните что это, а то мы можем о разных вещах говорить) — сделали бы свои продукты под все эти XNA(там еще ЕМНИП win forms прикручиваются), совсем как игроделы. И мы видели бы результаты.

Здравствуйте, Yoriсk, Вы писали:

Y>Я вот смотрю на список игр на XNA в AppStore, Android Мarketplace и Сhrome Web Store и недоумеваю — о каком отсутствии производительности и концептуальных фичах типа кроссполатформенности идёт речь?

Плиз научите определять прямо по взгляду на страницу программы в сторах на чем она сделана?!

Здравствуйте, loginx, Вы писали:

Y>>Я вот смотрю на список игр на XNA в AppStore, Android Мarketplace и Сhrome Web Store и недоумеваю — о каком отсутствии производительности и концептуальных фичах типа кроссполатформенности идёт речь?
L>Плиз научите определять прямо по взгляду на страницу программы в сторах на чем она сделана?!

Прямо по взгляду я тоже не умею. А вот погуглив 2 минуты — более чем.

А вам зачем это надо? Если для оценки приложений на платформе/фреймворке — так зайдите с другой стороны: сначала идите на сайт оной, там будет список чего на ней сделано, дальше — вперёд в Стор/плэй смотреть рейтинги/читать обзоры.

Здравствуйте, Yoriсk, Вы писали:

Y>>>>>Я вот смотрю на список игр на XNA в AppStore, Android Мarketplace и Сhrome Web Store и недоумеваю — о каком отсутствии производительности и концептуальных фичах типа кроссполатформенности идёт речь?
I>>>>И много ты видишь бизнес-приложений под XNA ?
Y>>>И много ты видишь бизнес-приложений с требованием концептуальных фич типа кроссплатформенности?
I>>Практически все сталкиваются с этой необходимостью.

Y>Очевидно что никто не сталкивается.

Y>Вот игроделы — сталкиваются, результаты видны. Сталкивались бы разработчики "бизнес-приложений"(кстати, уточните что это, а то мы можем о разных вещах говорить) — сделали бы свои продукты под все эти XNA(там еще ЕМНИП win forms прикручиваются), совсем как игроделы. И мы видели бы результаты.

XNA это маленький рантайм, 32 бита и куча других ограничений и самое главное — XNA не требует инфраструктуры, то есть, вообще. А для бизнес-приложений требуется инфраструктура, которая вся насквозь некросплатформенная у микрософта, потому проще мигрировать под Джаву чем брать на себя разработку такой инфраструктуры. Собтсвенно мелочевку можно пускануть под Mono, а чуть что побольше — всё, приехали.

Это сделано абсолютно сознательно, потому что наличие такой кросплатформенной инфраструктуры сделает невыгодным виндовозный бизнес, с которого у Микрософта идут все деньги.

Здравствуйте, Ikemefula, Вы писали:

I>А для бизнес-приложений требуется инфраструктура, которая вся насквозь некросплатформенная у микрософта

О каких 64-х разрядных кроссплатформенных performance-critical бизнес приложениях и инфраструктуре на java идёт речь?

Здравствуйте, IObserver, Вы писали:

A>>А при чем тут Microsoft? Есть разработчики Mono. И в первую очередь от них зависит совместимость Mono с .NET.
IO>А кормит их кто?

xamarin + donations

Здравствуйте, veroni, Вы писали:

__>>1) Прошли те времена когда win занимала 85% на рынке ОС. Наступили времена, когда основные конкуренты Apple и Google захватили уже более половины рынка.

V>Вранье и провокация, по последнему отчету гугла мобильные пользователи телефонов приносят прибыли ему в 10 раз меньше, чем декстопники и ноутбучники.

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

Здравствуйте, Yoriсk, Вы писали:

I>>А для бизнес-приложений требуется инфраструктура, которая вся насквозь некросплатформенная у микрософта

Y>О каких 64-х разрядных кроссплатформенных performance-critical бизнес приложениях и инфраструктуре на java идёт речь?

Приходит заказчик и говорит — у меня вся сеть на линуксе. Это значит, что весь серверный софт должен быть линуксовый. А что у микрософта из серверного софта есть для линукса ? Ничего. Скажем простые приложения можно хостить в Моно. А куда они коннектиться будут ?

Здравствуйте, Ikemefula, Вы писали:

I>>>А для бизнес-приложений требуется инфраструктура, которая вся насквозь некросплатформенная у микрософта
Y>>О каких 64-х разрядных кроссплатформенных performance-critical бизнес приложениях и инфраструктуре на java идёт речь?
I>Приходит заказчик и говорит — у меня вся сеть на линуксе.

И снова стартует забег сферических коней в вакууме.
Жаль, что мы, видимо, так и не дождёмся примеров этих замечательных приложений.

Здравствуйте, Yoriсk, Вы писали:

I>>>>А для бизнес-приложений требуется инфраструктура, которая вся насквозь некросплатформенная у микрософта
Y>>>О каких 64-х разрядных кроссплатформенных performance-critical бизнес приложениях и инфраструктуре на java идёт речь?
I>>Приходит заказчик и говорит — у меня вся сеть на линуксе.

Y>И снова стартует забег сферических коней в вакууме.
Y>Жаль, что мы, видимо, так и не дождёмся примеров этих замечательных приложений.

IIS, Sql, Exchange, BizTalk, Search, Sharepoint

Здравствуйте, Ikemefula, Вы писали:

Y>>>>О каких 64-х разрядных кроссплатформенных performance-critical бизнес приложениях и инфраструктуре на java идёт речь?
...
I>IIS, Sql, Exchange, BizTalk, Search, Sharepoint

Здравствуйте, Yoriсk, Вы писали:

Y>Здравствуйте, Ikemefula, Вы писали:

Y>>>>>О каких 64-х разрядных кроссплатформенных performance-critical бизнес приложениях и инфраструктуре на java идёт речь?
Y>...
I>>IIS, Sql, Exchange, BizTalk, Search, Sharepoint

Y>

Не ясно зачем ты перформанс-критикал и джаву притянул за уши

Все решения от микрософта прибиты гвоздями к перечисленным и другим приложениям, которые ни разу не кроссплатформенны. Потому XNA ничего не меняет, ею можно пренебречь.

Здравствуйте, Ikemefula, Вы писали:

Y>>>>>>О каких 64-х разрядных кроссплатформенных performance-critical бизнес приложениях и инфраструктуре на java идёт речь?
Y>>...
I>>>IIS, Sql, Exchange, BizTalk, Search, Sharepoint
Y>>

I>Не ясно зачем ты перформанс-критикал и джаву притянул за уши

Влазить в разговор про про высокопроизводительную яву, приводить в пример "бизнес приложений" на яве Sharepoint и тут же обьявлять java притянутой за уши — это высший пилотаж, поздравляю!

I>Все решения от микрософта прибиты гвоздями к перечисленным и другим приложениям, которые ни разу не кроссплатформенны. Потому XNA ничего не меняет, ею можно пренебречь.

Да, я уже понял, что с примерами не срослось. А жаль.

Здравствуйте, Yoriсk, Вы писали:

Y>Влазить в разговор про про высокопроизводительную яву, приводить в пример "бизнес приложений" на яве Sharepoint и тут же обьявлять java притянутой за уши — это высший пилотаж, поздравляю!

И давно XNA стала джавой ?

Здравствуйте, Ikemefula, Вы писали:

Y>>Влазить в разговор про про высокопроизводительную яву, приводить в пример "бизнес приложений" на яве Sharepoint и тут же обьявлять java притянутой за уши — это высший пилотаж, поздравляю!
I>И давно XNA стала джавой ?

И давно java стала sql?

Здравствуйте, Ikemefula, Вы писали:

Блин, вы хоть читайте свои посты перед тем как писать.

I>Собтсвенно мелочевку можно пускануть под Mono, а чуть что побольше — всё, приехали.
I>А для бизнес-приложений требуется инфраструктура, которая вся насквозь некросплатформенная у микрософта, потому проще мигрировать под Джаву чем брать на себя разработку такой инфраструктуры

Y>О каких 64-х разрядных кроссплатформенных performance-critical бизнес приложениях и инфраструктуре на java идёт речь?

I>IIS, Sql, Exchange, BizTalk, Search, Sharepoint
I>Не ясно зачем ты перформанс-критикал и джаву притянул за уши

Здравствуйте, Yoriсk, Вы писали:

Y>>>Влазить в разговор про про высокопроизводительную яву, приводить в пример "бизнес приложений" на яве Sharepoint и тут же обьявлять java притянутой за уши — это высший пилотаж, поздравляю!
I>>И давно XNA стала джавой ?

Y>И давно java стала sql?

Я тебе показал, какая инфраструктура есть у микрософта и почему используя продукты от микрософт никогда не получится кроссплатформенность. Клиенту проще свалить в джаву.

Здравствуйте, Ikemefula, Вы писали:

I>Я тебе показал, какая инфраструктура есть у микрософта и почему используя продукты от микрософт никогда не получится кроссплатформенность. Клиенту проще свалить в джаву.

По факту приходится выбирать между инфраструктурой и кроссплатформенностью. Потому что в реальной жизни внезапно оказывается, что заменить тот же Exchange просто нечем, от слова "совсем".

Здравствуйте, alexanderfedin, Вы писали:

Могу сказать про банки в штатах. .NET с серверов приложений полностью выдавлен джавой. Web-технологии 50/50. Десктоп пока за .NET. Но тенденции печальные.

Если ещё лет пять назад можно было говорить о конкуренции .NET с джавой на серверах приложений, то сегодня такого разговора нет вообще в принципе. Всё! .NET с серверов надёжно и надолго вытеснен. Что от этого выиграла MS мне лично не понятно

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

В Web интересен прежде всего сильверлайт, которому в мире джавы альтернативы нет. Но MS эту технологию забросила и вовсю пиарит HTML5/JavaScript, что как раз и является пиленимем сука. Если они переведут всех веб девелоперов на это дело, то далее лёгким движением IIS меняется на Апач и .NET разработчики становятся джавистами. После чего возникает вполне законный вопрос — а зачем нам винда для веб-серверов? Нафиг винду, линукс форева.

На десктопе ситуация похожая. WPF мёртв и замену ему можно ждать только из мира джавы. Как только на горизонте появится что-нибудь достойное, то дотнетчиков попрут и с десктопа поганой метлой. А потом точно также встанет вопрос о нужности винды на десктопе.

Некоторым это всё, конечно, покажется страшилками, но против фактов не попрёшь. Не бывает так, чтобы платформа потихоньку сдавала свои позиции, сдавала, сдавала, а потом раз и всех заборола! Хрен вам! Пока мы устойчиво катимся вниз и наклон только увеличивается.

... << RSDN@Home 1.2.0 alpha 5 rev. 69>>

Здравствуйте, IT, Вы писали:

IT>Если бы наоборот — выжали джаву с серверов, то не исключено, что на определённом, и, думаю, не маленьком, проценте серверов сейчас крутилась бы винда. Но не судьба.

Ну, по тем данным что публично доступны виндовых серверов >50%. Это в целом. В энетрпрайзе, думаю, процент еще выше.

IT>Если они переведут всех веб девелоперов на это дело, то далее лёгким движением IIS меняется на Апач и .NET разработчики становятся джавистами.

Там все еще круче — отдельные личности проталкивают PHP и node.js под IIS.

Здравствуйте, Kerk, Вы писали:

K>По факту приходится выбирать между инфраструктурой и кроссплатформенностью. Потому что в реальной жизни внезапно оказывается, что заменить тот же Exchange просто нечем, от слова "совсем".

И много ты знаешь мобильных платформ, на которые Exchange ставится ?

Здравствуйте, Ночной Смотрящий, Вы писали:

IT>>Если бы наоборот — выжали джаву с серверов, то не исключено, что на определённом, и, думаю, не маленьком, проценте серверов сейчас крутилась бы винда. Но не судьба.
НС>Ну, по тем данным что публично доступны виндовых серверов >50%. Это в целом. В энетрпрайзе, думаю, процент еще выше.

На балансе моей команды виндовых серверов меньше, чем линуксовых. Это при том, что у нас исключительно .NET. У соседей примерно тоже. Там, где смешанные .NET/Java команды виндовых серверов практически нет. Там, где только Java даже говорить не о чем. Это то, что я вижу своими глазами без публичных данных.

... << RSDN@Home 1.2.0 alpha 5 rev. 69>>

Здравствуйте, Ikemefula, Вы писали:

I>И много ты знаешь мобильных платформ, на которые Exchange ставится ?

А причем здесь мобильные платформы? Что это за инфраструктура такая, состоящая исключительно из мобильных платформ?
Если уж на то пошло, то мобильных платформ, на которые ставятся, скажем так, клиенты для Exchange я знаю много.

Здравствуйте, IT, Вы писали:

IT>На балансе моей команды виндовых серверов меньше, чем линуксовых.

Значит тебе не повезло

Здравствуйте, Ночной Смотрящий, Вы писали:

IT>>На балансе моей команды виндовых серверов меньше, чем линуксовых.
НС>Значит тебе не повезло

Тогда уж не повезло половине НуЁрка. А вторая половина и так уже на джаве.

Здравствуйте, IT, Вы писали:

IT>Тогда уж не повезло половине НуЁрка.

Может и так. Но вот всякие там аналитики говорят несколько иное. Даже в вебе 35% вин-серверов (линуксов — 32%) пруфлинк.
А по поводу новых серверов вот что IDC врет:

Microsoft Windows server hardware demand was down 0.9% year over year in 3Q12 with quarterly server hardware revenue totaling $6.2 billion representing 51.1% of overall quarterly factory revenue, up 1.6 points over the prior year's quarter. This is the second time in the past three quarters that Windows has been responsible for driving more than half of all server spending worldwide.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>А по поводу новых серверов вот что IDC врет:

А там не написано, это новые сервера или апгрейды?

Здравствуйте, IT, Вы писали:

IT>Могу сказать про банки в штатах. .NET с серверов приложений полностью выдавлен джавой. Web-технологии 50/50. Десктоп пока за .NET. Но тенденции печальные.
IT>Если ещё лет пять назад можно было говорить о конкуренции .NET с джавой на серверах приложений, то сегодня такого разговора нет вообще в принципе. Всё! .NET с серверов надёжно и надолго вытеснен. Что от этого выиграла MS мне лично не понятно

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

Опана. Вот оно как получается, а мне недавно тут доказывали, что джаву вытесняют везде, а дотнет во все поля идет. Так кто же тут прав?

IT>Некоторым это всё, конечно, покажется страшилками, но против фактов не попрёшь. Не бывает так, чтобы платформа потихоньку сдавала свои позиции, сдавала, сдавала, а потом раз и всех заборола! Хрен вам! Пока мы устойчиво катимся вниз и наклон только увеличивается.

Дотнет уже 10 лет пытается забороть джаву.

Здравствуйте, IT, Вы писали:

НС>>А по поводу новых серверов вот что IDC врет:
IT>А там не написано, это новые сервера или апгрейды?

http://www.idc.com/getdoc.jsp?containerId=prUS23808612

Здравствуйте, xRAZORx, Вы писали:

RAZ>Опана. Вот оно как получается, а мне недавно тут доказывали, что джаву вытесняют везде, а дотнет во все поля идет. Так кто же тут прав?

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

RAZ>Дотнет уже 10 лет пытается забороть джаву.

Он уже давно заборол ее на винде. А на остальных платформах, как ты понимаешь, он и не претендует.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>>>А по поводу новых серверов вот что IDC врет:
IT>>А там не написано, это новые сервера или апгрейды?

НС>http://www.idc.com/getdoc.jsp?containerId=prUS23808612

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

Так вот оно как, Михалыч! Овно оказывается эта ваша серверная винда.

Здравствуйте, IT, Вы писали:

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

IT>Так вот оно как, Михалыч! Овно оказывается эта ваша серверная винда.

Очевидно, он передаёт отзывы админов. Осталось сформулировать в тексте, выложить и проанализировать эти самые отзывы.

Здравствуйте, netch80, Вы писали:

IT>>Так вот оно как, Михалыч! Овно оказывается эта ваша серверная винда.
N>Очевидно, он передаёт отзывы админов. Осталось сформулировать в тексте, выложить и проанализировать эти самые отзывы.

Очевидно, что есть проблемы. И очевидно, что майкрософт о них в курсе, только им как всегда пофиг.

... << RSDN@Home 1.2.0 alpha 5 rev. 69>>

Здравствуйте, IT, Вы писали:

IT> Так вот оно как, Михалыч! Овно оказывается эта ваша серверная винда.

Не сцать! Вот проникнутся одмины метроплиточками новых вендов... Так победимЪ!!!

avalon 1.0rc3 build 432, zlib 1.2.5

Здравствуйте, IT, Вы писали:

IT>А как же у майкрософта есть тулзы для админов? А ты их видел эти тулзы? Пусть они засунут их себе куда-нибудь подальше (это уже мой художественный перевод).

А чем линуксовые шеллы принципиально лучше psh он не сказал?

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Здравствуйте, IT, Вы писали:

IT>>А как же у майкрософта есть тулзы для админов? А ты их видел эти тулзы? Пусть они засунут их себе куда-нибудь подальше (это уже мой художественный перевод).

НС>А чем линуксовые шеллы принципиально лучше psh он не сказал?

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

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>А чем линуксовые шеллы принципиально лучше psh он не сказал?

У линуксовых шеллов нет принципиальных различий между локальной и удаленной работой.

Здравствуйте, TK, Вы писали:

TK>Здравствуйте, Ночной Смотрящий, Вы писали:

НС>>А чем линуксовые шеллы принципиально лучше psh он не сказал?

TK>У линуксовых шеллов нет принципиальных различий между локальной и удаленной работой.

У PS тоже. Первое найденное: http://www.howtogeek.com/117192/how-to-run-powershell-commands-on-remote-computers/ , если есть домен — настраивается через GPO.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>А чем линуксовые шеллы принципиально лучше psh он не сказал?

Велика радость — интерпретатор команд. Пфф. Дело-то не в шеллах. А в том, что из-под этих шеллов можно запускать.

В лялихе стандартная парадигма — консольный бакенд + GUI-фронтенды к нему. Даже многие мультимедийные вещи, по сути своей интерактивные, написаны с использованием этой парадигмы (например: mplayer, jackd, linuxsampler). Чего уж про системные тулзы говорить. Т.е. практически всё заточено под работу в консоли из-под bash-скриптов. В винде, насколько я помню, такой подход — скорее исключение, чем правило.

Здравствуйте, dimgel, Вы писали:

D>В винде, насколько я помню, такой подход — скорее исключение, чем правило.

В винде есть куча своих, не менее мощных средств — от mmc, wmi и т.п. до продуктов типа MS System Center, который искаропки дает целую инфраструктуру управления информационной системой корпорации, от датацентров до мобильных телефонов. Собрать последнее на линухе если и можно, то долго и больно скручивая пачку продуктов.

Здравствуйте, Codechanger, Вы писали:

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

На самом деле серверная винда действительно не хуже линуха. Но фокус в том что она и не лучше. А соответственно тогда зачем платить за неё, если есть такой же, но бесплатный линух?

Вот на десктопе винда действительно лучше линуха по многим параметрам и там есть смысл потратить на неё деньги. А для серверов не вижу смысла. Разве что по "историческим" в компании причинам...

Здравствуйте, Ночной Смотрящий, Вы писали:

D>>В винде, насколько я помню, такой подход — скорее исключение, чем правило.
НС>В винде есть куча своих, не менее мощных средств — от mmc, wmi и т.п. до продуктов типа MS System Center, который искаропки дает целую инфраструктуру управления информационной системой корпорации, от датацентров до мобильных телефонов. Собрать последнее на линухе если и можно, то долго и больно скручивая пачку продуктов.
MMC — маздай, WMI — отстой. Мониторинг — прямо из морга раскопали. Нормальной production-ready инструментации (perf, SystemTap, DTrace) нифига нет. Namespace'ы и cgroups — в зайчаточном состоянии и не поддерживаются нормально инструментами. Создание сервисов — лишь немного менее болезненно, чем вырывание зубов без наркоза. И т.д.

В общем, закапывайте этот WinServer обратно. Оно годится для поддержки ActiveDirectory и Exchange, но использовать его для своих приложений весьма утомительно по сравнению с Линуксом. Особенно на облачных системах.

Здравствуйте, Sinix, Вы писали:

TK>>У линуксовых шеллов нет принципиальных различий между локальной и удаленной работой.
S>У PS тоже. Первое найденное: http://www.howtogeek.com/117192/how-to-run-powershell-commands-on-remote-computers/ , если есть домен — настраивается через GPO.
Умеет MS извращаться.

Типичная ситуация — хост на Amazon EC2. Ни в каком домене, естественно, не участвует (так как у EC2 нет доступа в нашу внутреннюю сеть с контроллером домена). Нужно подключиться туда удалённо.

На Линуксе:
1) Бросаем свой authorized_keys в ~/.ssh
2) Включаем в firewall доступ на порт 22.
3) Всё работает.

На Винде:
1) Что-то поменять в реестре на клиенте.
2) Добавить имя серверной машины (которое динамическое, ага) в trusted hosts на клиенте.
3) Открыть все порты для клиента (какой именно набор нужен — х.з. разбираться).
4) Что-то поменять в GPO на сервере.
5) Сделать новый credential на клиенте. Публичные ключи? Ха! ~~Nazi science~~Windows sneers at you!
6) Создать PS-Session и записать её ID.
7) Enter-PSSession.

Повбывав бы.

Здравствуйте, Cyberax, Вы писали:

C>Повбывав бы.

Угу, изврат. Для single instance можно было сделать чуть проще — http://blogs.msdn.com/b/mariok/archive/2011/08/08/command-line-access-to-azure-vms-powershell-remoting.aspx

Плюс, относительно недавно появился azure ps, я уже за этой темой не слежу, первое нагугленное — http://michaelwasham.com/tag/windows-azure-powershell-cmdlets/

Здравствуйте, Cyberax, Вы писали:

UPD. Отстал от жизни. AzurePS теперь официально поддерживается, можно брать отсюда (секция Command line tools).

Здравствуйте, Sinix, Вы писали:

S>UPD. Отстал от жизни. AzurePS теперь официально поддерживается, можно брать отсюда (секция Command line tools).
Мне нафиг не нужен Azure. Мне нужен Amazon EC2 и наши собственные внутренние облака. А там геморрою с этой виндой, блин.

На поддержку Линукса реально уходить примерно раз в 5 меньше времени, хотя у нас на нём софта работает намного больше.

Здравствуйте, Cyberax, Вы писали:

C>Мне нафиг не нужен Azure. Мне нужен Amazon EC2 и наши собственные внутренние облака. А там геморрою с этой виндой, блин.

А если мне таки нужен Азур, то ситуация поменяется на противоположную, геморой будет с линухом.

C>На поддержку Линукса реально уходить примерно раз в 5 меньше времени, хотя у нас на нём софта работает намного больше.

Если пытаться винду администрировать как линух, то результат ожидаем.

Здравствуйте, alex_public, Вы писали:

_>А соответственно тогда зачем платить за неё, если есть такой же, но бесплатный линух?

Чтобы пользоваться продукцией серверного и девтульного дивиженов.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Чтобы пользоваться продукцией серверного и девтульного дивиженов.

Вот на десктопе это реально аргумент. А на серверах что за софт такой нужный есть под виндой и нет под линухом?

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>В винде есть куча своих, не менее мощных средств — от mmc, wmi и т.п. до продуктов типа MS System Center, который искаропки дает целую инфраструктуру управления информационной системой корпорации, от датацентров до мобильных телефонов. Собрать последнее на линухе если и можно, то долго и больно скручивая пачку продуктов.

А запустить pipeline (jackd + linuxsampler + vlc на запись mp3) для цифрового пианино в один клик вся эта супер-пупер-инфраструктура сможет? (У меня это делает .sh-скриптик на 10 строк.) Или может ты путаешь существование навороченных решений для узкого класса задач с универсальностью и гибкостью системы на всех уровнях?

Здравствуйте, alex_public, Вы писали:

_>Вот на десктопе это реально аргумент.

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

_> А на серверах что за софт такой нужный есть под виндой и нет под линухом?

MSSQL, к примеру. Из большой тройки по соотношению цена/перформанс он на первом месте с хорошим отрывом (я уж не говорю про дружелюбность к девелоперу). И есть он исключительно на винде.

Здравствуйте, dimgel, Вы писали:

D>А запустить pipeline (jackd + linuxsampler + vlc на запись mp3) для цифрового пианино в один клик

Зачем тебе это на сервере делать?

D>Или может ты путаешь существование навороченных решений для узкого класса задач с универсальностью и гибкостью системы на всех уровнях?

Универсальность и гибкость, это далеко не бесплатные вещи.

Здравствуйте, Ночной Смотрящий, Вы писали:

D>>А запустить pipeline (jackd + linuxsampler + vlc на запись mp3) для цифрового пианино в один клик

НС>Зачем тебе это на сервере делать?

А тут разве срач про сервера? Мне казалось — win vs lin. И вообще, это идиотское разделение на десктоп и сервер MS-овские маркетологи придумали. Вот у меня дома две машины — обе и десктоп, и сервер. Серверного софта на них крутится — чуть менее чем полный комплект. А теперь представь, каким идиотом я бы себя почувствовал, решив купить винду под свои нужды: что выбирать? Для ответа на этот совершенно искусственный, маркетологами — повторюсь — навязанный вопрос нужно быть опытным виндузявым сисадмином. Новичок же имеет хорошие шансы угодить в эту подленькую ловушку, потратив деньги дважды.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Универсальность и гибкость, это далеко не бесплатные вещи.

Естессно. Ничто не бесплатно в этом мире. Отсутствие универсальности и гибкости — тоже не бесплатно. Однако универсальность и гибкость системы никоим образом не исключает возможности создания под неё монструозных тулзов. И если эти тулзы ещё не созданы, это может означать только одно: они нафиг никому не нужны в условиях этой самой гибкости.

Здравствуйте, dimgel, Вы писали:

D>А тут разве срач про сервера?

В этой нитке начиная с сообщения ИТ — да, про сервера. А про линукс на десктопе и так все понятно

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>На десктопе очень небольшая часть продукции серверного дивижена нужна, а девтулы, вроде как, для серверного софта тоже нужны.

Ммм я плохо сформулировал ту свою фразу. В общем я хотел сказать что на десктопе есть реально много нужного софта, который есть под винду и которого нет (даже приемлемых аналогов) под линух. В то время как для серверов мне вообще ни один подобный пункт не приходит в голову...

НС>MSSQL, к примеру. Из большой тройки по соотношению цена/перформанс он на первом месте с хорошим отрывом (я уж не говорю про дружелюбность к девелоперу). И есть он исключительно на винде.

Сходу вспоминаю 3 разных sql сервера под линух. Причём как "слабее", так и "сильнее" MSSQL. Так что очень сомнительный аргумент.

Здравствуйте, alex_public, Вы писали:

_>Ммм я плохо сформулировал ту свою фразу. В общем я хотел сказать что на десктопе есть реально много нужного софта, который есть под винду и которого нет (даже приемлемых аналогов) под линух.

Ну и что? С десктопами и так все понятно, там больше 90% винды, что вы с таким удивительным постоянством пытаетесь на них перескочить? А вот с серверами не все так очевидно. И, тем не менее, если верить тому же IDC, доля винды растет довольно долго и стабильно и уже переросла половину (в вебе винда чуть чуть перегнала линух, обе где то по треть рынка занимают).

НС>>MSSQL, к примеру. Из большой тройки по соотношению цена/перформанс он на первом месте с хорошим отрывом (я уж не говорю про дружелюбность к девелоперу). И есть он исключительно на винде.

_>Сходу вспоминаю 3 разных sql сервера под линух.

Да хоть 10. Нормальных серверов там ровно два — Оракль и DB2. И то и другое существенно дороже mssql при сопоставимом качестве. Речь, разумеется, не про игрушечные или вообще бесплатные версии.

Здравствуйте, alex_public, Вы писали:

_>На самом деле серверная винда действительно не хуже линуха. Но фокус в том что она и не лучше. А соответственно тогда зачем платить за неё, если есть такой же, но бесплатный линух?

Специалисты дороже вроде обходятся, не? Т.е. сам лялих бесплатен, конечно, но с поддержкой можно намаяться.

Здравствуйте, Ночной Смотрящий, Вы писали:

C>>Мне нафиг не нужен Azure. Мне нужен Amazon EC2 и наши собственные внутренние облака. А там геморрою с этой виндой, блин.
НС>А если мне таки нужен Азур, то ситуация поменяется на противоположную, геморой будет с линухом.
Ну так нефиг на недо-облаке от MS запускать нормальные ОС...

Проблема в том, что с Виндой геморрой везде. В случае с Azure его немного прячет сама MS.

C>>На поддержку Линукса реально уходить примерно раз в 5 меньше времени, хотя у нас на нём софта работает намного больше.
НС>Если пытаться винду администрировать как линух, то результат ожидаем.
Ну т.е. нефиг пытаться автоматически делать повторяемые и контролируемые образы машин на Винде? Согласен, Винда для этого годиться очень плохо.

Здравствуйте, Ночной Смотрящий, Вы писали:

_>> А на серверах что за софт такой нужный есть под виндой и нет под линухом?
НС>MSSQL, к примеру. Из большой тройки по соотношению цена/перформанс он на первом месте с хорошим отрывом (я уж не говорю про дружелюбность к девелоперу). И есть он исключительно на винде.
PostgreSQL.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Ну и что? С десктопами и так все понятно, там больше 90% винды, что вы с таким удивительным постоянством пытаетесь на них перескочить? А вот с серверами не все так очевидно. И, тем не менее, если верить тому же IDC, доля винды растет довольно долго и стабильно и уже переросла половину (в вебе винда чуть чуть перегнала линух, обе где то по треть рынка занимают).
Да ну? http://news.netcraft.com/archives/2012/07/03/july-2012-web-server-survey.html — у IIS едва 15%. Конечно, часть nginx может быть фронтэндом для aspx и часть Апача может работать на Винде, но явного отрыва MS что-то не видно ну никак. Причём доля MS как раз снижается. Во многом из-за облачной революции, которую MS благополучно проспали.

Если считать внутренние системы, то у одного только Гугла и Facebook более миллиона серверов будет. На Линуксе.

НС>Да хоть 10. Нормальных серверов там ровно два — Оракль и DB2. И то и другое существенно дороже mssql при сопоставимом качестве. Речь, разумеется, не про игрушечные или вообще бесплатные версии.
DB2? LOL.

Здравствуйте, Cyberax, Вы писали:

C>Да ну? http://news.netcraft.com/archives/2012/07/03/july-2012-web-server-survey.html — у IIS едва 15%. Конечно, часть nginx может быть фронтэндом для aspx и часть Апача может работать на Винде

Вот видишь, ты сам все понимаешь. А еще реальные сервера могут скрываться за каким нибудь сервисом типа акамая. А еще 100500 сайтиков на ПХП, крутящихся на одном сервере, статистику в сайтах тоже соответственную делают.

C>DB2? LOL.

Как обычно, никаких аргументов, один треп.

Здравствуйте, Cyberax, Вы писали:

C>PostgreSQL.

Не тянет он на корпоративную СУБД, увы. И перформанс не тот, и оптимизатор хромает, и кластеры делать не умеет, и еще куча проблем — наш продукт постгрес поддерживает, да еще я в основном этой поддержкой и занимаюсь, так что опыт есть, многолетний. Впрочем, из бесплатных он, наверное, лучший.

Здравствуйте, Cyberax, Вы писали:

C>Ну так нефиг на недо-облаке от MS запускать нормальные ОС...

Ты, как обычно, в принципе не способен адекватно спорить.

Здравствуйте, Ночной Смотрящий, Вы писали:

D>>А тут разве срач про сервера?
НС>В этой нитке начиная с сообщения ИТ — да, про сервера. А про линукс на десктопе и так все понятно

Кстати, ещё одна печальная история про поддержку майкрософтом серверной разработки. Как должно работать серверное приложение, если его нет желания устанавливать в IIS? Правильно, как Windows Service. В VS2010- для установки сервисов был специальный тип проекта. Пишешь сервис, пишешь инсталяху, инсталлируешь и работаем. В VS2012 они решили, что проект для инсталляции поддерживать больше не интересно. Рекомендуют скачать какой-то там InstallShiled Lite. Но дело в том, что в моей конторе эту хрень нужно сначала заапрувить, доказать необходимость её использования, пройти 256 кругов ада, а потом ещё 512. С другой стороны можно просто забить на VS2012, а за одно и на FW 4.5. Хотя может тогда сразу и вообще на .NET.

... << RSDN@Home 1.2.0 alpha 5 rev. 69>>

Здравствуйте, IT, Вы писали:

IT>В VS2010- для установки сервисов был специальный тип проекта. Пишешь сервис, пишешь инсталяху, инсталлируешь и работаем.

Во-первых инсталлятор для сервисов есть в составе фреймворка, во-вторых у меня на написание инсталлера на базе winapi со всеми возможными фичами ушло меньше часа. И да, нормальный сервис должен уметь инсталлировать себя без каких либо отдельных инсталляторов.

IT> В VS2012 они решили, что проект для инсталляции поддерживать больше не интересно. Рекомендуют скачать какой-то там InstallShiled Lite.

http://wixtoolset.org/
Переходи на него. Студийным генератором инсталлеров все равно пользоваться нормально было нельзя, уж больно убог.

IT> Но дело в том, что в моей конторе эту хрень нужно сначала заапрувить, доказать необходимость её использования, пройти 256 кругов ада, а потом ещё 512.

С чем я твою контору и поздравляю. Интересно, а линуксевый софт и очередную версию жабы аппрувить в ней не нужно?

Здравствуйте, Ночной Смотрящий, Вы писали:

C>>Да ну? http://news.netcraft.com/archives/2012/07/03/july-2012-web-server-survey.html — у IIS едва 15%. Конечно, часть nginx может быть фронтэндом для aspx и часть Апача может работать на Винде
НС>Вот видишь, ты сам все понимаешь. А еще реальные сервера могут скрываться за каким нибудь сервисом типа акамая. А еще 100500 сайтиков на ПХП, крутящихся на одном сервере, статистику в сайтах тоже соответственную делают.
Могут. Только Акамай нынче не прячет заголовки нижележащего сервера.

cyberax@whale2:~/work/extreme-s3/bin/es3$ HEAD microsoft.com
200 OK
Cache-Control: private
Date: Fri, 26 Apr 2013 20:50:08 GMT
Server: Microsoft-IIS/8.0

А тонны сайтиков на PHP — почему их не считаем?

Здравствуйте, Ночной Смотрящий, Вы писали:

C>>Ну так нефиг на недо-облаке от MS запускать нормальные ОС...
НС>Ты, как обычно, в принципе не способен адекватно спорить.
Ты, как обычно, в принципе не способен адекватно спорить, так как работаешь только с MS.

Здравствуйте, Ночной Смотрящий, Вы писали:

C>>PostgreSQL.
НС>Не тянет он на корпоративную СУБД, увы. И перформанс не тот, и оптимизатор хромает, и кластеры делать не умеет, и еще куча проблем — наш продукт постгрес поддерживает, да еще я в основном этой поддержкой и занимаюсь, так что опыт есть, многолетний. Впрочем, из бесплатных он, наверное, лучший.
Performance нормальный, оптимизатор адекватный, кластеры умеет (разные).

А вот АДЪ, который из себя представляют старые сервера типа DB2, где надо отдельного администратора, чтобы разбираться почему оно сегодня глючит мы уже опробовали по полной.

Тем более, что прошли уже те годы, когда высшим мастерством было умение написать многокилометровый запрос на местном варианте SQL для создания отчётов, а потом оптимизировать его, чтобы он работал 15 минут вместо двух часов. Нынче проще тупо загрузить данные в память и пройтись по ним простым циклом (терабайтные машинки стоят уже приемлимо) или запустить запросик через Hadoop. Тем более, что критерии "больших данных" сильно сдвинулись вверх.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>А про линукс на десктопе и так все понятно

Ну сделай мне на виндоуз-десктопе батничек в 10 строк, запускающий realtime audio server + sampler + write to mp3 в один клик. А то я смотрю, извиваешься тут ужом — то зачем это на сервере, то с клиентами всё понятно.

Здравствуйте, Cyberax, Вы писали:

C>Тем более, что прошли уже те годы, когда высшим мастерством было умение написать многокилометровый запрос на местном варианте SQL для создания отчётов, а потом оптимизировать его, чтобы он работал 15 минут вместо двух часов. Нынче проще тупо загрузить данные в память и пройтись по ним простым циклом (терабайтные машинки стоят уже приемлимо) или запустить запросик через Hadoop. Тем более, что критерии "больших данных" сильно сдвинулись вверх.

А я больше промежуточные таблицы люблю. Такая вот ручная декомпозиция многоэтажных запросов, без клиентского трафика. Вполне красивенько, понятненько и шустренько, как в лучших домах. На куче мелких insert-select гораздо удобнее твикать оптимизатор, чем на одном огромном. Не знаю что там в MS SQL, но эвристики постгресовские частенько таки-лажают, когда данных гигабайты. Помнится, к примеру, прекрасный глюк, когда он вылетал out of memory, пытаясь загрузить в память всю таблицу для hash join. В таких случаях приходится вручную временно запрещать этот самый hash join (и все остальные кроме index join) для отдельно взятых этапов (insert into temptable select ...), что невозможно, если все эти этапы — в одном запросе.

Здравствуйте, Codechanger, Вы писали:

_>>На самом деле серверная винда действительно не хуже линуха. Но фокус в том что она и не лучше. А соответственно тогда зачем платить за неё, если есть такой же, но бесплатный линух?

C>Специалисты дороже вроде обходятся, не? Т.е. сам лялих бесплатен, конечно, но с поддержкой можно намаяться.

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

Здравствуйте, Cyberax, Вы писали:

C>А тонны сайтиков на PHP — почему их не считаем?

Потому что на один реальный сервер приходится 100500 таких сайтиков.

Здравствуйте, Cyberax, Вы писали:

C>Performance нормальный, оптимизатор адекватный

Сиильно недотягивает до большой тройки.

C>, кластеры умеет (разные).

А ты почитай как он их "умеет". Лучше б не умел, чем так.

Здравствуйте, dimgel, Вы писали:

D>Не знаю что там в MS SQL

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

D>но эвристики постгресовские частенько таки-лажают, когда данных гигабайты

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

Здравствуйте, Cyberax, Вы писали:

C>Ты, как обычно, в принципе не способен адекватно спорить, так как работаешь только с MS.

Сам то в это веришь, или чем наглее ложь тем убедительнее?

Здравствуйте, dimgel, Вы писали:

D>Ну сделай мне на виндоуз-десктопе батничек в 10 строк, запускающий realtime audio server + sampler + write to mp3 в один клик

Нафига? Мне не надо.

D>. А то я смотрю, извиваешься тут ужом — то зачем это на сервере, то с клиентами всё понятно.

Это ты пытаешься тему перевести.

Здравствуйте, Ночной Смотрящий, Вы писали:

C>>Performance нормальный, оптимизатор адекватный
НС>Сиильно недотягивает до большой тройки.
Ну так и не надо. Если оптимизатор сильно не справляется, то с большой вероятностью стоит использовать альтернативные стратегии (NoSQL и прочая).

C>>, кластеры умеет (разные).
НС>А ты почитай как он их "умеет". Лучше б не умел, чем так.
Собственно, я их использую (в режиме log shipping) для обеспечения HA и load balancing'а на нескольких узлах в Amazon EC2. Никаких проблем, всё работает с полпинка. А вот угрёбищный MSSQL требует для кластеризации разделяемого хранилища. Причём быстрого. Причём это хранилище становится SPOF.

И это называется "большая тройка", ага.

Здравствуйте, Ночной Смотрящий, Вы писали:

IT>>В VS2010- для установки сервисов был специальный тип проекта. Пишешь сервис, пишешь инсталяху, инсталлируешь и работаем.
НС>Во-первых инсталлятор для сервисов есть в составе фреймворка, во-вторых у меня на написание инсталлера на базе winapi со всеми возможными фичами ушло меньше часа. И да, нормальный сервис должен уметь инсталлировать себя без каких либо отдельных инсталляторов.

Это всё не нужно. Этот проект нормально мигрировал ещё с VS2005 и тут вот вам нате хер в томате.

IT>> В VS2012 они решили, что проект для инсталляции поддерживать больше не интересно. Рекомендуют скачать какой-то там InstallShiled Lite.

НС>http://wixtoolset.org/
НС>Переходи на него. Студийным генератором инсталлеров все равно пользоваться нормально было нельзя, уж больно убог.

Это всё тоже нужно апрувить.

IT>> Но дело в том, что в моей конторе эту хрень нужно сначала заапрувить, доказать необходимость её использования, пройти 256 кругов ада, а потом ещё 512.
НС>С чем я твою контору и поздравляю. Интересно, а линуксевый софт и очередную версию жабы аппрувить в ней не нужно?

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

... << RSDN@Home 1.2.0 alpha 5 rev. 69>>

Здравствуйте, Cyberax, Вы писали:

НС>>Сиильно недотягивает до большой тройки.
C>Ну так и не надо.

Кому как.

C> Если оптимизатор сильно не справляется, то с большой вероятностью стоит использовать альтернативные стратегии (NoSQL и прочая).

Да да, тему nosql в корпоративных системах мы уже как то обсуждали

НС>>А ты почитай как он их "умеет". Лучше б не умел, чем так.
C>Собственно, я их использую

У тебя опять какая нибудь специфическая задача, нужная 0.01% инсталляций sql серверов.

C>И это называется "большая тройка", ага.

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

Здравствуйте, IT, Вы писали:

IT>Это всё тоже нужно апрувить.

Сочувствую.

IT>Можешь поздравить не только мою контору, но и все остальные банки НуЁрка

Да ради бога, мне не жалко. Хотя я бы на все банки не обобщал.

IT> Так что как и что апрувить никого здесь учить не надо.

Да нафик мне учить? Пусть ходят по граблям и дальше, если нравится. Только вот ты по поводу аппрува линуксового софта не ответил — там что, аппрувить не надо?

Здравствуйте, Ночной Смотрящий, Вы писали:

C>> Если оптимизатор сильно не справляется, то с большой вероятностью стоит использовать альтернативные стратегии (NoSQL и прочая).
НС>Да да, тему nosql в корпоративных системах мы уже как то обсуждали

Ну дык. Местный банк какого-нибудь Задрищенска с сервером под DB2 на древнем AS/400, который они купили 10 лет назад — это серьёзная система. А Google с парой сотен тысяч серверов с NoSQL — это несерьёзные хиппи. Знакомо, да.

C>>Собственно, я их использую
НС>У тебя опять какая нибудь специфическая задача, нужная 0.01% инсталляций sql серверов.
Конкретно PostgreSQL у меня для вполне классических реляционных проблем (учёт задач, метаданные и т.п.). В NoSQL у меня хранится петабайт данных, которые на SQL ну никак не налезут.

C>>И это называется "большая тройка", ага.
НС>Большая тройка это называется в силу количества инсталляций, а вовсе не из-за того что оно работает на амазоновском клауде. Основное применение больших sql серверов — коропоративные системы, а они на облака не ставятся.
1) Ещё как ставятся.
2) Количество инсталляций PostgreSQL и MySQL точно больше DB2 и я почти уверен, что больше MSSQL и Oracle даже без учёта сайтиков на PHP. Или считаем только инсталляции в приличных компаниях с дресскодом и без хиппи?

Я вообще сейчас слабо понимаю смысл использования DB2 и Oracle. Ну да, там оптимизатор есть, но при этом геморрой с администрированием и стоит кучу денег. На кластерах стоит не просто кучу, а гору денег. У MSSQL хотя бы есть приличные инструменты для разработки, но только ради них затачивать всю архитектуру под MS — крайне сомнительное занятие.

Здравствуйте, Cyberax, Вы писали:

C>Я вообще сейчас слабо понимаю смысл использования DB2 и Oracle. Ну да, там оптимизатор есть, но при этом геморрой с администрированием и стоит кучу денег. На кластерах стоит не просто кучу, а гору денег. У MSSQL хотя бы есть приличные инструменты для разработки, но только ради них затачивать всю архитектуру под MS — крайне сомнительное занятие.

В portaone ради "серьёзных людей" пришлось делать вариант поддержки базы Oracle. Теперь
1) нужен фактически отдельный DBA, оплата книг, курсов, etc, и он постоянно занят диагностиками и оптимизациями.
2) резко усложнилось администрирование — банальный запрос мелкой переделки структуры базы требует согласований, подгонки под умение базы в плане организации индексов, местами какие-то безумные требования типа "для этой колонки включите nls_sort_ci, и нам пофиг, что у вас там адрес узла, которому всякие особенности локализации в принципе запрещены", в результате мы рисуя чего хотим видеть — выглядим идиотами перед DBA'щиками.
3) DBA ходит и ноет "вы тут слишком много транзакций плодите. собирайте действия в пачки, даже если совершенно не связаны друг с другом. у меня коммит дорогой".
4) у клиентских библиотек в принципе не лечатся детские болезни. обрыв сети после отправки полного запроса, но до получения ответа — и клиент не знает про таймаут. перевод на connection pool под реальной нагрузкой даёт segfault'ы из-за обгонов. в ихней багбазе уже с десяток тикетов и фиксов на эти проблемы, но они всё равно не вылечены. в результате на клиентское соединение порождаем промежуточный процесс, который не жалко убить.
5) получили жёсткую привязку к RHEL, который отстаёт по куче софта.

И это я ещё не вспоминаю проблемы собственно DBA, и дублирование текстов запросов серьёзнее, чем "select foo from bar". Я давно уже жалею, что перед этим отказались от постгреса.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Только вот ты по поводу аппрува линуксового софта не ответил — там что, аппрувить не надо?

У меня пока не было в этом необходимости. Но, чувствую, что политика MS к этому приведёт.

... << RSDN@Home 1.2.0 alpha 5 rev. 69>>

Здравствуйте, Cyberax, Вы писали:

C>Ну дык. Местный банк какого-нибудь Задрищенска с сервером под DB2 на древнем AS/400, который они купили 10 лет назад — это серьёзная система. А Google с парой сотен тысяч серверов с NoSQL — это несерьёзные хиппи. Знакомо, да.

Ты уже много лет не можешь понять, для чего нужны sql сервера. Гугль использует nosql для хранения слабоструктурированной информации, sql сервера нужны для хорошо структурированной информации (и оптимизатор значительный эффект тоже дает именно на хорошо структурированной информации).

НС>>У тебя опять какая нибудь специфическая задача, нужная 0.01% инсталляций sql серверов.
C>Конкретно PostgreSQL у меня для вполне классических реляционных проблем (учёт задач, метаданные и т.п.).

Т.е. смешные объемы, поэтому косяки оптимизатора просто не заметны, если специально их не искать.

C> В NoSQL у меня хранится петабайт данных

Дай угадаю — слабо структурированных?

C>1) Ещё как ставятся.

Только идиотами, способными доверить критичную информацию стороннему дяде.

C>2) Количество инсталляций PostgreSQL и MySQL точно больше DB2

А в деньгах?

C>Я вообще сейчас слабо понимаю смысл использования DB2 и Oracle

Об этом и речь.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Ты уже много лет не можешь понять, для чего нужны sql сервера. Гугль использует nosql для хранения слабоструктурированной информации, sql сервера нужны для хорошо структурированной информации (и оптимизатор значительный эффект тоже дает именно на хорошо структурированной информации).
Неверно. NoSQL прекрасно может использоваться для структурированной информации, по которой надо делать сложные запросы. Использование NoSQL часто требуется из-за гигантского объёма данных, по которому обычные реляционные запросы просто непрактичны.

И оптимизатор тут совершенно пофиг.

НС>>>У тебя опять какая нибудь специфическая задача, нужная 0.01% инсталляций sql серверов.
C>>Конкретно PostgreSQL у меня для вполне классических реляционных проблем (учёт задач, метаданные и т.п.).
НС>Т.е. смешные объемы, поэтому косяки оптимизатора просто не заметны, если специально их не искать.
Ну да. И это единственно правильный подход.

Если в проекте подтирать штанишки за оптимизатором, то с большой вероятностью стоит использовать что-то другое. Так как масштабируемость такого подхода хромает — РСУБД не умеют нормально параллелизовать запросы (не говоря уж о настоящем массивном распределённом исполнении), так что как только объём данных станет слишком большим для одного узла, то всё.

C>> В NoSQL у меня хранится петабайт данных
НС>Дай угадаю — слабо структурированных?
Разных. Есть и очень структурированные графы, есть и почти неструктурированный "текст".

C>>1) Ещё как ставятся.
НС>Только идиотами, способными доверить критичную информацию стороннему дяде.
LOL. Такой паранойей страдают, в основном, только банки. Нормальные компании не заморачиваются такой хренью.

C>>2) Количество инсталляций PostgreSQL и MySQL точно больше DB2
НС>А в деньгах?
У PostgreSQL цена — $0...

Ну и выбирать БД по её цене — это как-то совсем по-олимпийски в Сочи.

C>>Я вообще сейчас слабо понимаю смысл использования DB2 и Oracle
НС>Об этом и речь.
MSSQL ради него самого — туда же.

Здравствуйте, Cyberax, Вы писали:

C>Если в проекте подтирать штанишки за оптимизатором, то с большой вероятностью стоит использовать что-то другое.

А за этим чем-то другим не приходится штанишки подтирать? К примеру, гоняя раз в неделю скрипт, проверяющий логическую целостность NoSQL-базы, не поддерживающей FK.

Мы в курсе — по этому пишем до сих пор на С/C++ — и нам как-то пофиг — Windows/Linux/Mac или что-то еще это... х) Все компилируется под все платформы с требуемой скоростью работы без overhead — а детали платформы невелируются базовыми системными компонентами... х)

Здравствуйте, dimgel, Вы писали:

C>>Если в проекте подтирать штанишки за оптимизатором, то с большой вероятностью стоит использовать что-то другое.
D>А за этим чем-то другим не приходится штанишки подтирать? К примеру, гоняя раз в неделю скрипт, проверяющий логическую целостность NoSQL-базы, не поддерживающей FK.
Угу. Тоже верный признак того, что что-то в технологии не так было выбрано.

Здравствуйте, Cyberax, Вы писали:

C>Неверно.

Верно.

C> NoSQL прекрасно может использоваться для структурированной информации

При этом страшно сливать классическим реляционным серверам.

C>И оптимизатор тут совершенно пофиг.

Вот я и говорю — когда оптимизатор пофиг, тогда можно и nosql.

НС>>Т.е. смешные объемы, поэтому косяки оптимизатора просто не заметны, если специально их не искать.
C>Ну да. И это единственно правильный подход.

Вот только задачи бывают разными.

C>>> В NoSQL у меня хранится петабайт данных
НС>>Дай угадаю — слабо структурированных?
C>Разных. Есть и очень структурированные графы, есть и почти неструктурированный "текст".

Ну то есть таки слабо стурктурированных. ЧТД.

НС>>Только идиотами, способными доверить критичную информацию стороннему дяде.
C>LOL. Такой паранойей страдают, в основном, только банки. Нормальные компании не заморачиваются такой хренью.

А, ну ну.

C>>>2) Количество инсталляций PostgreSQL и MySQL точно больше DB2
НС>>А в деньгах?
C>У PostgreSQL цена — $0...

Не все так просто.

C>Ну и выбирать БД по её цене — это как-то совсем по-олимпийски в Сочи.

Это совершенно нормальный подход.

Здравствуйте, Cyberax, Вы писали:

D>>А за этим чем-то другим не приходится штанишки подтирать? К примеру, гоняя раз в неделю скрипт, проверяющий логическую целостность NoSQL-базы, не поддерживающей FK.
C>Угу. Тоже верный признак того, что что-то в технологии не так было выбрано.

Ну и какую технологию ты бы выбрал, если данных петабайт сильно связанных данных?

Здравствуйте, dimgel, Вы писали:

D>>>А за этим чем-то другим не приходится штанишки подтирать? К примеру, гоняя раз в неделю скрипт, проверяющий логическую целостность NoSQL-базы, не поддерживающей FK.
C>>Угу. Тоже верный признак того, что что-то в технологии не так было выбрано.
D>Ну и какую технологию ты бы выбрал, если данных петабайт сильно связанных данных?
Это интересный вопрос, который зависит от структуры данных.

Здравствуйте, Ночной Смотрящий, Вы писали:

C>> NoSQL прекрасно может использоваться для структурированной информации
НС>При этом страшно сливать классическим реляционным серверам.
Нет. Часто NoSQL работает на таких объёмах, где РБД просто не работают. Для примера, recommendation engine в Amazon работает со структурированными данными (информация о покупке), но на таких гигантских объёмах, что это реально только с custom-ным map/reduce движком.

В Foursqure основной тип данных — это обычные географические координаты. Тем не менее, РБД не справляются даже близко.

C>>И оптимизатор тут совершенно пофиг.
НС>Вот я и говорю — когда оптимизатор пофиг, тогда можно и nosql.
Оптимизатор может улучшить производительность в несколько раз. Это тривиально для большинства NoSQL — тупо берём немного больше узлов.

НС>>>Дай угадаю — слабо структурированных?
C>>Разных. Есть и очень структурированные графы, есть и почти неструктурированный "текст".
НС>Ну то есть таки слабо стурктурированных. ЧТД.
Что именно слабо структурировано в графах?

C>>>>2) Количество инсталляций PostgreSQL и MySQL точно больше DB2
НС>>>А в деньгах?
C>>У PostgreSQL цена — $0...
НС>Не все так просто.
Ну так как будем сравнивать?

C>>Ну и выбирать БД по её цене — это как-то совсем по-олимпийски в Сочи.
НС>Это совершенно нормальный подход.
Для дядей в "серьёзных" компаниях, где пофиг на разработчиков и реальную эффективность? Ага.

Здравствуйте, Cyberax, Вы писали:

D>>Ну и какую технологию ты бы выбрал, если данных петабайт сильно связанных данных?
C>Это интересный вопрос, который зависит от структуры данных.

Угу. Но какую бы ты ни выбрал, компенсировать её недостатки костылями тебе в любом случае придётся, если захочешь выжать из неё максимум. Тут как раз на днях неподалёку CAP-теорему вспоминали — что в общем по сути своей о том же: убить всех зайцев одним выстрелом невозможно.

Здравствуйте, Cyberax, Вы писали:

НС>>При этом страшно сливать классическим реляционным серверам.
C>Нет. Часто NoSQL работает на таких объёмах, где РБД просто не работают.

А кто то спорил?

C> Для примера, recommendation engine в Amazon работает со структурированными данными (информация о покупке)

Но работает он с ними как со слабо структурированными. Data mining — одна из классических задачек для нереляционных БД — много в память поднимать сравнительно простых по структуре данных, часто довольно разнородных, и потом их перелопачивать. На таких задачах толку от реляционных северов действительно немного. А вот когда у тебя в запросе сотня джойнов по разнотипным данным, тут nosql подохнет на сравнительно скромных объемах.

НС>>Вот я и говорю — когда оптимизатор пофиг, тогда можно и nosql.
C>Оптимизатор может улучшить производительность в несколько раз.

Он на несколько порядков ее может улучшить.

C> Это тривиально для большинства NoSQL — тупо берём немного больше узлов.

И транзакцию ты тоже по нескольким узлам размазывать будешь? Ах да, какие транзакции в nosql

C>>>Разных. Есть и очень структурированные графы, есть и почти неструктурированный "текст".
НС>>Ну то есть таки слабо стурктурированных. ЧТД.
C>Что именно слабо структурировано в графах?

Типов узлов и связей не очень много. Тебе, небось, их и читать нужно большими сериями с довольно тяжелой для CPU/памяти обработкой, да?

НС>>Не все так просто.
C>Ну так как будем сравнивать?

Не знаю. Вопрос весьма непростой.

НС>>Это совершенно нормальный подход.
C>Для дядей в "серьёзных" компаниях, где пофиг на разработчиков и реальную эффективность? Ага.

Понимаешь ли, дорогой, есть много разных задач. Где то выгоднее распределенные nosql хранилища, где то нужны реляционные сервера. Если ты с последним не сталкивался, это не значит что оно никому не нужно. Но ты можешь продолжать верить в толпу дядей-идиотов в корпорациях, не знающих о таком всемогутере как очередная nosql базка, и в толпу девелоперов, которые вливают огромное бабло в mssql, oracle, postgres и т.п.

Здравствуйте, Ночной Смотрящий, Вы писали:

C>> Для примера, recommendation engine в Amazon работает со структурированными данными (информация о покупке)
НС>Но работает он с ними как со слабо структурированными. Data mining — одна из классических задачек для нереляционных БД — много в память поднимать сравнительно простых по структуре данных, часто довольно разнородных, и потом их перелопачивать. На таких задачах толку от реляционных северов действительно немного. А вот когда у тебя в запросе сотня джойнов по разнотипным данным, тут nosql подохнет на сравнительно скромных объемах.
Если у меня в запросе будет сотня джойнов, то скорее всего, я убегу нафиг из такого проекта. Такие запросы стоит писать на чём-то, что лучше чем SQL.

НС>>>Вот я и говорю — когда оптимизатор пофиг, тогда можно и nosql.
C>>Оптимизатор может улучшить производительность в несколько раз.
НС>Он на несколько порядков ее может улучшить.
По сравнению с отсутствием оптимизатора, да. По сравнению с оптимизатором Postgres — вряд ли.

C>> Это тривиально для большинства NoSQL — тупо берём немного больше узлов.
НС>И транзакцию ты тоже по нескольким узлам размазывать будешь? Ах да, какие транзакции в nosql

Можно и по нескольким узлам. Можно и с eventual consistency — зависит от задачи.

C>>Что именно слабо структурировано в графах?
НС>Типов узлов и связей не очень много. Тебе, небось, их и читать нужно большими сериями с довольно тяжелой для CPU/памяти обработкой, да?
По-разному, в части случаев просто надо делать простейшие вещи, типа нахождения объединения частично перекрывающихся отрезков. В других случаях приходится делать тяжёлые вычисления. Потом ещё есть запросы, которые нужно делать по хитрым параметрам и в realtime.

НС>>>Это совершенно нормальный подход.
C>>Для дядей в "серьёзных" компаниях, где пофиг на разработчиков и реальную эффективность? Ага.
НС>Понимаешь ли, дорогой, есть много разных задач. Где то выгоднее распределенные nosql хранилища, где то нужны реляционные сервера.
Я вообще-то утверждал, что преимущества использования серверов "большой тройки" уже практически исчезли. А их недостатки как были, так и остались.

Я не утверждал, что SQL совсем не нужен.

Здравствуйте, IT, Вы писали:

IT>Некоторым это всё, конечно, покажется страшилками, но против фактов не попрёшь. Не бывает так, чтобы платформа потихоньку сдавала свои позиции, сдавала, сдавала, а потом раз и всех заборола! Хрен вам! Пока мы устойчиво катимся вниз и наклон только увеличивается.

А совсем недавно ты с этим яростно спорил. Забрало что ли приподнял ?

Здравствуйте, Cyberax, Вы писали:

C>Если у меня в запросе будет сотня джойнов, то скорее всего, я убегу нафиг из такого проекта.

ЧТД.

НС>>Он на несколько порядков ее может улучшить.
C>По сравнению с отсутствием оптимизатора, да. По сравнению с оптимизатором Postgres — вряд ли.

Я пару порядков ловил даже на Оракле из-за косяков оптимизатора, хоть и не часто. Так что на постгри — без проблем.

НС>>Понимаешь ли, дорогой, есть много разных задач. Где то выгоднее распределенные nosql хранилища, где то нужны реляционные сервера.
C>Я вообще-то утверждал, что преимущества использования серверов "большой тройки" уже практически исчезли.

Тут главное — верить.

Здравствуйте, Ikemefula, Вы писали:

IT>>Некоторым это всё, конечно, покажется страшилками, но против фактов не попрёшь. Не бывает так, чтобы платформа потихоньку сдавала свои позиции, сдавала, сдавала, а потом раз и всех заборола! Хрен вам! Пока мы устойчиво катимся вниз и наклон только увеличивается.

I>А совсем недавно ты с этим яростно спорил. Забрало что ли приподнял ?

С чем именно я спорил? И когда недавно?

... << RSDN@Home 1.2.0 alpha 5 rev. 69>>

Здравствуйте, IT, Вы писали:

IT>>>Некоторым это всё, конечно, покажется страшилками, но против фактов не попрёшь. Не бывает так, чтобы платформа потихоньку сдавала свои позиции, сдавала, сдавала, а потом раз и всех заборола! Хрен вам! Пока мы устойчиво катимся вниз и наклон только увеличивается.

I>>А совсем недавно ты с этим яростно спорил. Забрало что ли приподнял ?

IT>С чем именно я спорил? И когда недавно?

В этом году примерно

На счет впф, сильверлайта и тд.

Здравствуйте, Ikemefula, Вы писали:

I>>>А совсем недавно ты с этим яростно спорил. Забрало что ли приподнял ?
IT>>С чем именно я спорил? И когда недавно?
I>В этом году примерно

На счет впф, сильверлайта и тд.

Ну давай уже, признавайся, что там было? Нам всем жутко интересно!

... << RSDN@Home 1.2.0 alpha 5 rev. 69>>

Здравствуйте, IT, Вы писали:

I>>>>А совсем недавно ты с этим яростно спорил. Забрало что ли приподнял ?
IT>>>С чем именно я спорил? И когда недавно?
I>>В этом году примерно

На счет впф, сильверлайта и тд.

IT>Ну давай уже, признавайся, что там было? Нам всем жутко интересно!

Еще про энтерпрайз чтото было. Поиском не могу найти, подфикси его что ли ?

Вставлю свои "пять копеек".
Дубовые простые NoSql решения в среднем в 100-300 раз быстрее работают чем теже на MS-SQL/Oracle/Postrges и др.
Это проверено эксперментальным путем и инфы море, вот например: http://blog.pikosec.com/?p=14.

Оптимизатор тут нипричем, запросы простые, оптимизатору просто негде чудить.
Суть — в стандартных СУБД слишком много оверхеда процессорных комманд.

Здравствуйте, Ikemefula, Вы писали:

IT>>Ну давай уже, признавайся, что там было? Нам всем жутко интересно!

I>Еще про энтерпрайз чтото было. Поиском не могу найти, подфикси его что ли ?

Видимо я говорил, что Silverlight как web-based решение со страшной силой рулит в корпоративной среде. Ну так я от этого и не отказываюсь. Аналогов действительно нет. Пока нет. Но MS делает всё, чтобы убить эту технологию.

... << RSDN@Home 1.2.0 alpha 5 rev. 69>>

Здравствуйте, IT, Вы писали:

IT>С чем именно я спорил? И когда недавно?

В конце прошлого года еще был спор на тему: дотнет вс джава и всех уверял, что дотнет всех заруливает, а джава — говно мамонта.
А оказывается то немного наоборот.

Здравствуйте, IT, Вы писали:

IT>Видимо я говорил, что Silverlight как web-based решение со страшной силой рулит в корпоративной среде. Ну так я от этого и не отказываюсь. Аналогов действительно нет. Пока нет. Но MS делает всё, чтобы убить эту технологию.

Как это нет аналогов?!

Всё началось ещё с аплетов. Но MS с ними старательно боролся путём выкорчёвывания Джава.

А сейчас несколько RIA технологий. Вот сравнение.. Сейчас у них у всех главный враг это HTML5. Который хайманагеры считают адекватной заменой. И который действительно ею является для простых случаев.

Здравствуйте, xRAZORx, Вы писали:

RAZ>Здравствуйте, IT, Вы писали:

IT>>С чем именно я спорил? И когда недавно?

RAZ>В конце прошлого года еще был спор на тему: дотнет вс джава и всех уверял, что дотнет всех заруливает, а джава — говно мамонта.
RAZ>А оказывается то немного наоборот.

Не оказывается, джава как была говном мамонта, так им же и остается

Здравствуйте, Steamus, Вы писали:

S>Как это нет аналогов?!

То, что оно есть ещё не значит что оно рулит со страшной силой. Например, флеш в корпоративной среде рулит только для создания учебных роликов. Для всего остального он со страшной силой не рулит.

S>А сейчас несколько RIA технологий. Вот сравнение.. Сейчас у них у всех главный враг это HTML5. Который хайманагеры считают адекватной заменой. И который действительно ею является для простых случаев.

Несколько за исключением HTML5/JS и SL это каличный Flash и JavaFX, для которого я ни разу в жизни не видел ни одного приложения?

... << RSDN@Home 1.2.0 alpha 5 rev. 69>>

Здравствуйте, xRAZORx, Вы писали:

IT>>С чем именно я спорил? И когда недавно?
RAZ>В конце прошлого года еще был спор на тему: дотнет вс джава и всех уверял, что дотнет всех заруливает, а джава — говно мамонта.

Я тебя и сейчас могу в этом поуверять.

RAZ>А оказывается то немного наоборот.

Пока джаве на десктопе до .net как раком до Парижа. Но мне категорически не нравятся тенденции. Именно об этом я тут и толкую.

... << RSDN@Home 1.2.0 alpha 5 rev. 69>>

Здравствуйте, IT, Вы писали:

IT>Несколько за исключением HTML5/JS и SL это каличный Flash и JavaFX, для которого я ни разу в жизни не видел ни одного приложения?

JavaFX — уже очень интересный инструмент (а в восьмёрке ещё и 3D будет, уже пошли бета версии). Но молодой совсем. Пары лет нету. Оракл завернул старый JavaFX, убрал скриптовой язык (вместо него обычная Java) и выпустил JavaFX2. И вполне шустро развивает. Включая инструменты построения интерфейсов. Там и аналог XAML (FXML) и CSS стилизация и биндинг в XML и разные формы деплоймента (включая заворачивания приложения в родной формат OS и расположение нужного рантайма рядом вне конфликта с уже установленным в системе). Ну и общий подход современный. Сцена, разные трансформации...

Будут приложения. Уже пошли потихоньку.

Здравствуйте, IT, Вы писали:

IT>Я тебя и сейчас могу в этом поуверять.

Мне хватило того, что в нуерке везде жаба используется.

IT>Пока джаве на десктопе до .net как раком до Парижа. Но мне категорически не нравятся тенденции. Именно об этом я тут и толкую.

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

Здравствуйте, IT, Вы писали:

IT>Пока джаве на десктопе до .net как раком до Парижа.
Уже нет. Выше писал про JavaFX2. Не верите — проверьте, ознакомьтесь. Нет уже явного превосходства. JavaFX2 порой сыроват, но и WPF за много лет не так уж что бы и вылизан. Оракл очень агрессивно продвинул новую технологию.

Здравствуйте, Steamus, Вы писали:

S>Здравствуйте, IT, Вы писали:

IT>>Пока джаве на десктопе до .net как раком до Парижа.
S>Уже нет. Выше писал про JavaFX2. Не верите — проверьте, ознакомьтесь. Нет уже явного превосходства. JavaFX2 порой сыроват, но и WPF за много лет не так уж что бы и вылизан. Оракл очень агрессивно продвинул новую технологию.

Похоже у человека синдром утенка.

Здравствуйте, xRAZORx, Вы писали:

RAZ>Десктоп никогда не был сильным местом джавы. Вот сервер — другой разговор, там ситуация ровно обратная.

Что там у них такого на сервере космического? Что на сервере вообще может быть космического? У них там даже линка нет. Каменный век, однако.

... << RSDN@Home 1.2.0 alpha 5 rev. 69>>

Здравствуйте, Steamus, Вы писали:

IT>>Пока джаве на десктопе до .net как раком до Парижа.
S>Уже нет. Выше писал про JavaFX2. Не верите — проверьте, ознакомьтесь. Нет уже явного превосходства. JavaFX2 порой сыроват, но и WPF за много лет не так уж что бы и вылизан. Оракл очень агрессивно продвинул новую технологию.

Верю

... << RSDN@Home 1.2.0 alpha 5 rev. 69>>

Здравствуйте, xRAZORx, Вы писали:

RAZ>Здравствуйте, IT, Вы писали:

IT>>Пока джаве на десктопе до .net как раком до Парижа. Но мне категорически не нравятся тенденции. Именно об этом я тут и толкую.

RAZ>Десктоп никогда не был сильным местом джавы. Вот сервер — другой разговор, там ситуация ровно обратная.

Это не заслуга джавы, а линукса, как основной серверной ОС.

Здравствуйте, Klikujiskaaan, Вы писали:

K>Похоже у человека синдром утенка.

Согласен. У НЕТовцев он распространён. Одна первая и любимая компания затмевает им весь разнообразный и красивый окружающий мир.

Здравствуйте, MainLang, Вы писали:

ML>Вставлю свои "пять копеек".
ML>Дубовые простые NoSql решения в среднем в 100-300 раз быстрее работают чем теже на MS-SQL/Oracle/Postrges и др.
ML>Это проверено эксперментальным путем и инфы море, вот например: http://blog.pikosec.com/?p=14.
ML>Оптимизатор тут нипричем, запросы простые, оптимизатору просто негде чудить.
ML>Суть — в стандартных СУБД слишком много оверхеда процессорных комманд.

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

P.S. ты блог что ли рекламируешь ?

Здравствуйте, Steamus, Вы писали:

K>>Похоже у человека синдром утенка.

S>Согласен. У НЕТовцев он распространён. Одна первая и любимая компания затмевает им весь разнообразный и красивый окружающий мир.

Я попрошу без инсинуаций. .NET-чики хотя бы способны на критику как MS в целом, так и .NET в частности. Наше ворчание им только на пользу.

... << RSDN@Home 1.2.0 alpha 5 rev. 69>>

Здравствуйте, alex_public, Вы писали:

_>Здравствуйте, Ночной Смотрящий, Вы писали:

НС>>Чтобы пользоваться продукцией серверного и девтульного дивиженов.

_>Вот на десктопе это реально аргумент. А на серверах что за софт такой нужный есть под виндой и нет под линухом?

Sharepoint, например

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

Здравствуйте, IT, Вы писали:

Эх, поднять бы местное хистори и посмотреть на твоё отношение к линупсу и виндам в эпоху эпичных войн, но лень. Может сам расскажешь?

зы. Действительно интересно, безо всякого троллинга и издевок.

Здравствуйте, Sheridan, Вы писали:

S>Что жаба, что шарпы — легкие в освоении языки. Но к сожалению большинство погроммистов ленивы и предпочитают на этом останавляваться, вместо того что бы идти дальше в сторону более производительного кода. Да, я про с++.

А окупится ли им резкий всплеск возни с ситуациями типа "программа спекла корку, ибо куча разрушена, а кем и когда — ХЗ", "задолбался понимать, как именно считать ссылки на этот объект — тут у меня получается 4-6 разных уровней владения" и т.п.?

Здравствуйте, IT, Вы писали:

IT>Могу сказать про банки в штатах. .NET с серверов приложений полностью выдавлен джавой. Web-технологии 50/50. Десктоп пока за .NET. Но тенденции печальные.

Похожая ситуация и у нас. Года 3 назад было 50/50 винда+дотнет и линух+жаба. Сейчас на винде и дотнете осталась довольно ничтожная часть серверов, а дотнетчики попереквалифицировались в скалистов-джавистов. Только у нас серваки в основном в EU, ну немного еще в США и в Азии(но про эти знаю меньше всего, т.к. мы с азиатской частью меньше всего взаиодействуем). Меньшая причина — в довольно убогих возможностях Винды к кастомизации(ну и вообще тулзы админимстрирования там как и все в Винде — чуть отход от стандартного, предопределенного МС сценария, и получите тонну геморроя на ровном месте). Большая — в совершенно уродским саппортом МС в последнее время, причем с каждым годом все хуже и хуже(и это еще один сук, который МС методично рубит в последнее время).

Здравствуйте, netch80, Вы писали:

N>А окупится ли им резкий всплеск возни с ситуациями типа "программа спекла корку, ибо куча разрушена, а кем и когда — ХЗ", "задолбался понимать, как именно считать ссылки на этот объект — тут у меня получается 4-6 разных уровней владения" и т.п.?
Не нанимайте студентов

Здравствуйте, a_g_99, Вы писали:

__>1) Прошли те времена когда win занимала 85% на рынке ОС. Наступили времена, когда основные конкуренты Apple и Google захватили уже более половины рынка. И каждый из них продвигает свою платформу (objC & java соответственно), которая отбирает разработчиков у MS. В конце концов MS придется идти по пути oracle мигрируя свои флагманские продукты под наиболее famous операционное окружение, если они хотят выжить. И потребуется платформа для разработки под эти продукты. Винда кстати приносит лишь четверть доходов MS.

поставил минус за выделенное слово. всегда бесит.

Здравствуйте, Sheridan, Вы писали:

N>>А окупится ли им резкий всплеск возни с ситуациями типа "программа спекла корку, ибо куча разрушена, а кем и когда — ХЗ", "задолбался понимать, как именно считать ссылки на этот объект — тут у меня получается 4-6 разных уровней владения" и т.п.?
S>Не нанимайте студентов

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

Вот прямо сейчас у меня на глазах происходит с одним из проектов:
1. Разработчик Р., вредный, но опытный, ушёл на повышение (грубо говоря, team lead), занимается, кроме текущей админвозни, разработкой кастомных средств для автоматизации работы группы.
2. Разработчик Т., опытный и спокойный, загружен на >100%.
3. Разработчик Ш., с некоторым опытом, но не сильно ушедший от уровня студента (а главное — без кругозора, который даётся только прошлой деятельностью в других видах работ), выдаёт очень странные решения, пропускает важные детали и чаще, чем хотелось бы, спрашивает коллег по самым разным мелочам.

Проблема 1 была в итоге опознана так, что тред, работающий с соединением, молча мрёт, а его штатная оболочка, взятая из распиаренной библиотеки, не в состоянии обеспечить даже минимального RAII на ресурсы, которые она использует, и в результате сокет болтается в состоянии процесса, никому не нужный; приходится наворачивать уже свой слой врапперов на уровень ниже их оболочки, причём Р., который продолжает быть в ревьюерах, задаёт кучу вредных вопросов, на которые Ш. не знает, как ответить.

Проблема 2 в логике той же распиаренной библиотеки заключается в том, что если прекратилась передача потока данных по соединению, то она молча сохраняет этот факт в себе, не блокируя отправителя, но теряя данные; когда же происходит рестарт источника, она считает себя вправе заблокировать рестарт, пока выходные буферы не очистятся (чего, понятно, не происходит).

И если уж надо было "не нанимать студентов", то это надо было делать не на нашем уровне, а у авторов библиотеки, которые сами оказались студентами, несмотря на бороду и регалии.

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

С кадрами тяжко, да.

Здравствуйте, Sheridan, Вы писали:

S>Не нанимайте студентов

Ты это основу русского програмерского бизнеса не трожь — студенты это святое, можно не платить, навешать лапши на уши про крутизну конторы, ну а код... как-то работает, ну и хер с ним.

Здравствуйте, Sheridan, Вы писали:

S>Что жаба, что шарпы — легкие в освоении языки. Но к сожалению большинство погроммистов ленивы и предпочитают на этом останавляваться, вместо того что бы идти дальше в сторону более производительного кода. Да, я про с++.

Всё как правило несколько наоборот, по крайней мере в моём поколении +/- (в т.ч. у многих тутошних гуру): сначала C++, а потом изучается java/C# и C++ выбрасывается, потому что большинству программистов лениво ломать об него пальцы.

Здравствуйте, senglory, Вы писали:

S>Sharepoint, например

Вот его бы я, как раз, а пример не приводил. В природе достаточно кроссплатформенных CMS, которые как минимум не хуже.
Зато за прошедший с момента прошлого общения год существенно окрепли средства создания сравнительно тяжелых веб-решений — улучшается MVC, Katana/OWIN, Web Optimization Framework и т.д. TypeScript опять же.

Здравствуйте, dimgel, Вы писали:

D>Всё как правило несколько наоборот, по крайней мере в моём поколении +/- (в т.ч. у многих тутошних гуру): сначала C++, а потом изучается java/C# и C++ выбрасывается, потому что большинству программистов лениво ломать об него пальцы.

Ага, так и есть. Правда надо уточнить, что эти товарищи C++ так и не изучили к этому времени...

Здравствуйте, alex_public, Вы писали:

D>>Всё как правило несколько наоборот, по крайней мере в моём поколении +/- (в т.ч. у многих тутошних гуру): сначала C++, а потом изучается java/C# и C++ выбрасывается, потому что большинству программистов лениво ломать об него пальцы.

_>Ага, так и есть. Правда надо уточнить, что эти товарищи C++ так и не изучили к этому времени...

Несколько лет работы считается за "так и не изучили"?

Здравствуйте, alex_public, Вы писали:

N>>А окупится ли им резкий всплеск возни с ситуациями типа "программа спекла корку, ибо куча разрушена, а кем и когда — ХЗ", "задолбался понимать, как именно считать ссылки на этот объект — тут у меня получается 4-6 разных уровней владения" и т.п.?
_>Что-то это больше C напоминает, а не современный C++. )

Современный — это 11 или 14? А если половина кода не дотягивает даже до уровня 98?

Здравствуйте, dimgel, Вы писали:

D>Несколько лет работы считается за "так и не изучили"?

А годы тут ни при чём — можно много лет сидеть и программировать на C с классами, только при этом знать C++ по прежнему не будешь. )

Можно ввести критерий знания например так: если спокойно читаешь все исходники Boost'a и можешь сам писать подобное.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Здравствуйте, senglory, Вы писали:

S>>Sharepoint, например

НС>Вот его бы я, как раз, а пример не приводил. В природе достаточно кроссплатформенных CMS, которые как минимум не хуже.

1. А кто вам сказал, что шарик — это CMS?
2. Не слышал про коммерчески удачные его аналоги.

НС>Зато за прошедший с момента прошлого общения год существенно окрепли средства создания сравнительно тяжелых веб-решений — улучшается MVC, Katana/OWIN, Web Optimization Framework и т.д. TypeScript опять же.

Простите, а какое отношение эта хренотень имеет к организации документооборота из коробки?

Здравствуйте, netch80, Вы писали:

N>Современный — это 11 или 14?

А там разницы почти нет. Т.е. В 14 всего лишь подшлифовали некоторые неудачные реализации новинок 11 и собственно какого-то "перехода" вообще не намечается.

А вот 11 — это да, действительно существенный порог для понятия "современный C++".

N>А если половина кода не дотягивает даже до уровня 98?

Тогда вообще мрак. ))) Но какое это имеет отношение к данной дискуссии? )

Здравствуйте, alex_public, Вы писали:

_>А годы тут ни при чём — можно много лет сидеть и программировать на C с классами, только при этом знать C++ по прежнему не будешь. )

_>Можно ввести критерий знания например так: если спокойно читаешь все исходники Boost'a и можешь сам писать подобное.

Учитывая, что я тут про этот буст наслушался, твой критерий можно переформулировать применительно к программированию вообще так: "~~кто не прыгал из окошка вместе с маминым зонтом~~ кто не писал на брейнфаке ничего сложнее 10 тыс строк, тот лихим парашютистом не считается пока". Я вот не застал template-извратов — и слава богу.

Здравствуйте, alex_public, Вы писали:

_>Можно ввести критерий знания например так: если спокойно читаешь все исходники Boost'a и можешь сам писать подобное.

а в чём радость чтения и создания костылей для (скажем прямо) убогенького языка?
ведь даже новый стандарт двинулся в сторону как раз тех языков, которые так презираемы Sheridan'ом

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

а кто готов писать на плюсах, кроме зелёных студентов с горящими глазами?
ведь с опытом огонь в глазах погаснет, и они уйдут на более другие языки.

Здравствуйте, Yoriсk, Вы писали:

Y>Вот игроделы — сталкиваются, результаты видны.

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

Здравствуйте, dimgel, Вы писали:

D>Учитывая, что я тут про этот буст наслушался, твой критерий можно переформулировать применительно к программированию вообще так: "~~кто не прыгал из окошка вместе с маминым зонтом~~ кто не писал на брейнфаке ничего сложнее 10 тыс строк, тот лихим парашютистом не считается пока". Я вот не застал template-извратов — и слава богу.

Вот вот, классическая позиция тех, кто не разобрался. )

Здравствуйте, alex_public, Вы писали:

_>Здравствуйте, dimgel, Вы писали:

D>>Учитывая, что я тут про этот буст наслушался, твой критерий можно переформулировать применительно к программированию вообще так: "~~кто не прыгал из окошка вместе с маминым зонтом~~ кто не писал на брейнфаке ничего сложнее 10 тыс строк, тот лихим парашютистом не считается пока". Я вот не застал template-извратов — и слава богу.

_>Вот вот, классическая позиция тех, кто не разобрался. )

Нормальные люди предпочитают использовать удобные и незаумные инструменты. Это удел гиков — гордиться, что разобрался в чём-то заумном. Точно так же как адепты php любят аргумент "хороший спец может писать на чём угодно". Хороший спец умеет выбрать себе инструмент, а не тратить свою жизнь, "разбираясь".

Здравствуйте, neFormal, Вы писали:

F>а в чём радость чтения и создания костылей для (скажем прямо) убогенького языка?
F>ведь даже новый стандарт двинулся в сторону как раз тех языков, которые так презираемы Sheridan'ом

F>когда плюсы дойдут по встроенным возможностям хотя бы до современности, тогда и можно будет говорить об их величии

Ну покажи пример не убогенького языка, чтобы мы могли непосредственно сравнить... ) Я пока знаю ровно один язык, который имеет возможности сильнее C++. Это язык D. Но к сожалению он пока не имеет развитой инфраструктуры, так что пока в большинстве случаев не может быть выбран в качестве инструмента в серьёзных проектах.

Здравствуйте, IT, Вы писали:

IT>На десктопе ситуация похожая. WPF мёртв и замену ему можно ждать только из мира джавы. Как только на горизонте появится что-нибудь достойное, то дотнетчиков попрут и с десктопа поганой метлой. А потом точно также встанет вопрос о нужности винды на десктопе.

C чего это WPF мертв?

Здравствуйте, IT, Вы писали:

IT>На десктопе ситуация похожая. WPF мёртв и замену ему можно ждать только из мира джавы

Ну прям. Дохера еще сиплюсплюсников, которые дружно ломанулись на Qt, а если хочется нормального высокоуровневого языка, есть HTML5/CSS3/Inline SVG/jQuery (либо чисто для GUI с нативным бэкендом, либо вообще в традиционную десктопную нишу влезть с веб-аппом). Джаваскрипт настолько же кривее шарпа (ИМХО, близкого к идеалу языка), насколько и сама джава. Нормального LINQ'а, во всяком случае, ни там, ни там нет. По-моему, если чего и следует ждать, так это когда интегрировать Webkit куда угодно станет проще — чтобы, значить, из джаваскрипта прямой доступ к любым данным иметь, а из бэкенда вызывать джаваскрипты с нативными параметрами и неявным Invoke'ом. Шансов на это куда больше, чем на то, что носорог Оракл сумеет завоевать десктоп.

Здравствуйте, alex_public, Вы писали:

_>Ну покажи пример не убогенького языка, чтобы мы могли непосредственно сравнить... )

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

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

_>Я пока знаю ровно один язык, который имеет возможности сильнее C++. Это язык D.

я боюсь даже спрашивать, что ещё, кроме однобуквенных языков ты знаешь?

_>Но к сожалению он пока не имеет развитой инфраструктуры

и нельзя использовать то, что уже есть под плюсы?
хороший язык, нечего сказать

Здравствуйте, Sheridan, Вы писали:

S>Что жаба, что шарпы — легкие в освоении языки. Но к сожалению большинство погроммистов ленивы и предпочитают на этом останавляваться, вместо того что бы идти дальше в сторону более производительного кода. Да, я про с++.

Легкость освоения вовсе не означает простоту языков. Так же как и простота — это вовсе не легко. Сложность плюсов не означает их крутость. Сложность плюсов прежде всего означает их кривизну и запутанность.

Здравствуйте, neFormal, Вы писали:

F>возьми практически любой современный язык и удивись. даже жалкоскрипт получше будет, как ни странно

Ага, ага... Как только переходим к конкретике, так сразу в кусты. Понятненько. )))

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

Это типа предположение, что буст медленный? Сразу чувствуется "серьёзный" специалист... )))

F>и нельзя использовать то, что уже есть под плюсы?
F>хороший язык, нечего сказать

А есть какой-то язык кроме плюсов, способный использовать инфраструктуру плюсов? )

Здравствуйте, alex_public, Вы писали:

F>>возьми практически любой современный язык и удивись. даже жалкоскрипт получше будет, как ни странно
_>Ага, ага... Как только переходим к конкретике, так сразу в кусты. Понятненько. )))

читать не умеем, отмахиваемся скобками? жалко

F>>но все эти россказни плюсеров мы давно слышали. плюсер не может отличить язык от платформы и дрожит за каждый такт, хотя активно использует буст.
F>>смешно и грустно. пожалеем их.
_>Это типа предположение, что буст медленный? Сразу чувствуется "серьёзный" специалист... )))

это факт
нет, конечно, есть быстрые части. там где не успели ничего особо навернуть сверху.

F>>и нельзя использовать то, что уже есть под плюсы?
F>>хороший язык, нечего сказать

_>А есть какой-то язык кроме плюсов, способный использовать инфраструктуру плюсов? )

неужели плюсеры не знают про биндинги?

Здравствуйте, dimgel, Вы писали:

D>Нормальные люди предпочитают использовать удобные и незаумные инструменты.
например молоток и стамеску
D>Это удел гиков — гордиться, что разобрался в чём-то заумном.
например станок с ЧПУ

D>Хороший спец умеет выбрать себе инструмент, а не тратить свою жизнь, "разбираясь".
Хороший спец использует современные инструменты, а не говно мамонта.

Здравствуйте, Sheridan, Вы писали:

S>Эх, поднять бы местное хистори и посмотреть на твоё отношение к линупсу и виндам в эпоху эпичных войн, но лень. Может сам расскажешь?

Моё отношение к линуксу, к джаве, к айфону и даже к EF очень простое — всё имеет право на жизнь. А если оно не нужно, то само умрёт.

F>когда плюсы дойдут по встроенным возможностям хотя бы до современности, тогда и можно будет говорить об их величии

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

Здравствуйте, _ABC_, Вы писали:

_AB>Кхм. И как это я умудрялся на сотне серверов СУБД менять централизованно настройки через консоль?..

Ты — молодец!

Здравствуйте, Abyx, Вы писали:

D>>Хороший спец умеет выбрать себе инструмент, а не тратить свою жизнь, "разбираясь".
A>Хороший спец использует современные инструменты, а не говно мамонта.

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

А вот буст ваш, как и весь C++ — это-таки говно мамонта, уж извините.

Здравствуйте, IncremenTop, Вы писали:

IT>C чего это WPF мертв?

А с чего это он жив?

Здравствуйте, dimgel, Вы писали:

D>Нормальные люди предпочитают использовать удобные и незаумные инструменты. Это удел гиков — гордиться, что разобрался в чём-то заумном. Точно так же как адепты php любят аргумент "хороший спец может писать на чём угодно". Хороший спец умеет выбрать себе инструмент, а не тратить свою жизнь, "разбираясь".

Сложность C++ не в заумности, а в костыльности. Т.е. это как бы тоже сложность, но совсем другого порядка.

Здравствуйте, alex_public, Вы писали:

_>Ну покажи пример не убогенького языка, чтобы мы могли непосредственно сравнить... ) Я пока знаю ровно один язык, который имеет возможности сильнее C++. Это язык D. Но к сожалению он пока не имеет развитой инфраструктуры, так что пока в большинстве случаев не может быть выбран в качестве инструмента в серьёзных проектах.

D — это перебинотованный и повсеместно загипсованный C++. На сегодняшний день есть только один язык всем языкам язык — Немерле. Но, к сожаления, у него своих проблем выше крыши.

Здравствуйте, IT, Вы писали:

IT>Сложность C++ не в заумности, а в костыльности. Т.е. это как бы тоже сложность, но совсем другого порядка.

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

Здравствуйте, neFormal, Вы писали:

F>читать не умеем, отмахиваемся скобками? жалко

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

F>это факт
F>нет, конечно, есть быстрые части. там где не успели ничего особо навернуть сверху.

"Специалист" конечно же не в курсе, что как бы много не навернуть при подобном способе программирования, то оно всё равно всё вырежется и заинлайнится на этапе компиляции... Понятно, понятно... )

F>неужели плюсеры не знают про биндинги?

Биндинги к C++ библиотекам? ) Становится всё интереснее и интереснее... )

Здравствуйте, IT, Вы писали:

IT>D — это перебинотованный и повсеместно загипсованный C++. На сегодняшний день есть только один язык всем языкам язык — Немерле. Но, к сожаления, у него своих проблем выше крыши.

До Немерле я так и не добрался к сожалению, в последнее время много других дел. Хотя общее представление имею (трудно его не иметь, обитая на этом форуме

). И насколько я понял, Немерле может служить заменой C++ только в весьма узкой области. А в основном направление C++ (в роли системного языка) не получится. В отличие от D, которые легко может исполнять и системную роль.

Здравствуйте, alex_public, Вы писали:

_>До Немерле я так и не добрался к сожалению, в последнее время много других дел. \

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

_>Хотя общее представление имею (трудно его не иметь, обитая на этом форуме

Здравствуйте, IT, Вы писали:

IT>Здравствуйте, alex_public, Вы писали:

_>>До Немерле я так и не добрался к сожалению, в последнее время много других дел. \

IT>Понимаю. Стандарная отмазка. Если на что-то нет денег, то их никогда и не будет. Если нет времени, то его тоже никогда не будет. Это главный принцип закона нехотения.

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

Здравствуйте, IT, Вы писали:

IT>Понимаю. Стандарная отмазка. Если на что-то нет денег, то их никогда и не будет. Если нет времени, то его тоже никогда не будет. Это главный принцип закона нехотения.

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

Здравствуйте, alex_public, Вы писали:

F>>читать не умеем, отмахиваемся скобками? жалко
_>Ну как только увижу хоть какую-то аргументацию, тогда может и перестану смеяться над твоими сообщениями. )

а сможешь увидеть?

F>>это факт
F>>нет, конечно, есть быстрые части. там где не успели ничего особо навернуть сверху.
_>

"Специалист" конечно же не в курсе, что как бы много не навернуть при подобном способе программирования, то оно всё равно всё вырежется и заинлайнится на этапе компиляции... Понятно, понятно... )

этапять

и ты меня ещё обвиняешь в незнании плюсов. бугага

F>>неужели плюсеры не знают про биндинги?

_>Биндинги к C++ библиотекам? ) Становится всё интереснее и интереснее... )

ты не знал, что они существуют? или что?
расскажи же, в чём подвох?

Здравствуйте, Abyx, Вы писали:

A>когда гугл с мозилой перепишут хром и фф

но зачем? чтобы доказать Abyx'у, что плюсы ущербны?
так они и так это знают. чай не от хорошей жизни за них взялись.

A>а пока на твоем недоязыке только формы с вебсервисами клепают — на него для серьезных вещей даже смотреть не стоит.

если ты про жалкоскрипт, который я помянул, то это только пример, что даже на нём пишется лучше и адекватней.

Здравствуйте, dimgel, Вы писали:

D>Несколько лет работы считается за "так и не изучили"?
Достаточно почитать срачи в разделе "О работе". Там многие разы было показано, что товарищи с опытом 10 и более лет С++ не знают, а вот опыт до 1 года рулит.

Здравствуйте, Vzhyk, Вы писали:

V>Достаточно почитать срачи в разделе "О работе". Там многие разы было показано, что товарищи с опытом 10 и более лет С++ не знают,

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

V>а вот опыт до 1 года рулит.

1/25/2014 7:02 PM, neFormal пишет:

> а кто готов писать на плюсах, кроме зелёных студентов с горящими глазами?
Пол форума здесь на плюсах пишут, вот только с одним нюансом: "не с
горящими глазами за миску доширака".

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, Vzhyk, Вы писали:

>> а кто готов писать на плюсах, кроме зелёных студентов с горящими глазами?
V>Пол форума здесь на плюсах пишут, вот только с одним нюансом: "не с
V>горящими глазами за миску доширака".

не, я не спорю, что где-то оно ещё нужно. но это и не та панацея, о которой говорят фанаты.

Здравствуйте, dimgel, Вы писали:

V>>Достаточно почитать срачи в разделе "О работе". Там многие разы было показано, что товарищи с опытом 10 и более лет С++ не знают,
D>Или забыли. Или с тех пор, когда они на нём последний раз кодили, он ~~сильно испортился в худшую сторону~~ оброс ещё большим количеством костылей.

теперь за знание С++ считают знание буста
как? вы не используете буст? вы что, похапэшник?

но если вспомнить, то на момент распространения буста были срачи о его необходимости. тогда говорили: "можно же самим написать нужное, зачем нам чужие костыли? скоро без буста шагу ступить не сможете"
как в воду глядели.

Здравствуйте, neFormal, Вы писали:

F>не, я не спорю, что где-то оно ещё нужно. но это и не та панацея, о которой говорят фанаты.
По тексту я этого не увидел, посему и вставил 5 копеек. А так, конечно, всему свое место.

Здравствуйте, neFormal, Вы писали:

F>теперь за знание С++ считают знание буста
F>как? вы не используете буст? вы что, похапэшник?
Мода же. А молодежь в первую очередь на моду реагирует.

Здравствуйте, neFormal, Вы писали:

A>>когда гугл с мозилой перепишут хром и фф

F>но зачем? чтобы доказать Abyx'у, что плюсы ущербны?
F>так они и так это знают. чай не от хорошей жизни за них взялись.

"не от хорошей жизни" — это требования к проекту.
то что они взялись за С++, а не за что-то другое, означает что все остальные языки под эти требования не подходят.

A>>а пока на твоем недоязыке только формы с вебсервисами клепают — на него для серьезных вещей даже смотреть не стоит.

F>если ты про жалкоскрипт, который я помянул, то это только пример, что даже на нём пишется лучше и адекватней.

я про то, что есть сложные проекты с 100500 строк кода и требованиями по производительности, для которых подходит только С++, и есть всякие мелкие проекты для которых подходит чтоугодно.

Здравствуйте, Abyx, Вы писали:

A>то что они взялись за С++, а не за что-то другое, означает что все остальные языки под эти требования не подходят.

или люди, которые за это берутся, не подходят под что-то другое

A>я про то, что есть сложные проекты с 100500 строк кода и требованиями по производительности, для которых подходит только С++, и есть всякие мелкие проекты для которых подходит чтоугодно.

халва-халва-халва

Здравствуйте, neFormal, Вы писали:

A>>то что они взялись за С++, а не за что-то другое, означает что все остальные языки под эти требования не подходят.

F>или люди, которые за это берутся, не подходят под что-то другое

A>>я про то, что есть сложные проекты с 100500 строк кода и требованиями по производительности, для которых подходит только С++, и есть всякие мелкие проекты для которых подходит чтоугодно.

F>халва-халва-халва

ок. допустим это так. программисты застрявшие в 80х-90х и т.п.

вот есть конкретные проекты — chrome(chromium) и webkit.
если бы их делали с нуля в 2014 году, на каких языках их надо писать чтобы получился хороший браузер (т.е. такой который смог бы занять хотя бы 5% рынка на всех популярных платформах)

из нативных императивных go/rust/D — еще сырые.
на функциональных (хаскел, окамл) вроде ничего таких масштабов еще не писали, и вообще мутабельный DOM наверное плохо сочетается с ФП.
из не-нативных — рендеринг на .NET/JVM будет тормозить и жрать тонны памяти, олсо с .NET дистрибутив на андроиде увеличится на размер Mono.

Здравствуйте, neFormal, Вы писали:

F>а сможешь увидеть?

Пока что нечего видеть)

F>ты не знал, что они существуют? или что?
F>расскажи же, в чём подвох?

Ну покажи пример биндинга к C++ библиотеке. Вот к тому же Boost'у например. )

Здравствуйте, alex_public, Вы писали:

F>>а сможешь увидеть?
_>Пока что нечего видеть)

чтд

_>Ну покажи пример биндинга к C++ библиотеке. Вот к тому же Boost'у например. )

зачем биндинг к сугубо плюсовым костылям? буст должен умереть, как все школоподелия.
к действительно полезным штукам биндинги делают. можно вспомнить хотя бы PyQt

Здравствуйте, Abyx, Вы писали:

A>если бы их делали с нуля в 2014 году, на каких языках их надо писать чтобы получился хороший браузер (т.е. такой который смог бы занять хотя бы 5% рынка на всех популярных платформах)
A>из нативных императивных go/rust/D — еще сырые.

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

A>на функциональных (хаскел, окамл) вроде ничего таких масштабов еще не писали, и вообще мутабельный DOM наверное плохо сочетается с ФП.

тут проблема с мышлением. перестроить восприятие на ФП бывает сложно. а с каким-нить хакселем — очень сложно.

A>из не-нативных — рендеринг на .NET/JVM будет тормозить и жрать тонны памяти, олсо с .NET дистрибутив на андроиде увеличится на размер Mono.

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

Здравствуйте, Sheridan, Вы писали:

S>С кадрами тяжко, да.

Некоторое время назад то же самое говорили программирующие на ассемблере всем остальным. "Фортран — отстой, Кобол — в печку, кадров — нет". И где счас тот ассемблер?

Здравствуйте, neFormal, Вы писали:

A>>если бы их делали с нуля в 2014 году, на каких языках их надо писать чтобы получился хороший браузер (т.е. такой который смог бы занять хотя бы 5% рынка на всех популярных платформах)
A>>из нативных императивных go/rust/D — еще сырые.

F>если учитывать расходы, то всё таки на плюсах. потому что много людей, которые их вроде как знают.
F>если расходы не учитывать, то на любом. хоть на go.

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

т.е. если на С++ 1000 человек делают браузер с 0 до 1.0beta за год, то на брейнфаке хоть 10'000 человек, хоть 100К человек делают браузер за 10+ лет, если вообще когда-то сделают.

A>>на функциональных (хаскел, окамл) вроде ничего таких масштабов еще не писали, и вообще мутабельный DOM наверное плохо сочетается с ФП.
F>тут проблема с мышлением. перестроить восприятие на ФП бывает сложно. а с каким-нить хакселем — очень сложно.

~~халва-халва~~ мышление-мышление.
разница между ФП и ИП совсем не в мышлении. разница в коде, т.к. ФП компилируется в императивный ассемблер, т.е. мы можем на ИЯП написать точно такой же код, какой может сгенерить компилятор ФЯП.
только почему-то так никто не делает.

F>в любом случае рендер придётся делать нативно. но там можно обойтись хотя бы чистым Си.

ну ты и клоун)

Здравствуйте, Abyx, Вы писали:

A>ага, на брейнфаке тоже.

и сходу начал сливаться

A>т.е. если на С++ 1000 человек делают браузер с 0 до 1.0beta за год, то на брейнфаке хоть 10'000 человек, хоть 100К человек делают браузер за 10+ лет, если вообще когда-то сделают.

охохох, как всё плохо с логикой

A>т.е. мы можем на ИЯП написать точно такой же код, какой может сгенерить компилятор ФЯП.
A>только почему-то так никто не делает.

никто не пишет на ИЯП? пьяный штоле?

F>>в любом случае рендер придётся делать нативно. но там можно обойтись хотя бы чистым Си.
A>ну ты и клоун)

очень мелко
если ты типичный плюсер, то у плюсов нет будущего ._.

Здравствуйте, Abyx, Вы писали:

A>я про то, что есть сложные проекты с 100500 строк кода и требованиями по производительности, для которых подходит только С++
И ск-ко таких проектов по сравнению с нетеребовательными к производительности? Боюсь, что 1 к 1000 тут будет завышеной оценкой. А ск-ко в деньгах? Подозреваю, что сумма денег в С++ проектах на порядок меньше суммы денег в менее вые.стых.

Здравствуйте, senglory, Вы писали:

A>>я про то, что есть сложные проекты с 100500 строк кода и требованиями по производительности, для которых подходит только С++
S>И ск-ко таких проектов по сравнению с нетеребовательными к производительности? Боюсь, что 1 к 1000 тут будет завышеной оценкой. А ск-ко в деньгах? Подозреваю, что сумма денег в С++ проектах на порядок меньше суммы денег в менее вые.стых.

я про то, что сравнение языков на примере hello-world'ов некорректно, даже если 99% программ — это hello-world'ы.

Здравствуйте, neFormal, Вы писали:

F>чтд

Болтун детектед. )

F>зачем биндинг к сугубо плюсовым костылям? буст должен умереть, как все школоподелия.
F>к действительно полезным штукам биндинги делают. можно вспомнить хотя бы PyQt

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

Здравствуйте, alex_public, Вы писали:

F>>зачем биндинг к сугубо плюсовым костылям? буст должен умереть, как все школоподелия.
F>>к действительно полезным штукам биндинги делают. можно вспомнить хотя бы PyQt
_>Потому что именно об этом и была речь. Но когда "специалист" обнаружил, что он оказывается лажанулся, то естественно попытался сделать вид, что разговор был о другом.

ну я рад, что по поводу костылей к убогому языку мы пришли к консенсусу.

Здравствуйте, senglory, Вы писали:

S>И ск-ко таких проектов по сравнению с нетеребовательными к производительности? Боюсь, что 1 к 1000 тут будет завышеной оценкой. А ск-ко в деньгах? Подозреваю, что сумма денег в С++ проектах на порядок меньше суммы денег в менее вые.стых.

Когда я вижу такие забавные размышления, то обычно советую автору перечислить какой же софт на его компе в данный момент написан не на C/C++. Ну и попытаться сравнить его количество с остальным.

Кстати, вот даже общаемся на данном форуме мы благодаря цепочке софта, написанной именно на C/C++. В начале (ну ОС не будем упоминать

) у нас браузер, который отправляет сообщения на сервер, где у нас http демон, который хранит сообщения в базе данных. И на каком языке написан браузер, http демон, база данных? )

В итоге, если смотреть по всему миру, то может и будет соотношение 1 к 1000, только в пользу C/C++...

Здравствуйте, alex_public, Вы писали:

_>В итоге, если смотреть по всему миру, то может и будет соотношение 1 к 1000, только в пользу C/C++...

Какой-то заметный процент софта на другом языке (Java больше всего) есть только в специфическом корпоративном мире

Подозреваю, что основные деньги ИТ-сектора экономики — это как раз корпоративный сектор. И основные значимые клиенты оттуда, а не хомячки домашние.

Здравствуйте, alex_public, Вы писали:

_>Когда я вижу такие забавные размышления, то обычно советую автору перечислить какой же софт на его компе в данный момент написан не на C/C++. Ну и попытаться сравнить его количество с остальным.

смешно, когда плюсеры не делают различия между C и С++.
однажды ещё и C# приплетут. фигли, буковка-то есть.

_>В итоге, если смотреть по всему миру, то может и будет соотношение 1 к 1000, только в пользу C/C++...

Какой-то заметный процент софта на другом языке (Java больше всего) есть только в специфическом корпоративном мире (т.е. софт написанный в не IT компаниях),

я тебя удивлю: мир не ограничивается только десктопным и системным софтом.

_>где основное требование идёт к возможности безопасного использования слабых программистов, а не к силе инструмента.

фаллометрия для плюсера — это главное. иначе нечем объяснить свою привязанность с детства.
но тут ты тоже порадовал. сила инструмента не в кучерявости.

Здравствуйте, neFormal, Вы писали:

F>ну я рад, что по поводу костылей к убогому языку мы пришли к консенсусу.

Пока что мы зафиксировали только полный слив и не знание базовых вещей у neFormal.

Здравствуйте, senglory, Вы писали:

S>Подозреваю, что основные деньги ИТ-сектора экономики — это как раз корпоративный сектор. И основные значимые клиенты оттуда, а не хомячки домашние.

Речь идёт не о софте для корпоративного мира, а о софте, который пишется внутри корпоративного (не IT) мира для себя. Как раз там и является важнейшей возможность использования малоквалифицированных программистов. Но при этом и в корпоративном секторе только небольшая часть софта пишется внутри. А большая часть всё же покупается снаружи в профессиональных IT компаниях (типа того же Oracle и т.п. подобных), которые опять же используют соответствующие мощные инструменты.

Здравствуйте, alex_public, Вы писали:

_>Когда я вижу такие забавные размышления, то обычно советую автору перечислить какой же софт на его компе в данный момент написан не на C/C++. Ну и попытаться сравнить его количество с остальным.

Думаешь политика инсталяции Микрософт дает ответ на вопрос, сколько же софта пишется на каком языке ?

Считать нужно исключительно по вакансиям и занятости людей. Сейчас нативных разработчиков примерно в 10 раз меньше всех остальных. Это значит, что кода в среднем пишется в 10 раз меньше.

_>В итоге, если смотреть по всему миру, то может и будет соотношение 1 к 1000, только в пользу C/C++...

Какой-то заметный процент софта на другом языке (Java больше всего) есть только в специфическом корпоративном мире (т.е. софт написанный в не IT компаниях), где основное требование идёт к возможности безопасного использования слабых программистов, а не к силе инструмента.

То есть, ты предлагаешь считать не софт, а его инсталяции, правильно ?

Как будем считать веб-странички ? С т.з. юзера это полноценные приложения. Вот открыл юзер сотню страниц — опаньки, надо в пользу джаваскрипта запасать 100 инсталяций.

Здравствуйте, alex_public, Вы писали:

S>>Подозреваю, что основные деньги ИТ-сектора экономики — это как раз корпоративный сектор. И основные значимые клиенты оттуда, а не хомячки домашние.
_>Речь идёт не о софте для корпоративного мира, а о софте, который пишется внутри корпоративного (не IT) мира для себя. Как раз там и является важнейшей возможность использования малоквалифицированных программистов. Но при этом и в корпоративном секторе только небольшая часть софта пишется внутри. А большая часть всё же покупается снаружи в профессиональных IT компаниях (типа того же Oracle и т.п. подобных), которые опять же используют соответствующие мощные инструменты.

В терминах Спольски это "внутреннее ПО". Только вот в чём проблема — большинство людей, похоже, заняты именно на таких работах для внутреннего ПО, и в основном под это идёт таки Java.
Я где-то лет 5 назад видел оценку, что на внутреннее ПО занято 70-80% от всего численного состава программистов в мире.
Не думаю, что оно сильно изменилось.

Здравствуйте, Ikemefula, Вы писали:

Ух ты кто появился этой темке... Но тебе сюда не надо на самом деле. ))) Мы с тобой хоть и спорим обычно, но хотя бы по делу и с аргументами. А тут народ вышел в основном потроллить или же подемонстрировать свою некомпетентность. Не порти своим здравыми нотками местную забавную атмосферу. )))

I>Думаешь политика инсталяции Микрософт дает ответ на вопрос, сколько же софта пишется на каком языке ?

Ну практически про весь известный софт можно узнать его язык написания. Даже в той же википедии указано обычно. Так что про установленное у меня на компьютере я обычно в курсе. Всего одна программка на Java и несколько на Python'e. Причём эти программки относятся к программированию (ide, система сборки, редактор и т.п.), т.е. если бы я был обычным пользователем, то у меня точно ноль был бы. ))) И это из более чем 250 папок в Program Files...

I>Считать нужно исключительно по вакансиям и занятости людей. Сейчас нативных разработчиков примерно в 10 раз меньше всех остальных. Это значит, что кода в среднем пишется в 10 раз меньше.

Дааааа? ))) Ну приводи источник своих данных... Я вот пока вижу данные

, утверждающие что 36,5% за нативными языками против 34% за ненативные (сумма меньше 100, т.к. это только первая 10-ка языков).

I>То есть, ты предлагаешь считать не софт, а его инсталяции, правильно ?
I>Как будем считать веб-странички ? С т.з. юзера это полноценные приложения. Вот открыл юзер сотню страниц — опаньки, надо в пользу джаваскрипта запасать 100 инсталяций.

Страничка — это максимум аналог "окна" приложения, а не отдельного приложения. Вот сайт — это да, аналог приложения. Только работа любого серьёзного сайта обеспечивается большой цепочкой софта. Как минимум: браузер, клиентский скрипт, http-демон, серверный скрипт, база данных. Ну браузер допустим используется один для разных сайтов, но всё остальное устанавливается под конкретный сайт. Так что как видишь стандартный сайт приносит в среднем +2 инсталляции к нативному софту и +2 к скриптам. И то если забыть про всякие memcached и т.п. серверное ПО. Это уж если делать подобные подсчёты инсталляций, хотя в принципе это всё ерунда и для оценки востребованности проще всего глянуть на график выше.

Здравствуйте, netch80, Вы писали:

N>В терминах Спольски это "внутреннее ПО". Только вот в чём проблема — большинство людей, похоже, заняты именно на таких работах для внутреннего ПО, и в основном под это идёт таки Java.
N>Я где-то лет 5 назад видел оценку, что на внутреннее ПО занято 70-80% от всего численного состава программистов в мире.
N>Не думаю, что оно сильно изменилось.

Насчёт того, что для внутреннего ПО в основном идёт Java, согласен. А вот по поводу процента этой деятельности от общего числа программистов сомневаюсь — см. картинку в моём предыдущем сообщение.

Здравствуйте, alex_public, Вы писали:

N>>В терминах Спольски это "внутреннее ПО". Только вот в чём проблема — большинство людей, похоже, заняты именно на таких работах для внутреннего ПО, и в основном под это идёт таки Java.
N>>Я где-то лет 5 назад видел оценку, что на внутреннее ПО занято 70-80% от всего численного состава программистов в мире.
N>>Не думаю, что оно сильно изменилось.

_>Насчёт того, что для внутреннего ПО в основном идёт Java, согласен. А вот по поводу процента этой деятельности от общего числа программистов сомневаюсь — см. картинку в моём предыдущем сообщение.

Картинку видел. Но там нет никаких прямых данных о делении по "миру разработки". А косвенно, если пересчитать, мои данные ничуть этому не противоречат, если, например, в коробочном ПО C/C++ занимает процентов 90, а во внутреннем — 30 (а ява, например, 50), то в сумме получатся где-то те же цифры.

Здравствуйте, alex_public, Вы писали:

_>Дааааа? ))) Ну приводи источник своих данных... Я вот пока вижу данные, утверждающие что 36,5% за нативными языками против 34% за ненативные (сумма меньше 100, т.к. это только первая 10-ка языков).

Тиоб все-таки очень сомнительный показатель. Он некоего коня в вакууме показывает.

Скорей все зависит от метода подсчета. Есть, к примеру, вот такой

Здравствуйте, uncommon, Вы писали:

IT>>Понимаю. Стандарная отмазка. Если на что-то нет денег, то их никогда и не будет. Если нет времени, то его тоже никогда не будет. Это главный принцип закона нехотения.
U>Просто он никому не нужен. Есть тонна куда более интересных технологий и языков, чтобы тратить время впустую на всякую ерунду.

Дружище, не надо пороть полную чушь и уж тем более выдвать её за абсолютную истину. Немерле на сегодняшний день один из лучших языков программирования, если не самый лучший. В нём органично собраны все лучшие парадигмы, а уж про метопрограммирование я вообще молчу. В MS только начали к нему серьёзно присматриваться. У него есть свои проблемы, в частности ему как-то с самого начала не везло с разработчиками. Но чтобы назвать этот язык ерундой нужно быть либо тролем, либо ничего не понимать в программировании.

Здравствуйте, netch80, Вы писали:

N>Картинку видел. Но там нет никаких прямых данных о делении по "миру разработки". А косвенно, если пересчитать, мои данные ничуть этому не противоречат, если, например, в коробочном ПО C/C++ занимает процентов 90, а во внутреннем — 30 (а ява, например, 50), то в сумме получатся где-то те же цифры.

Да, в принципе такое возможно. Правда в таком случае мир коробочного ПО уж совсем мелкий должен быть, потому как в данных рассуждениях был забыт (кстати про него почему-то часто забывают тут) embedded мир. Который весьма не маленький и как раз в нём основное царство C, с вкраплениями asm и C++. Так что цифра в 70-80% программистов мира работающих на внутреннее ПО мне кажется всё же несколько завышенной. Хотя всё может быть, у меня нет прямых цифр на этот счёт.

Здравствуйте, Aлeкceй, Вы писали:

A>Тиоб все-таки очень сомнительный показатель. Он некоего коня в вакууме показывает.

http://www.tiobe.com/index.php/content/paperinfo/tpci/tpci_definition.htm

A>Скорей все зависит от метода подсчета. Есть, к примеру, вот такой

Так это буквально та же самая техника подсчёта, что и у TIOBE, только более убогая. У них тут берутся данные только гугла (а у TIOBE с множества разных систем) и используется обобщённая система анализа Google Trends (а у TIOBE своя, заточенная специально под задачу анализа языков). Так что они меряют буквально одно и тоже, только подозреваю что TIOBE чуть точнее. )

Здравствуйте, alex_public, Вы писали:

I>>Думаешь политика инсталяции Микрософт дает ответ на вопрос, сколько же софта пишется на каком языке ?

_>Ну практически про весь известный софт можно узнать его язык написания. Даже в той же википедии указано обычно. Так что про установленное у меня на компьютере я обычно в курсе. Всего одна программка на Java и несколько на Python'e. Причём эти программки относятся к программированию (ide, система сборки, редактор и т.п.), т.е. если бы я был обычным пользователем, то у меня точно ноль был бы. ))) И это из более чем 250 папок в Program Files...

I>>Считать нужно исключительно по вакансиям и занятости людей. Сейчас нативных разработчиков примерно в 10 раз меньше всех остальных. Это значит, что кода в среднем пишется в 10 раз меньше.

_>Дааааа? ))) Ну приводи источник своих данных... Я вот пока вижу данные http://upload.wikimedia.org/wikipedia/en/d/d3/Tiobe_index.png, утверждающие что 36,5% за нативными языками против 34% за ненативные (сумма меньше 100, т.к. это только первая 10-ка языков).

Еще раз — если нужен индекс использования, надо смотреть данные по
1. рабочим местам
2. вакансиям

TIOBE это всего лишь индекс популярности результатов, а не индекс использования

Например, как отсюда понять, что около 90% программистов комитает в продакшн Джаваскрипт ?

I>>То есть, ты предлагаешь считать не софт, а его инсталяции, правильно ?
I>>Как будем считать веб-странички ? С т.з. юзера это полноценные приложения. Вот открыл юзер сотню страниц — опаньки, надо в пользу джаваскрипта запасать 100 инсталяций.

_>Страничка — это максимум аналог "окна" приложения, а не отдельного приложения.

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

>Вот сайт — это да, аналог приложения. Только работа любого серьёзного сайта обеспечивается большой цепочкой софта.

Да, я в курсе, если хотя бы одна строка на С++, значит и вся софтина на С++

>Как минимум: браузер, клиентский скрипт, http-демон, серверный скрипт, база данных. Ну браузер допустим используется один для разных сайтов, но всё остальное устанавливается под конкретный сайт. Так что как видишь стандартный сайт приносит в среднем +2 инсталляции к нативному софту и +2 к скриптам. И то если забыть про всякие memcached и т.п. серверное ПО. Это уж если делать подобные подсчёты инсталляций, хотя в принципе это всё ерунда и для оценки востребованности проще всего глянуть на график выше.

"Стандартный сайт" это примерно один из 10-100 на один сервер. Все они используют один и тот же веб-сервер, одну и ту же базу данных и тд.

Так вот количество уникальных сайтов много больше чем количество уникальных софтин. Где то лет 15 назад обычные приложения начали перебираться в веб, а с 2005го туда полезли десктопные монстры.

Сейчас почти все софтины имеют веб-аналоги, при чем не в одном экземпляре. Например офисные, включая экзотику типа TeX и тд и тд.

Здравствуйте, senglory, Вы писали:

S>Подозреваю, что основные деньги ИТ-сектора экономики — это как раз корпоративный сектор. И основные значимые клиенты оттуда, а не хомячки домашние.
Возможно, но не все так просто. Корпоративный сектор — это часто вещь в себе и деньги за него не выходят. А вот домашние хомячки, это те, которые приносят деньги со стороны.

З.Ы. Для не умеющих читать и понимать, это было ИМХО.

Здравствуйте, Ikemefula, Вы писали:

I>Еще раз — если нужен индекс использования, надо смотреть данные по
I>1. рабочим местам
I>2. вакансиям

I>TIOBE это всего лишь индекс популярности результатов, а не индекс использования

Ну вакансии, так вакансии... Давай глянем на тех же самых персонажей с этой точки зрения:

Java — 15609
C++ — 15355
Javascript — 10627
C# — 7822
Python — 4009
PHP — 3285

Несколько отличается от данных TIOBE, но по прежнему ничего близкого с твоими утверждениями. ))) А если посмотреть на использование этого софта, то вообще очень весело будет, т.к. коробочный софт устанавливается намного шире, чем внутрикорпоративный.

Ну и для контраста ещё несколько (в тему нашей другой дискуссии):

Erlang — 61
Haskell — 32
F# — 18
И то в последних двух вариантах ищут разработчиков на других языках, а указанные идут как "желательные навыки". )

I>Например, как отсюда понять, что около 90% программистов комитает в продакшн Джаваскрипт ?

Никак этого не понять, т.к. это твои фантазии. )

I>"Стандартный сайт" это примерно один из 10-100 на один сервер. Все они используют один и тот же веб-сервер, одну и ту же базу данных и тд.

Это ты про shared хостинг, который для домашних страничек васи пупкина? ) Хотя сейчас же уже есть VPS по $5/месяц — можно даже для таких страничек нормальный хостинг брать, не говоря уже об облаках.

I>Так вот количество уникальных сайтов много больше чем количество уникальных софтин. Где то лет 15 назад обычные приложения начали перебираться в веб, а с 2005го туда полезли десктопные монстры.

Да, есть такое. Хотя некоторое время назад наметилась другая интересная тенденция — серьёзные сайты начали делать нативные клиенты своих сайтов под каждую ОС, вместо запуска просто в браузере. ) Особенно это касается всяческих мобильных устройств — там наверное большая часть маркетов подобным забита. )))

Здравствуйте, senglory, Вы писали:

S>1. А кто вам сказал, что шарик — это CMS?

Потому что его использование за пределами возможностей типичных больших CMS при водит к такому геморою, что проще нужное реализовать на MVC.

S>Простите, а какое отношение эта хренотень имеет к организации документооборота из коробки?

А я разве где то подобное обещал?

Здравствуйте, alex_public, Вы писали:

_>Ну практически про весь известный софт можно узнать его язык написания. Даже в той же википедии указано обычно. Так что про установленное у меня на компьютере я обычно в курсе. Всего одна программка на Java и несколько на Python'e. Причём эти программки относятся к программированию (ide, система сборки, редактор и т.п.), т.е. если бы я был обычным пользователем, то у меня точно ноль был бы. ))) И это из более чем 250 папок в Program Files...

А сколько из этих 250 папок — софт за который заплачены деньги (не важно, за лицензию или поддержку)? У скольких из них вервая версия выпущена не ранее чем года 3 назад? А то вон на дорогах машин с карбюраторми пока хватает, что вовсе не означает что специалист по их конструированию кому нибудь нужен.

_>Я вот пока вижу данные ... утверждающие что 36,5% за нативными языками против 34% за ненативные (сумма меньше 100, т.к. это только первая 10-ка языков).

TIOBE с таким же успехом показывает так же погоду в Африке и количество осадков на Южном Полюсе.

_>И то если забыть про всякие memcached и т.п. серверное ПО.

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

Здравствуйте, Aлeкceй, Вы писали:

A>Скорей все зависит от метода подсчета. Есть, к примеру, вот такой

The PYPL PopularitY of Programming Language Index is created by analyzing how often language tutorials are searched on Google

Очередной тиобе. Я вот тоже последнее время в основном по js и питону туториалы ищу. Как думаешь, значит ли это что питон и жабаскрипт — мои основные языки?

Здравствуйте, alex_public, Вы писали:

_>C# — 7822

С# не всегда указывают. Иногда пишут просто .NET или даже просто какие то целевые фреймворки типа MVC.

I>>"Стандартный сайт" это примерно один из 10-100 на один сервер. Все они используют один и тот же веб-сервер, одну и ту же базу данных и тд.
_>Это ты про shared хостинг, который для домашних страничек васи пупкина? )

Как думаешь, сколько инсталляций веб-серверов на рсдн, который хостит этот сайт, блоги, немерлевые сайты, сайт издательства, которое в том числе rsdn mag выпускает, сайт для сервиса, собирающего янус? Или это у тебя домашние странички васи пупкина?

Здравствуйте, Ночной Смотрящий, Вы писали:

S>>Простите, а какое отношение эта хренотень имеет к организации документооборота из коробки?

НС>А я разве где то подобное обещал?

Я изначально говрил про шарик, как про средство документооборота из коробки. Что-то не на MS платформе есть такое же, что может похвастать объемами внедрения в мире?

Здравствуйте, alex_public, Вы писали:

>>TIOBE это всего лишь индекс популярности результатов, а не индекс использования

_>Ну вакансии, так вакансии... Давай глянем на тех же самых персонажей с этой точки зрения:

_>Java — 15609
_>C++ — 15355
_>Javascript — 10627
_>C# — 7822
_>Python — 4009
_>PHP — 3285

_>Несколько отличается от данных TIOBE, но по прежнему ничего близкого с твоими утверждениями. ))) А если посмотреть на использование этого софта, то вообще очень весело будет, т.к. коробочный софт устанавливается намного шире, чем внутрикорпоративный.

Мне кажется, ты или не понимаешь что пишешь, или врёшь внаглую

1. твои слова, цитирую " 36,5% за нативными языками против 34% за ненативные"? т.е. примерно 1 к 1
это было про топ 10 языков, TIOBE
2. раслад по вакансиям, ВНИМАНИЕ, только 5 языкам ! — 40 000 vs 15 000. Теперь добавим ruby, perl, visual basiс и objective с, получается 48 тыс vs 16 тыс. т.е. 3 к 1

Я правильно о тебя понял, 3 к 1 "несколько отличается от" 1 к 1 ?

I>>Например, как отсюда понять, что около 90% программистов комитает в продакшн Джаваскрипт ?

_>Никак этого не понять, т.к. это твои фантазии. )

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

"Senior .NET Developer — C#, ASP.NET, MVC, SQL"
".NET Developer — C#, ASP.NET, WPF"
"Lead .NET Developer — C#, ASP.NET, SQL"

Надо объяснять, что все эти вакансии подразумевают JavaScript в обязательном порядке ?

Теперь фокус, в языки программирования надо еще SQL добавить — это 22 тысячи вакансий. Итого, лень считать, по вакансиям выходит 4 к 1 или даже 5 к 1 не в пользу нативного кода.

I>>"Стандартный сайт" это примерно один из 10-100 на один сервер. Все они используют один и тот же веб-сервер, одну и ту же базу данных и тд.

_>Это ты про shared хостинг, который для домашних страничек васи пупкина? ) Хотя сейчас же уже есть VPS по $5/месяц — можно даже для таких страничек нормальный хостинг брать, не говоря уже об облаках.

При чем здесь вася пупкин ? Сколько виртуальных машин на сервере-ферме-кластере-клауде, никому не интересно, мы не считаем инсталяции, мы считаем уникальные приложения.
И вот получается 10-100 приложений на сервер, а IIS он один.

I>>Так вот количество уникальных сайтов много больше чем количество уникальных софтин. Где то лет 15 назад обычные приложения начали перебираться в веб, а с 2005го туда полезли десктопные монстры.

_>Да, есть такое. Хотя некоторое время назад наметилась другая интересная тенденция — серьёзные сайты начали делать нативные клиенты своих сайтов под каждую ОС, вместо запуска просто в браузере. ) Особенно это касается всяческих мобильных устройств — там наверное большая часть маркетов подобным забита. )))

Эти нативные приложения в большинстве или джава или джаваскрипт или чтото навроде, типа Unity и тд и тд. Даже iOs приложения пишутся не 100% на objective C, там есть и джава и C# и даже джаваскрипт.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>А сколько из этих 250 папок — софт за который заплачены деньги (не важно, за лицензию или поддержку)? У скольких из них вервая версия выпущена не ранее чем года 3 назад? А то вон на дорогах машин с карбюраторми пока хватает, что вовсе не означает что специалист по их конструированию кому нибудь нужен.

Уууу, чтобы именно первая версия выпущена не ранее чем 3 года назад — это сложно найти такое... Из моих кажется только только BitTorrent Sync (бесплатная) и пара тяжёлых игрушек (платные, лицензионные естественно).

А что, 3 года назад вышел какой-то замечательный язык программирования, который должен был затмить всех в новых проектах? )

НС>TIOBE с таким же успехом показывает так же погоду в Африке и количество осадков на Южном Полюсе.

Я не против использовать для анализа какой-то другой авторитетный рейтинг. Предлагай какой. А вот просто критика без предложения замены — это не конструктивно. )

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

Я говорю про практику, а не про теорию. ) Думая ты не будешь спорить, что описанная мною минимальная схемка устройства сайта является сейчас наиболее распространённой? )

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>С# не всегда указывают. Иногда пишут просто .NET или даже просто какие то целевые фреймворки типа MVC.

Если поставить .net вместо c#, то будет не 7K+, а 8K+, но при этом влезают всякие basic'и, asp и т.д.

Здравствуйте, Ikemefula, Вы писали:

I>Мне кажется, ты или не понимаешь что пишешь, или врёшь внаглую

I>1. твои слова, цитирую " 36,5% за нативными языками против 34% за ненативные"? т.е. примерно 1 к 1
I> это было про топ 10 языков, TIOBE
I>2. раслад по вакансиям, ВНИМАНИЕ, только 5 языкам ! — 40 000 vs 15 000. Теперь добавим ruby, perl, visual basiс и objective с, получается 48 тыс vs 16 тыс. т.е. 3 к 1

I>Я правильно о тебя понял, 3 к 1 "несколько отличается от" 1 к 1 ?

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

I>Фантазии это у тебя, ибо даже три числа сложить не можешь. Все веб-разработчики обязаны уметь Джаваскрипт. Независимо от того, руби, пхп или джава с дотнетом. Вакансии по твоей ссылке

I>"Senior .NET Developer — C#, ASP.NET, MVC, SQL"
I>".NET Developer — C#, ASP.NET, WPF"
I>"Lead .NET Developer — C#, ASP.NET, SQL"

I>Надо объяснять, что все эти вакансии подразумевают JavaScript в обязательном порядке ?

А там поиск как работает по всему тексту заявки, а не только по заголовку, так что это всё полностью включено. Собственно только из-за такой работы поиска и нашлось целых 30 вакансий на Хаскель — он там шёл как раз в описание.

I>Теперь фокус, в языки программирования надо еще SQL добавить — это 22 тысячи вакансий. Итого, лень считать, по вакансиям выходит 4 к 1 или даже 5 к 1 не в пользу нативного кода.

Половина из этих 22К входит как раз в требование к C/C++ разработчикам. ))) Я же говорю, там поиск работает по всей заявке, а не по названию должности.

I>Эти нативные приложения в большинстве или джава или джаваскрипт или чтото навроде, типа Unity и тд и тд. Даже iOs приложения пишутся не 100% на objective C, там есть и джава и C# и даже джаваскрипт.

Всё же в основном Java (смартофны/планшеты на Андроид), Objective-C (смартофны/планшеты на iOS), C++ (десктоп). Остальное скорее исключением, чем правило.

Здравствуйте, alex_public, Вы писали:

I>>Я правильно о тебя понял, 3 к 1 "несколько отличается от" 1 к 1 ?

_>Вообще то разговор про цифры начал как раз ты и озвучил цифру "нативных в 10 раз меньше". На что я тебе показал данные TIOBE (там 1 к 1) и наколенный анализ некого сайта вакансий (там 1 к 3). И там и там ничего похожего на твои цифры.

Потому, что мы считали открытые вакансии, а не проекты в разработке. В реальных проектах еще бОльшая разница с TIOBE. 10 к 1 это моя собственная оценка.

I>>Фантазии это у тебя, ибо даже три числа сложить не можешь. Все веб-разработчики обязаны уметь Джаваскрипт. Независимо от того, руби, пхп или джава с дотнетом. Вакансии по твоей ссылке

I>>"Senior .NET Developer — C#, ASP.NET, MVC, SQL"
I>>".NET Developer — C#, ASP.NET, WPF"
I>>"Lead .NET Developer — C#, ASP.NET, SQL"

I>>Надо объяснять, что все эти вакансии подразумевают JavaScript в обязательном порядке ?

_>А там поиск как работает по всему тексту заявки, а не только по заголовку, так что это всё полностью включено. Собственно только из-за такой работы поиска и нашлось целых 30 вакансий на Хаскель — он там шёл как раз в описание.

У меня ощущение, что ты отказываешься прочесть хоть чтото, что не согласуется с твоей позицией:

Interested in Node.js
Have experience with a Client Side MVC framework (Angular.js, Backbone.js, etc.)

Вот такое в вакансиях есть, а JavaScript может и не встречаться вовсе и это собтсвенно типичный случай. Сейчас "использование JavaScript" приравнивается к "умение программировать"

I>>Теперь фокус, в языки программирования надо еще SQL добавить — это 22 тысячи вакансий. Итого, лень считать, по вакансиям выходит 4 к 1 или даже 5 к 1 не в пользу нативного кода.

_>

Половина из этих 22К входит как раз в требование к C/C++ разработчикам.

Половина это сильно вряд ли. С++ это
1. драйвера
2. ядро
3. звук
4. видео
5. графика

А вот для веб-приложений SQL это the Must, бывают такие проекты, где SQL столько же или больше, чем кода на шарпе или джаве.

>))) Я же говорю, там поиск работает по всей заявке, а не по названию должности.

Это чушь, отрой глаза — куча веб-вакансий где джаваскрипт упоминается только косвенно.

_>Всё же в основном Java (смартофны/планшеты на Андроид), Objective-C (смартофны/планшеты на iOS), C++ (десктоп). Остальное скорее исключением, чем правило.

С++ десктоп версии это исключение, таких примеров наверное около одного — Эвернот. Скажем, в этой же области, что и Эвернот, есть несколько сотен приложений и средни них С++ на большинство не тянет — джава, vb, vba, дотнет, питон, джаваскрипт. И это всё настольные.

Здравствуйте, Ikemefula, Вы писали:

I>Потому, что мы считали открытые вакансии, а не проекты в разработке. В реальных проектах еще бОльшая
I>разница с TIOBE. 10 к 1 это моя собственная оценка.

Думаю что наоборот. Всё же оценка профессионалов в своём деле эффективнее чем наколенный анализ по одному сайту. Ну а твои оценки вообще из области фантастики.

I>У меня ощущение, что ты отказываешься прочесть хоть чтото, что не согласуется с твоей позицией:
I>

I>Interested in Node.js
I>Have experience with a Client Side MVC framework (Angular.js, Backbone.js, etc.)

I>Вот такое в вакансиях есть, а JavaScript может и не встречаться вовсе и это собтсвенно типичный случай. Сейчас "использование JavaScript" приравнивается к "умение программировать"

Ну покажи эту вакансию. )

I>Половина это сильно вряд ли. С++ это

Я к тому, что сделав поиск по sql ты вряд ли зацепил больше вакансий, чем уже было учтено при поиске по предыдущим языкам. Т.е. это повтор уже просто)

I>С++ десктоп версии это исключение, таких примеров наверное около одного — Эвернот. Скажем, в этой же области, что и Эвернот, есть несколько сотен приложений и средни них С++ на большинство не тянет — джава, vb, vba, дотнет, питон, джаваскрипт. И это всё настольные.

Как раз C++ и Питон там чаще всего. Ты забываешь про такие штуки как дропбокс и горы ему подобного)))

Здравствуйте, alex_public, Вы писали:

I>>Потому, что мы считали открытые вакансии, а не проекты в разработке. В реальных проектах еще бОльшая
I>>разница с TIOBE. 10 к 1 это моя собственная оценка.

_>Думаю что наоборот. Всё же оценка профессионалов в своём деле эффективнее чем наколенный анализ по одному сайту. Ну а твои оценки вообще из области фантастики.

У меня анализ по известным конторам и проектам, в нескольких странах кстати говоря

I>>У меня ощущение, что ты отказываешься прочесть хоть чтото, что не согласуется с твоей позицией:
I>>

I>>Interested in Node.js
I>>Have experience with a Client Side MVC framework (Angular.js, Backbone.js, etc.)

I>>Вот такое в вакансиях есть, а JavaScript может и не встречаться вовсе и это собтсвенно типичный случай. Сейчас "использование JavaScript" приравнивается к "умение программировать"

_>Ну покажи эту вакансию. )

http://www.dice.com/job/result/RTX18d369/wspos444045?src=19&q=Angular.js,%20Backbone.js%20C#

I>>Половина это сильно вряд ли. С++ это

_>Я к тому, что сделав поиск по sql ты вряд ли зацепил больше вакансий, чем уже было учтено при поиске по предыдущим языкам. Т.е. это повтор уже просто)

Это голословные рассуждения. Вместо того что бы додумывать, лучше взять и сделать поиск:
MS SQL Server Engineer
SQL Server DBA
Lead SQl DBA
Oracle Pl/SQL developer
postgre SQL DBA
SQL Developer

Дальше лень стало

I>>С++ десктоп версии это исключение, таких примеров наверное около одного — Эвернот. Скажем, в этой же области, что и Эвернот, есть несколько сотен приложений и средни них С++ на большинство не тянет — джава, vb, vba, дотнет, питон, джаваскрипт. И это всё настольные.

_>Как раз C++ и Питон там чаще всего. Ты забываешь про такие штуки как дропбокс и горы ему подобного)))

Я, к слову, из гигантского списка по GTD в свое время заинсталил практически все, только список был покороче, но больше сотни это точно
http://www.priacta.com/Articles/Comparison_of_GTD_Software.php

Здравствуйте, Ikemefula, Вы писали:

I>У меня анализ по известным конторам и проектам, в нескольких странах кстати говоря

А например программирование микроконтроллёров туда входит? )

I>http://www.dice.com/job/result/RTX18d369/wspos444045?src=19&q=Angular.js,%20Backbone.js%20C#

Ха, так это C# вакансия, что там и вполне чётко указано. Т.е. эта вакансия уже учтена была в той твоей статистике.

I>Это голословные рассуждения. Вместо того что бы додумывать, лучше взять и сделать поиск:
I>MS SQL Server Engineer
I>SQL Server DBA
I>Lead SQl DBA
I>Oracle Pl/SQL developer
I>postgre SQL DBA
I>SQL Developer

I>Дальше лень стало

Из перечисленного только одно является языком программирования и оно имеет свой тэг.

I>Я, к слову, из гигантского списка по GTD в свое время заинсталил практически все, только список был покороче, но больше сотни это точно
I>http://www.priacta.com/Articles/Comparison_of_GTD_Software.php

А причём тут это? )

Здравствуйте, alex_public, Вы писали:

I>>У меня анализ по известным конторам и проектам, в нескольких странах кстати говоря

_>А например программирование микроконтроллёров туда входит? )

Разумеется.

I>>http://www.dice.com/job/result/RTX18d369/wspos444045?src=19&q=Angular.js,%20Backbone.js%20C#

_>Ха, так это C# вакансия, что там и вполне чётко указано. Т.е. эта вакансия уже учтена была в той твоей статистике.

Ты снова перестал читать. Я про то и говорю — джаваскриптеров много больше. Это значит, в сумме, что самый востребованый язык это Джаваскрипт, ну может SQL.

Где это в твоей картинке от TIOBE — не ясно.

I>>MS SQL Server Engineer
I>>SQL Server DBA
I>>Lead SQl DBA
I>>Oracle Pl/SQL developer
I>>postgre SQL DBA
I>>SQL Developer

I>>Дальше лень стало

_>Из перечисленного только одно является языком программирования и оно имеет свой тэг.

Во всех этих вакансиях надо знать и уметь SQL. У тебя есть примеры DBA которые не знают SQL ?

I>>Я, к слову, из гигантского списка по GTD в свое время заинсталил практически все, только список был покороче, но больше сотни это точно
I>>http://www.priacta.com/Articles/Comparison_of_GTD_Software.php

_>А причём тут это? )

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

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Очередной тиобе. Я вот тоже последнее время в основном по js и питону туториалы ищу. Как думаешь, значит ли это что питон и жабаскрипт — мои основные языки?

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

Здравствуйте, alex_public, Вы писали:

_>Думаю что наоборот. Всё же оценка профессионалов в своём деле эффективнее чем наколенный анализ по одному сайту. Ну а твои оценки вообще из области фантастики.

Вот наколенный анализ по другому сайту. Здесь разрыв еще больше виден.

java-72k
c#-34,5k
javascript-50k
php-20k
perl-20k
python-24k
ruby-14k

c++-33k
obj-c-4,5k

Так что здесь разница где-то 7-8 раз в сравнении с компилируемыми.

Здравствуйте, Ikemefula, Вы писали:

I>Ты снова перестал читать. Я про то и говорю — джаваскриптеров много больше. Это значит, в сумме, что самый востребованый язык это Джаваскрипт, ну может SQL.

Хыхы, ну в таком смысле я могу тебе ещё несколько таких же мегапопулярных языков подкинуть: html, xml и т.п. )))

I>Где это в твоей картинке от TIOBE — не ясно.

Ну так если они это как-то сумели отфильтровать, то только молодцы. Как они отфильтровали всякие там sql, html и т.п. понятно — это просто не языки программирования и поэтому не входят в их рейтинг. А вот с JS сложнее, т.к. он одновременно частенько служит и "результатом вычислений", т.е. как бы данными, и обычным языком программирования.

I>Во всех этих вакансиях надо знать и уметь SQL. У тебя есть примеры DBA которые не знают SQL ?

Ага, осталось ещё админов начать учитывать. )))

I>Я намекаю, что ты вряд ли сообщишь мне чтото новое об этих программах, хотя стараешься это сделать когда рассказываешь на чем же они написаны.

А я про GTD вообще ни слова не говорил. Это ты про них вспомнил, я же тебе наоборот сказал, что это далеко не единственный вид сервиса, часто предоставляющий нативные клиенты.

Здравствуйте, Aлeкceй, Вы писали:

A>Вот наколенный анализ по другому сайту. Здесь разрыв еще больше виден.

A>java-72k
A>c#-34,5k
A>javascript-50k
A>php-20k
A>perl-20k
A>python-24k
A>ruby-14k

A>c++-33k
A>obj-c-4,5k

A>Так что здесь разница где-то 7-8 раз в сравнении с компилируемыми.

Ага, осталось только учесть здесь такой язык как C... Только вот т.к. это сайт не айтишный (в отличие от моего примера), то там это весьма и весьма проблематично. Так что наколенный анализ — это всё же сомнительное дело. )

Здравствуйте, alex_public, Вы писали:

_>Хыхы, ну в таком смысле я могу тебе ещё несколько таких же мегапопулярных языков подкинуть: html, xml и т.п. )))

И давно они получили полноту по Тьюрингу ?

I>>Где это в твоей картинке от TIOBE — не ясно.

_>Ну так если они это как-то сумели отфильтровать, то только молодцы. Как они отфильтровали всякие там sql, html и т.п. понятно — это просто не языки программирования и поэтому не входят в их рейтинг. А вот с JS сложнее, т.к. он одновременно частенько служит и "результатом вычислений", т.е. как бы данными, и обычным языком программирования.

Они вообще ничего не фильтровали, где то чтото нагуглили и показали.

I>>Я намекаю, что ты вряд ли сообщишь мне чтото новое об этих программах, хотя стараешься это сделать когда рассказываешь на чем же они написаны.

_>А я про GTD вообще ни слова не говорил. Это ты про них вспомнил, я же тебе наоборот сказал, что это далеко не единственный вид сервиса, часто предоставляющий нативные клиенты.

Так назови еще какой сервис, не стесняйся.

Здравствуйте, alex_public, Вы писали:

A>>Так что здесь разница где-то 7-8 раз в сравнении с компилируемыми.

_>Ага, осталось только учесть здесь такой язык как C... Только вот т.к. это сайт не айтишный (в отличие от моего примера), то там это весьма и весьма проблематично. Так что наколенный анализ — это всё же сомнительное дело. )

Сайт не айтишный, гранаты не той системы...

С какого бодуна вакансии надо смотреть на айтишных сайтах ?

Что касается языка С, то он без плюсов в вакансиях встречается почти так же часто, как и никогда.

Здравствуйте, Ikemefula, Вы писали:

I>И давно они получили полноту по Тьюрингу ?

А в каком году её получил SQL? )

Кстати, как раз поэтому его не включают в рейтинг TIOBE, но при этом включают всякие pl/sql и т.п.

Вообще это наше подробное обсуждение достаточно полезным было, т.к. из него я оценил проблемность этого нашего наколенного метода с сайтом вакансий. Т.к. поиск идёт по всей заявке (а иначе делать смысла тоже нет, т.к. заголовки часто вообще невнятные), то там попадает множество языков. Т.е. каждая вакансия у нас входит много раз в нашу "статистику". Причём больше всего от этого выигрывают языки, интенсивно используемые другими в вспомогательных целях. Максимально это демонстрирует SQL, который сам по себе (по чистому) имеет может тысячу заявок, но результат выдаёт на 20 тысяч, т.к. реально он используется как вспомогательный почти во всех языках. JS аналогично, возникает в заявке скажем какого-нибудь разработчика ajax скриптов на Питоне, хотя реально пишут не на нём, и в итоге набирает неадекватные цифры. В общем совсем это не простое дело, реально оценить популярность языков по сайту вакансий. Надо полноценную методику разрабатывать, выкачивать все их данных и считать без повторов. )

I>Они вообще ничего не фильтровали, где то чтото нагуглили и показали.

Вот уже не раз говорил тут. Я абсолютно не против воспользоваться любым другим авторитетным рейтингом — предлагай вариант. Но когда ты тупо критикуешь, ничего не предлагая взамен, то это не дело. Какие-то ориентиры нужны всё равно, так что если ты не можешь предложить ничего лучше, то будем пользоваться неидеальным TIOBE.

I>Так назови еще какой сервис, не стесняйся.

Я же уже говорил в предыдущем сообщение. Например всяческие разновидности дропбоксов, которых в последнее время много развелось. А сейчас, на почве всеобщей паранойи, по второму кругу зарождаются, уже с сильной криптографией. )))

Здравствуйте, Ikemefula, Вы писали:

I>Сайт не айтишный, гранаты не той системы...
I>С какого бодуна вакансии надо смотреть на айтишных сайтах ?

Потому что при поиске на просто C на этом сайте (в отличие от айтишного) вылезают горы постороннего мусора.

I>Что касается языка С, то он без плюсов в вакансиях встречается почти так же часто, как и никогда.

Дааа, точно ты ничего не знаешь про микроконтроллеры... )

Здравствуйте, alex_public, Вы писали:

_>А в каком году её получил SQL? )

SQL92 еще не обладает полнотой, SQL с CTE и window функциями уже CTE. Кроме того, T-sql и pl/sql обладают полнотой по тьюрингу с самого начала.

_>Кстати, как раз поэтому его не включают в рейтинг TIOBE, но при этом включают всякие pl/sql и т.п.

Просто на SQL никто никогда не пишет. Пишут на конкретных реализациях.

_>Вообще это наше подробное обсуждение достаточно полезным было, т.к. из него я оценил проблемность этого нашего наколенного метода с сайтом вакансий. Т.к. поиск идёт по всей заявке (а иначе делать смысла тоже нет, т.к. заголовки часто вообще невнятные), то там попадает множество языков. Т.е. каждая вакансия у нас входит много раз в нашу "статистику". Причём больше всего от этого выигрывают языки, интенсивно используемые другими в вспомогательных целях. Максимально это демонстрирует SQL, который сам по себе (по чистому) имеет может тысячу заявок, но результат выдаёт на 20 тысяч, т.к. реально он используется как вспомогательный почти во всех языках. JS аналогично, возникает в заявке скажем какого-нибудь разработчика ajax скриптов на Питоне, хотя реально пишут не на нём, и в итоге набирает неадекватные цифры.

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

I>>Они вообще ничего не фильтровали, где то чтото нагуглили и показали.

_>Вот уже не раз говорил тут. Я абсолютно не против воспользоваться любым другим авторитетным рейтингом — предлагай вариант. Но когда ты тупо критикуешь, ничего не предлагая взамен, то это не дело. Какие-то ориентиры нужны всё равно, так что если ты не можешь предложить ничего лучше, то будем пользоваться неидеальным TIOBE.

А кто, по твоему, предложил смотреть в вакансии ?

I>>Так назови еще какой сервис, не стесняйся.

_>Я же уже говорил в предыдущем сообщение. Например всяческие разновидности дропбоксов, которых в последнее время много развелось. А сейчас, на почве всеобщей паранойи, по второму кругу зарождаются, уже с сильной криптографией. )))

Прикладных тулов на порядки больше чем системных. Кроме GTD, есть целая куча редакторов, аутлайнеров и вообще тулов, которые хоть как то помогают организовать работу пользователя. Для чего в них С++ — совершенно не ясно.

Здравствуйте, alex_public, Вы писали:

I>>Сайт не айтишный, гранаты не той системы...
I>>С какого бодуна вакансии надо смотреть на айтишных сайтах ?

_>Потому что при поиске на просто C на этом сайте (в отличие от айтишного) вылезают горы постороннего мусора.

Ну я вот нашел, 2 тысячи вакансий

I>>Что касается языка С, то он без плюсов в вакансиях встречается почти так же часто, как и никогда.

_>Дааа, точно ты ничего не знаешь про микроконтроллеры... )

То есть, ты считаешь, что надо разбираться в микроконтролерах, что бы суметь прочесть текст вакансии ?

Может причина в том, что тебе не нравится, что так мало вакансий про микроконтроллеры ?

Так это нормально, с железом колупается только один из 10.

Здравствуйте, Ikemefula, Вы писали:

I>Это вполне адекватные цифры и показывают ровно ту ситуацию, что есть на самом деле — хотя чистых джаваскриптеров относительно немного, джаваскрипт знает, умеет и применяет подавляющее большинство разработчиков.

Ну так вот с такой формулировкой я совершенно не спорю... ) Собственно я в этом смысле тоже временами работаю "на js". )))

I>А кто, по твоему, предложил смотреть в вакансии ?

Как видишь, простого "посмотреть вакансии на сайте" совершенно не достаточно для получения каких-то вменяемых цифр. Нужен довольно серьёзный анализ. Если его кто-то проделывал и публиковал, то было бы интересно взглянуть... )

Здравствуйте, Ikemefula, Вы писали:

I>Ну я вот нашел, 2 тысячи вакансий

Это каким способом? )

I>То есть, ты считаешь, что надо разбираться в микроконтролерах, что бы суметь прочесть текст вакансии ?

Нет, это касалось твоего предположения об отсутствие вакансий на чистый C. )))

Здравствуйте, alex_public, Вы писали:

I>>Ну я вот нашел, 2 тысячи вакансий

_>Это каким способом? )

Классическим.

I>>То есть, ты считаешь, что надо разбираться в микроконтролерах, что бы суметь прочесть текст вакансии ?

_>Нет, это касалось твоего предположения об отсутствие вакансий на чистый C. )))

"почти так же часто, как и никогда"

Здравствуйте, alex_public, Вы писали:

_>Если поставить .net вместо c#

Надо не вместо а вместе.

_>, то будет не 7K+, а 8K+, но при этом влезают всякие basic'и,

Бейсика сейчас в новых проектах совсем немного, так что и людей для него ищут мало.

_> asp и т.д.

ASP это не язык программирования, а технология.

Здравствуйте, Ikemefula, Вы писали:

_>>Хыхы, ну в таком смысле я могу тебе ещё несколько таких же мегапопулярных языков подкинуть: html, xml и т.п. )))
I>И давно они получили полноту по Тьюрингу ?

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

Здравствуйте, alex_public, Вы писали:

_>Уууу, чтобы именно первая версия выпущена не ранее чем 3 года назад — это сложно найти такое...

Ну вот поэтому и так много нативного софта — переписывать большие проекты мало кто отваживается.

НС>>TIOBE с таким же успехом показывает так же погоду в Африке и количество осадков на Южном Полюсе.
_>Я не против использовать для анализа какой-то другой авторитетный рейтинг.

Так нет его, нормального рейтинга то. Но это ж не повод всякой хрени типа тиобы верить, не так ли?

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

_>Я говорю про практику, а не про теорию. )

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

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Ну вот поэтому и так много нативного софта — переписывать большие проекты мало кто отваживается.

Ну так новый софт (и BitTorrent Sync и тяжёлые игрушки) у меня всё равно весь нативный оказался. )

НС>Так нет его, нормального рейтинга то. Но это ж не повод всякой хрени типа тиобы верить, не так ли?

Какой-то ориентир всё равно же нужен...

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

НС>А это практика и есть. Фокус сложности сильно перекошен в сторону того что ты называешь клиентскими и серверными скриптами. Веб-сервера давно уже никого сильно не волнуют. Апач+Томкет сотоварищи и ИИС+АСП.НЕТ перекрывают почти весь рынок веб-серверов для обычных приложений, и они уже давным давно написаны.

Вот именно потому что давно написаны, потому и никого не волнуют. Т.е. удалось абстрагировать некую часть процесса настолько хорошо, что можно написать один раз для всех случаев сразу. Хотя на самом деле всё же периодически пытаются новые варианты разработать: тот же самый node.js или куча своих python серверов и ещё много разных вариантов.

НС>Если же ты гипетрофируешь крошечную часть, слушающую сокет (у lighttpd, к примеру, всех исходников 800К в архиве), зато весь стек серверных веб-технологий утаптываешь в "серверный скрипт", то твоя картинка очень далека от реальной, мягко говоря.

Ну для начала я говорил не только про нативного http-демона, но и про нативную базу данных. И вот последнее как раз обычно и выполняет основную работу (кстати, а не хочешь сравнить объём кода скриптов у среднего сайта и объём исходников скажем mysql?). А серверные скрипты чаще всего представляют собой тонкую прослойку между этими двумя монстрами, занимающуюся переформатированием данных между базой и js скриптом, и добавлением минимальной логики (той, которую небезопасно делать на клиентском компьютере, типа авторизации).

Здравствуйте, senglory, Вы писали:

S>Я изначально говрил про шарик, как про средство документооборота из коробки. Что-то не на MS платформе есть такое же, что может похвастать объемами внедрения в мире?
Lotus (aka IBM) Notes/Domino.

Здравствуйте, alex_public, Вы писали:

_>Ну так новый софт (и BitTorrent Sync и тяжёлые игрушки) у меня всё равно весь нативный оказался. )

Игрушки это отдельный разговор, особенно те что и на консолях есть. Итого остается всего одна софтинка. Опять же игрушки — вон уже и нвидивские драйвера дотнет требуют, а catalyst control center так давно уже.
Опять же, я вот был уверен, что SourceTree чисто нативное приложение. Ан нет, виндовый SourceTree.exe — дотнетная сборка, и гуй на WPF.

НС>>Так нет его, нормального рейтинга то. Но это ж не повод всякой хрени типа тиобы верить, не так ли?
_>Какой-то ориентир всё равно же нужен...

Но это не повод использовать тиобе.

_>Ну и кстати не знаю как там насчёт абсолютных цифр, но тенденции во времени они на мой взгляд показывают вполне не плохо.

Тенденции он тоже не показывает. Он показывает только хайп. Т.е. выходит новая версия, скажем, шарпа — график у тиобе активно растет. К реальному объему использования языка это почти никакого отношения не имеет.

_>Вот именно потому что давно написаны, потому и никого не волнуют.

Ну так их никто и переписывать не будет. Но мысль моя была не в этом, а в том что количество людей, которые пишут ИИС и Апач сравнительно невелико, и не увеличивается. Так что этот софт в плане потребления разработчиков — капля в море.

_>Хотя на самом деле всё же периодически пытаются новые варианты разработать: тот же самый node.js

Тот же самый node.js работает в основном под теми же самыми апачем и иисом.

_> или куча своих python серверов

Которые на продакшене все равно работают не standalone, а в виде апачевского модуля.

_>Ну для начала я говорил не только про нативного http-демона, но и про нативную базу данных.

БД могут быть и не нативными, если это NoSQL. А SQL практически все мейнстримовые написаны много десятков лет назад. Там и С++ то постольку поскольку, в основном чистый С.

_> И вот последнее как раз обычно и выполняет основную работу (кстати, а не хочешь сравнить объём кода скриптов у среднего сайта и объём исходников скажем mysql?).

Средний сайт — понятие растяжимое. Есть и такие, на фоне которых mysql — карлик.

_> А серверные скрипты чаще всего представляют собой тонкую прослойку между этими двумя монстрами, занимающуюся переформатированием данных между базой и js скриптом, и добавлением минимальной логики (той, которую небезопасно делать на клиентском компьютере, типа авторизации).

Ты либо абсолютно не в теме, либо сознательно вводишь в заблуждение.

Здравствуйте, IT, Вы писали:

IT>Могу сказать про банки в штатах. .NET с серверов приложений полностью выдавлен джавой.

Это неправда. WellsFargo, Citigroup, Barclays — много чего на IIS крутится. А это одни из самых крупных.

Здравствуйте, mark_kavinski, Вы писали:

IT>>Могу сказать про банки в штатах. .NET с серверов приложений полностью выдавлен джавой.
_>Это неправда. WellsFargo, Citigroup, Barclays — много чего на IIS крутится. А это одни из самых крупных.

IIS — это веб, а не сервер сайд.

Здравствуйте, Privalov, Вы писали:

S>>С кадрами тяжко, да.

P>Некоторое время назад то же самое говорили программирующие на ассемблере всем остальным. "Фортран — отстой, Кобол — в печку, кадров — нет".

Так для того времени и тех задач это была вполне себе нормальная позиция.
Фактически, C закрыл собой ту нишу, для которой пытались долго и нудно делать PL/1.

P> И где счас тот ассемблер?

Там же, где и был — чуть более чем везде. Только он стал по большинству пунктов кроссплатформенным и переименовался в C

Здравствуйте, IT, Вы писали:

IT>>>Могу сказать про банки в штатах. .NET с серверов приложений полностью выдавлен джавой.
_>>Это неправда. WellsFargo, Citigroup, Barclays — много чего на IIS крутится. А это одни из самых крупных.

IT>IIS — это веб, а не сервер сайд.
И веб и сервер сайд у них на .NET. Не всё естественно, но у них десятки сервисов.

Здравствуйте, mark_kavinski, Вы писали:

IT>>>>Могу сказать про банки в штатах. .NET с серверов приложений полностью выдавлен джавой.
_>>>Это неправда. WellsFargo, Citigroup, Barclays — много чего на IIS крутится. А это одни из самых крупных.

IT>>IIS — это веб, а не сервер сайд.
_>И веб и сервер сайд у них на .NET. Не всё естественно, но у них десятки сервисов.

А на джаве их десятки тысяч. Разница в несколько порядков. В принципе, я погу перефразировать своё утверждение. .NET с серверов приложений почти полностью выдавлен джавой.

Здравствуйте, IT, Вы писали:

IT>А на джаве их десятки тысяч. Разница в несколько порядков. В принципе, я погу перефразировать своё утверждение. .NET с серверов приложений почти полностью выдавлен джавой.

А вон Абалак говорит, что работы на бэкэнд дофига.
И, кстати, не знаешь почему так произошло? Раньше же дотнета там порядочно было. Как так вдруг произошло, что джава почти вытеснила?

Здравствуйте, Aлeкceй, Вы писали:

IT>>А на джаве их десятки тысяч. Разница в несколько порядков. В принципе, я погу перефразировать своё утверждение. .NET с серверов приложений почти полностью выдавлен джавой.

A>А вон Абалак говорит, что работы на бэкэнд дофига.

Абалак работает в хедж-фонде.

A>И, кстати, не знаешь почему так произошло? Раньше же дотнета там порядочно было. Как так вдруг произошло, что джава почти вытеснила?

В Morgan Stanley, где я до последнего времени работал, разработка серверного кода на .NET запрещена архитекрутным тимом. Кроме Web. Поэтому народ извращается как может. У нас в хозяйстве были свои никому неподконтрольные Windows сервера и мы на них, конечно же, делали всё что нужно на .NET. Но вот пробить SQL Server никак не получается, при чём по той же причине — сервер БД должен работать на Линухе. Поэтому там во всю процветают дебильные БД вроде Sybase.

Требование Java вытекает из того же самого — должно работать на Линуксе. С Моно никто связываться не хочет, а .NET под Линуксом не работает, поэтому .NET в сад, а C# лесом.

В результате многие трейдинговые системы делаются по схеме — Java на сервере, .NET на клиенте.

Здравствуйте, Aлeкceй, Вы писали:

Забыл добавить.

Если бы MS выпустил .NET под Линукс, то дни Java ну не то чтобы были сочтены, но мы бы её оттуда очень сильно подвинули, т.к. желающих очень много. А когда .NET обосновался бы на серверах, то можно было бы ставить вопрос о нужности Линукса на сервере и доказывать, что его обслуживание вовсе не дешевле Windows, а гемора при разработке больше. Т.е. .NET вполне мог бы оказаться тем поршнем, который помог бы выдавать Линукс с серверной части. А пока получается, что на серверах, за исключением веба, MS представлена очень слабо.

Здравствуйте, IT, Вы писали:

IT>Если бы MS выпустил .NET под Линукс, то дни Java ну не то чтобы были сочтены, но мы бы её оттуда очень сильно подвинули, т.к. желающих очень много. А когда .NET обосновался бы на серверах, то можно было бы ставить вопрос о нужности Линукса на сервере и доказывать, что его обслуживание вовсе не дешевле Windows, а гемора при разработке больше. Т.е. .NET вполне мог бы оказаться тем поршнем, который помог бы выдавать Линукс с серверной части.

не совсем понимаю, как отсутствие/присутствие Net на линуксе сможет продвинуть винду.
скорее наоборот -- еще один повод отказаться от Windows.

Здравствуйте, night beast, Вы писали:

NB>не совсем понимаю, как отсутствие/присутствие Net на линуксе сможет продвинуть винду.

Очень просто. Я — дотнечик. Пустите меня на сервер сайд, а дальше я туда постепенно притащу всё что угодно.

NB>скорее наоборот -- еще один повод отказаться от Windows.

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

Здравствуйте, IT, Вы писали:

NB>>не совсем понимаю, как отсутствие/присутствие Net на линуксе сможет продвинуть винду.

IT>Очень просто. Я — дотнечик. Пустите меня на сервер сайд, а дальше я туда постепенно притащу всё что угодно.

NB>>скорее наоборот -- еще один повод отказаться от Windows.

IT>От линукса меня тянет блевать. Поэтому я сделаю всё, что бы заменить его на винду. Но проблема в том, что меня отсекают и не дают сказать слова в самом самом начале. Ещё раз повторюсь. MS никак не представлена на серверах. То, что есть в банках делается в полуподпольном режиме силами энтузиастов против всех полиси. Например, мне одному, хотя я в банке и при офицерской должности, такое не под силу. Моему начальнику? Может быть, хотя не уверен. А вот под работающее или разрабатывающееся приложение виндовый серверок продавить можно. Они в банках есть и их много. В основном для веба. Но сервер сайд закрыт, т.к. нужно, чтобы серверное приложение умело работать под Линуксом.

я тебя понимаю, но я также понимаю, что присутствие Net под линуксом никак не повлияет не текущее положение дел. никак.

то есть писать на нем тебе дадут, но менять операционку никто не будет.

Здравствуйте, night beast, Вы писали:

NB>то есть писать на нем тебе дадут, но менять операционку никто не будет.

Как-то ты очень уверенно утверждаешь что мне дадут, а что нет. Ещё раз. Причина, точнее это просто повод, для недопуска .NET на сервера — отсутствие поддержки Линукса. Всё, period! Все дотнетчики свободны. Это, надеюсь, понятно? А вот получить мне самому нужный сервер гораздо проще. На это нет никакой политики компании. Я совершенно спокойно могу обосновать необходимость dev сервера под Windows как более удобного для девелопмента и отладки. А потом под шумок и другие сервера поменяю. Там нужен уже совсем другой уровень чтобы договариваться.

Здравствуйте, IT, Вы писали:

IT>А когда .NET обосновался бы на серверах, то можно было бы ставить вопрос о нужности Линукса на сервере и доказывать, что его обслуживание вовсе не дешевле Windows, а гемора при разработке больше.

так разве не из-за обслуживания ушли с винды?

>> Но только на линуксе, потому что винда менее надёжная и менее управляемая.

вот же ^
ну, т.е., если там такие проблемы, то доказать будет уже почти невозможно.

IT>От линукса меня тянет блевать.

хм, почему?

Здравствуйте, neFormal, Вы писали:

>>> Но только на линуксе, потому что винда менее надёжная и менее управляемая.
F>вот же ^

Вот же что? То, что в архитектурном тиме сидят долбодятлы и придумывают всякую хрень лишь бы от них отстали?

F>ну, т.е., если там такие проблемы, то доказать будет уже почти невозможно.

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

Здравствуйте, IT, Вы писали:

NB>>то есть писать на нем тебе дадут, но менять операционку никто не будет.

IT>Как-то ты очень уверенно утверждаешь что мне дадут, а что нет. Ещё раз. Причина, точнее это просто повод, для недопуска .NET на сервера — отсутствие поддержки Линукса. Всё, period! Все дотнетчики свободны. Это, надеюсь, понятно?

ок. и что мешает тебе пропихнуть моно, а потом под шумок поменять серваки?

Здравствуйте, IT, Вы писали:

IT>Причина, точнее это просто повод, для недопуска .NET на сервера — отсутствие поддержки Линукса. Всё, period!
Такой вопрос: а как сейчас с CAL к winserver? Насколько я помню, варианта всего два или затариваться External Connector+per-cpu CAL, или надеяться что не заметят

Здравствуйте, IT, Вы писали:

>>>> Но только на линуксе, потому что винда менее надёжная и менее управляемая.
F>>вот же ^
IT>Вот же что?

вот же пример отзыва об одинаковой или меньшей стоимости обслуживания винды.
если про винду есть такие отзывы, основанные, похоже, на личном опыте, то как MS сможет убедить юзеров в дешевизне обслуживания?

F>>ну, т.е., если там такие проблемы, то доказать будет уже почти невозможно.
IT>Когда мне нужен сервер я общаюсь с совершенно другими людьми.

не, я не про ваши корпоративные тёрки. я про создание винде позитивного имиджа.

IT>серверные приложения должны иметь возможность работать на Линухе.

всё правильно

Здравствуйте, IT, Вы писали:

IT>Как-то ты очень уверенно утверждаешь что мне дадут, а что нет. Ещё раз. Причина, точнее это просто повод, для недопуска .NET на сервера — отсутствие поддержки Линукса. Всё, period! Все дотнетчики свободны. Это, надеюсь, понятно?

А всего-то надо было при формулировке стандарта .NET подумать не только про виндовую среду... впрочем, видимо, это было не в интересах MS.

Здравствуйте, netch80, Вы писали:

IT>>Как-то ты очень уверенно утверждаешь что мне дадут, а что нет. Ещё раз. Причина, точнее это просто повод, для недопуска .NET на сервера — отсутствие поддержки Линукса. Всё, period! Все дотнетчики свободны. Это, надеюсь, понятно?

N>А всего-то надо было при формулировке стандарта .NET подумать не только про виндовую среду...

знаю NET поверхностно, но ничего Win-специфичное не припоминаю. другое дело тратить деньги на реализацию этого под другую платформу

N>впрочем, видимо, это было не в интересах MS.

видимо, MS пох. на то, есть ли .NET за пределами виндовса.

Здравствуйте, netch80, Вы писали:

N>А всего-то надо было при формулировке стандарта .NET подумать не только про виндовую среду... впрочем, видимо, это было не в интересах MS.
А можно пример мест, в которых .net явно заточен под win?

Здравствуйте, Sinix, Вы писали:

N>>А всего-то надо было при формулировке стандарта .NET подумать не только про виндовую среду... впрочем, видимо, это было не в интересах MS.
S>А можно пример мест, в которых .net явно заточен под win?

Во-первых, следи за формулировками и не приписывай лишнего. Разница между "явно заточен под Windows" и "подумать не только про Windows" принципиальная, а в данном случае ещё и существенная.
Во-вторых, вот такое хотя бы. По описанному мы отказались от любых попыток завести что-то .NET основанное под Unix для наших задач.
Судя по тому, что сейчас видно, ситуация не лучше — использование .NET под Unix не вышло за пределы одной локальной ниши "графические приблуды под Unity".

Здравствуйте, night beast, Вы писали:

NB>видимо, MS пох. на то, есть ли .NET за пределами виндовса.

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

Здравствуйте, netch80, Вы писали:

S>>А можно пример мест, в которых .net явно заточен под win?

N>Во-первых, следи за формулировками и не приписывай лишнего. Разница между "явно заточен под Windows" и "подумать не только про Windows" принципиальная, а в данном случае ещё и существенная.
Знаешь, если понимать твоё утверждение как "в .net не должно быть вещей, удобных для программирования под win", то всё становится ещё более странным. Напомню, mono существовал с 2005 года, но коммерческого интереса к нему не было вплоть до появления xamarin и возможности разработки под ios/android. Нет коммерческого интереса => нет целевой аудитории => нет необходимости что-либо делать. Вполне логично, что основной интерес уделялся именно возможностям разработки под win.

N>Во-вторых, вот такое хотя бы. По описанному мы отказались от любых попыток завести что-то .NET основанное под Unix для наших задач.
1. По ссылке не совсем .Net, а IronPython, который в официальный список поддерживаемых языков не входит.
2. Претензии по ссылке:
* Нам не подходит типовая перегрузка "OpenFile". File.Open — это просто хелпер, обёртка вокруг "new FileStream(...)". Что мешало сделать свой?
* Грабли с интеропом. Вопрос: вы там точно использовали FileStream.SafeHandle.DangerousGetHandle()? Если да — очевидно баг в mono, в win всё отдаётся корректно.
И это всё?

N>использование .NET под Unix не вышло за пределы одной локальной ниши "графические приблуды под Unity".
Так причина не в технических ограничениях, их немного; реальный софт это подтверждает. Проблема не столько в самом mono, сколько в отсутствии перспектив в массовом портировании managed-софта под lin.

Здравствуйте, Sinix, Вы писали:

S>А можно пример мест, в которых .net явно заточен под win?

Проще будет тебе привести хотя бы одно место, где он не заточен.

Здравствуйте, Sinix, Вы писали:

S>>>А можно пример мест, в которых .net явно заточен под win?

N>>Во-первых, следи за формулировками и не приписывай лишнего. Разница между "явно заточен под Windows" и "подумать не только про Windows" принципиальная, а в данном случае ещё и существенная.
S>Знаешь, если понимать твоё утверждение как "в .net не должно быть вещей, удобных для программирования под win",

А с чего бы его именно так понимать?
В .NET, как в любой подобной среде, есть 1) основа виртуальной машины (байткод и её исполнение), 2) библиотеки, не связанные с ОС или минимально с ней связанные (например, regexps, mutex/CV/etc., очереди, массивы и т.д.), 3) библиотеки, связанные с ОС (например, то же понятие файла уже есть концептуальное ограничение). Для (1) и (2) нет специфики, и с ними всё в порядке. Но в (3) введены _для всех_ особенности работы, которые полезны или вообще имеют смысл только для Windows.
Сравни, например, с Си. Кроме стандартной библиотеки, которая в основном досталась в наследство, ничего из новых добавлений не специфично для Unix, Windows, zOS или любой другой ОС.

S> то всё становится ещё более странным. Напомню, mono существовал с 2005 года,

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

S> но коммерческого интереса к нему не было вплоть до появления xamarin

Суровая коммерческость интереса тут не важна. Есть интересный движок и желание что-то писать под него.

S>1. По ссылке не совсем .Net, а IronPython, который в официальный список поддерживаемых языков не входит.
S>2. Претензии по ссылке:
S>* Нам не подходит типовая перегрузка "OpenFile". File.Open — это просто хелпер, обёртка вокруг "new FileStream(...)". Что мешало сделать свой?

Тем, что это значит брать на себя сопровождение чужого кода (IronPython), тщательно отслеживать его разработку, при мерже ловить все подозрительные места и зачищать их, делать своё пакетирование... дорого, марудно и ненадёжно.
И всё это вместо того, чтобы пусть даже явно вызвать один раз при старте процесса что-то вроде SetRuntimeStyle(STYLE_UNIX) и удовлетвориться результатом во всех смыслах.
Альтернатива, ещё более дурная — делать персональную сборку самого Mono для этого.

S>* Грабли с интеропом. Вопрос: вы там точно использовали FileStream.SafeHandle.DangerousGetHandle()? Если да — очевидно баг в mono, в win всё отдаётся корректно.

_Мы_ _точно_ использовали библиотечные средства Питона, у которых такого вызова нет.

S>И это всё?

А что, мало?

N>>использование .NET под Unix не вышло за пределы одной локальной ниши "графические приблуды под Unity".
S>Так причина не в технических ограничениях, их немного; реальный софт это подтверждает. Проблема не столько в самом mono, сколько в отсутствии перспектив в массовом портировании managed-софта под lin.

Тогда почему полно этих перспектив для написания и портирования managed-софта на Java под Linux?
У меня единственное объяснение — потому что Java создавалась под работу на SysV, а Linux заменил собой SysV для >99% потребителей. И Java рантайм, соответственно, не ставит грабли для Unix.

Здравствуйте, netch80, Вы писали:

N>3) библиотеки, связанные с ОС (например, то же понятие файла уже есть концептуальное ограничение). Для (1) и (2) нет специфики, и с ними всё в порядке. Но в (3) введены _для всех_ особенности работы, которые полезны или вообще имеют смысл только для Windows.
Ну так что мешает lin-сообществу добавить свои хелперы и распространять их через nuget, как это делает МС с большинством новых дополнений? Не, серьёзно: что в IO/WCF/ASP.Net mvc/Ado.NET принципиально завязано на Win?

N>Сравни, например, с Си. Кроме стандартной библиотеки, которая в основном досталась в наследство, ничего из новых добавлений не специфично для Unix, Windows, zOS или любой другой ОС.
В стандарт дотнета входит только ограниченный набор BCL и он в принципе вполне кроссплатформенен. Наличие в mono остальных библиотек и их портируемость — это уже вопрос доброй воли команд MS/mono. Принципиальных отличий от си я тут не вижу.

S>> то всё становится ещё более странным. Напомню, mono существовал с 2005 года,
N>Начал разрабатываться около 2001, согласно википедии. Первые анонсы я помню как раз в те годы. 2004 это уже 1.0, законченная.
Ага, с датами напутал. Имел в виду именно первые более-менее стабильные релизы

N>Суровая коммерческость интереса тут не важна. Есть интересный движок и желание что-то писать под него.
Нет коммерческого интереса — получаем поддержку силами сообщества и закономерный результат в виде "кому нафиг нужен дотнет под lin?". Есть поддержка — получаем xamarin или unity, который покупают, несмотря на ценники вида "килобакс в год для каждого разработчика".

S>>* Нам не подходит типовая перегрузка "OpenFile". File.Open — это просто хелпер, обёртка вокруг "new FileStream(...)". Что мешало сделать свой?
N>Тем, что это значит брать на себя сопровождение чужого кода (IronPython), тщательно отслеживать его разработку, при мерже ловить все подозрительные места и зачищать их, делать своё пакетирование... дорого, марудно и ненадёжно.
А, понял проблему. Тут два варианта: если менять поведение OpenFile в зависимости от платформы — получим падающий при запуске на другой платформе софт. Не менять — получим тормоза и блокировки, коротые в принципе решаются написанием хелпера + заменой кода по всему солюшну.

Ну и это точно проблема самого питона, дотнетовский FileStream использует нативные средства для задания FileShare.None.

S>>* Грабли с интеропом. Вопрос: вы там точно использовали FileStream.SafeHandle.DangerousGetHandle()? Если да — очевидно баг в mono, в win всё отдаётся корректно.
N>_Мы_ _точно_ использовали библиотечные средства Питона, у которых такого вызова нет.
Ага, т.е. обе проблемы сводятся к
1. Мы использовали опенсорсный IronPyton, который абсолютно не портируется под lin
2. Виноват в этом MS так как он не озаботился "при формулировке стандарта .NET подумать не только про виндовую среду"

N>Тогда почему полно этих перспектив для написания и портирования managed-софта на Java под Linux?
N>У меня единственное объяснение — потому что Java создавалась под работу на SysV, а Linux заменил собой SysV для >99% потребителей. И Java рантайм, соответственно, не ставит грабли для Unix.
Абсолютно точно. В тоже время количество явы под win намекает, что проблема работает в обе стороны

Здравствуйте, Sinix, Вы писали:

N>>3) библиотеки, связанные с ОС (например, то же понятие файла уже есть концептуальное ограничение). Для (1) и (2) нет специфики, и с ними всё в порядке. Но в (3) введены _для всех_ особенности работы, которые полезны или вообще имеют смысл только для Windows.
S>Ну так что мешает lin-сообществу добавить свои хелперы и распространять их через nuget, как это делает МС с большинством новых дополнений? Не, серьёзно: что в IO/WCF/ASP.Net mvc/Ado.NET принципиально завязано на Win?

Не знаю. Меня, кажется, ничего из названного не интересует — ни ASP[.NET], ни ADO, ни MVC... а вот проблемы базы, которая требует переделки начиная с ECMA стандарта — оказались существенны.

N>>Суровая коммерческость интереса тут не важна. Есть интересный движок и желание что-то писать под него.
S>>>* Нам не подходит типовая перегрузка "OpenFile". File.Open — это просто хелпер, обёртка вокруг "new FileStream(...)". Что мешало сделать свой?
N>>Тем, что это значит брать на себя сопровождение чужого кода (IronPython), тщательно отслеживать его разработку, при мерже ловить все подозрительные места и зачищать их, делать своё пакетирование... дорого, марудно и ненадёжно.
S>А, понял проблему. Тут два варианта: если менять поведение OpenFile в зависимости от платформы — получим падающий при запуске на другой платформе софт. Не менять — получим тормоза и блокировки, коротые в принципе решаются написанием хелпера + заменой кода по всему солюшну.
S>Ну и это точно проблема самого питона, дотнетовский FileStream использует нативные средства для задания FileShare.None.

Ну не питона в целом, а IronPython, но таки да.

S>>>* Грабли с интеропом. Вопрос: вы там точно использовали FileStream.SafeHandle.DangerousGetHandle()? Если да — очевидно баг в mono, в win всё отдаётся корректно.
N>>_Мы_ _точно_ использовали библиотечные средства Питона, у которых такого вызова нет.
S>Ага, т.е. обе проблемы сводятся к
S>1. Мы использовали опенсорсный IronPyton, который абсолютно не портируется под lin
S>2. Виноват в этом MS так как он не озаботился "при формулировке стандарта .NET подумать не только про виндовую среду"
S>

Вот ты не смог, конечно, удержаться и не написать, кто "виноват". Я ни слова говорил про _вину_. Я говорил про источник проблемы. Разницу видишь?

N>>Тогда почему полно этих перспектив для написания и портирования managed-софта на Java под Linux?
N>>У меня единственное объяснение — потому что Java создавалась под работу на SysV, а Linux заменил собой SysV для >99% потребителей. И Java рантайм, соответственно, не ставит грабли для Unix.
S>Абсолютно точно. В тоже время количество явы под win намекает, что проблема работает в обе стороны

Угу. И при выборе — Java или .NET — для меня выбор очевиден. Несмотря на опережение C# + .NET в некоторых областях.

Здравствуйте, netch80, Вы писали:

N>Угу. И при выборе — Java или .NET — для меня выбор очевиден. Несмотря на опережение C# + .NET в некоторых областях.

Это в каких же областях дотнет опережает??

Здравствуйте, Vzhyk, Вы писали:

S>>А можно пример мест, в которых .net явно заточен под win?

V>Проще будет тебе привести хотя бы одно место, где он не заточен.
Открываем MSDN и читаем, пропуская платформенно-зависимые штуки типа winforms и EnterpriseServices

Здравствуйте, netch80, Вы писали:

N>Не знаю. Меня, кажется, ничего из названного не интересует — ни ASP[.NET], ни ADO, ни MVC... а вот проблемы базы, которая требует переделки начиная с ECMA стандарта — оказались существенны.
Ну а нафиг тогда .net? Что там остаётся такого, что нельзя заменить простым питоном или явой?

N>Ну не питона в целом, а IronPython, но таки да.
N>Вот ты не смог, конечно, удержаться и не написать, кто "виноват". Я ни слова говорил про _вину_. Я говорил про источник проблемы. Разницу видишь?
Не, пойнт не в том. Аналогия (сильно утрирую): мы используем библиотеку на си, которая не портируется под lin, но виноват в этом язык, т.к. Страуструп при разработке не озаботился подумать про non-unix-системы.

Портируемость оговорена явно для подчасти BCL (при соблюдении языком CLS конечно). Всё остальное — на совести разработчиков конкретного языка/библиотеки. Если они закладывают поведение отличное от дефолтного (и тем более не дают его поменять), то MS тут ничем помочь не может.

N>Угу. И при выборе — Java или .NET — для меня выбор очевиден. Несмотря на опережение C# + .NET в некоторых областях.
Ну так области использования у них пересекаются редко, так уж сложилось. Если ничего из возможностей .net не нужно (или не хватает того что в .net нет) — зачем кушать кактус?

Здравствуйте, Vzhyk, Вы писали:

V>Здравствуйте, Sinix, Вы писали:

S>>А можно пример мест, в которых .net явно заточен под win?

V>Проще будет тебе привести хотя бы одно место, где он не заточен.

Ну давай к примеру возьмем класс System.String, покажешь, в каком месте он заточен под винду?

... << RSDN@Home 1.2.0 alpha 5 rev. 1495>>

Здравствуйте, Sinix, Вы писали:

N>>Не знаю. Меня, кажется, ничего из названного не интересует — ни ASP[.NET], ни ADO, ни MVC... а вот проблемы базы, которая требует переделки начиная с ECMA стандарта — оказались существенны.
S>Ну а нафиг тогда .net? Что там остаётся такого, что нельзя заменить простым питоном или явой?

Идея была опробовать для питона другой движок. Предполагалось, будет заметно шустрее.

N>>Угу. И при выборе — Java или .NET — для меня выбор очевиден. Несмотря на опережение C# + .NET в некоторых областях.
S>Ну так области использования у них пересекаются редко, так уж сложилось. Если ничего из возможностей .net не нужно (или не хватает того что в .net нет) — зачем кушать кактус?

Так вот и не кушаем

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

Здравствуйте, Cadet, Вы писали:

C>Ну давай к примеру возьмем класс System.String, покажешь, в каком месте он заточен под винду?

Дык тру-юникс-строчка должна жеж быть UTF-8 и никак иначе. Иначе неправославненько и вообще богомерзко жеж?..

Здравствуйте, netch80, Вы писали:

N>Идея была опробовать для питона другой движок. Предполагалось, будет заметно шустрее.
Енто все поняли, но выяснилось, что те, кто айронпитон делали, сделали как раз так, как тебе нравится. Типа поменяли все умолчания на такие, которые они естественными считают, а на совместимость тупо забили. Да. так что этот ваш айронпитон -- та ещё какашка. Странно, что ты на неё посмотрел и теперь говоришь, что мновоцы не молодцы, что так же не стали делать. Это то, чего лияно я не понял в твоей позиции.
Но ты самое интересное не осветил, шустрее-то получилось?..

N>Так вот и не кушаем

Дык вот не надо насиловать природу просто. Нет бы вот по шерсти кактусы глотать, а вы всё не с того конца заглотунть стараетсь

Здравствуйте, Erop, Вы писали:

E>Дык тру-юникс-строчка должна жеж быть UTF-8 и никак иначе. Иначе неправославненько и вообще богомерзко жеж?..

А какая она в дотнете по-твоему?

Здравствуйте, koandrew, Вы писали:

K>А какая она в дотнете по-твоему?
Дык Char жеж, AKA UTF-16...

Здравствуйте, Erop, Вы писали:

E>Здравствуйте, Cadet, Вы писали:

C>>Ну давай к примеру возьмем класс System.String, покажешь, в каком месте он заточен под винду?

E>Дык тру-юникс-строчка должна жеж быть UTF-8 и никак иначе. Иначе неправославненько и вообще богомерзко жеж?..

Ну ок, с натяжкой согласиться можно

. Что в общем то не отменяет того факта, что это исключительно вопрос внутренней реализации программы, написанной на дотнете, и все манипуляции с внешними источниками, ака файлами, один шут по умолчанию производятся в UTF-8, см. дефолтные параметры в StreamWriter например.

... << RSDN@Home 1.2.0 alpha 5 rev. 1495>>

Здравствуйте, night beast, Вы писали:

NB>ок. и что мешает тебе пропихнуть моно, а потом под шумок поменять серваки?

Моно пока всерьёз никто не воспринимает. Хотя это, конечно, тоже больше отмазка, чем реальность. Да и не думаю, что с Моно всё так хорошо. Например, не уверен, что для Моно существует ADO.NET драйвер для DB2. Он для Windows наполовину нативный, а уже для Моно им вряд ли кто-то озаботился.

Здравствуйте, Sinix, Вы писали:

S>Такой вопрос: а как сейчас с CAL к winserver? Насколько я помню, варианта всего два или затариваться External Connector+per-cpu CAL, или надеяться что не заметят

Понятия не имею.

Здравствуйте, neFormal, Вы писали:

IT>>серверные приложения должны иметь возможность работать на Линухе.
F>всё правильно

Ничего правильного. Голимая отмазка. Ещё ни разу в жизни не видел ни одного приложения в корпоративной среде, которому была бы нужна многоплатформенность. Если вдруг нужно поменять платформу, то это в первую очередь означает, что приложение серьёзно больно и его не только будут переносить в другое место, но ещё и серьёзно лечить, т.е. скорее всего переписывать с нуля. А многоплатформенность в корпоративной среде — это миф.

Здравствуйте, IT, Вы писали:

NB>>ок. и что мешает тебе пропихнуть моно, а потом под шумок поменять серваки?

IT>Моно пока всерьёз никто не воспринимает. Хотя это, конечно, тоже больше отмазка, чем реальность. Да и не думаю, что с Моно всё так хорошо.

а ты попробуй, может чего получится... а там глядишь, и сервера виндовые подоспеют.

IT>Например, не уверен, что для Моно существует ADO.NET драйвер для DB2. Он для Windows наполовину нативный, а уже для Моно им вряд ли кто-то озаботился.

здесь?

Здравствуйте, night beast, Вы писали:

IT>>Моно пока всерьёз никто не воспринимает. Хотя это, конечно, тоже больше отмазка, чем реальность. Да и не думаю, что с Моно всё так хорошо.
NB>а ты попробуй, может чего получится... а там глядишь, и сервера виндовые подоспеют.

Пробовал. В ответ мидлфингер. На новом проекте этого не требуется. Здесь мы придумали обходной манёвр. Будем выбивать .NET и Sql Server. Но это может занять одних бумажек и согласований до полу года.

IT>>Например, не уверен, что для Моно существует ADO.NET драйвер для DB2. Он для Windows наполовину нативный, а уже для Моно им вряд ли кто-то озаботился.
NB>здесь?

Надо попробовать будет ли оно работать с linq2db.

Здравствуйте, Erop, Вы писали:

E>Дык Char жеж, AKA UTF-16...

Close enough

Здравствуйте, Cadet, Вы писали:

[]

C>Ну давай к примеру возьмем класс System.String, покажешь, в каком месте он заточен под винду?

Данубожемой, вот с первой жеж буквы — system это у нас что? Система. А система у мелкомягких какая? Правильно, венда.
Ergo, System.String заточен под винду!!111

Здравствуйте, Sinix, Вы писали:

S>Не, серьёзно: что в IO/WCF/ASP.Net mvc/Ado.NET принципиально завязано на Win?

В IO действительно по мелочам явно хвосты Win32 торчат. Что, впрочем, не фатально. В WCF и ADO.NET, несмотря на их названия — ничего, там интероперабельнойсть — насущная необходимость. C ASP.NET внизу есть определенные подвязки (не на win32, а на МСную веб-инфраструктуру), поэтому OWIN.

Здравствуйте, Cadet, Вы писали:

C>>>Ну давай к примеру возьмем класс System.String, покажешь, в каком месте он заточен под винду?

C>Ну ок, с натяжкой согласиться можно

Здравствуйте, alexanderfedin, Вы писали:

A>Компания зарабатывает деньги не на продаже .NET, а на продаже операционной системы Windows. .NET — это средство для облегчения создания программ под Windows сторонним производителям, а не способ облегчить перенос этих программ на другие платформы.

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

Здравствуйте, Erop, Вы писали:

N>>Так вот и не кушаем

E>Дык вот не надо насиловать природу просто. Нет бы вот по шерсти кактусы глотать, а вы всё не с того конца заглотунть стараетсь

Проблема в том, что у кактуса иголки во все стороны равномерно смотрят. Нельзя сказать, куда "по шерсти".

Здравствуйте, Privalov, Вы писали:

N>>>Так вот и не кушаем

E>>Дык вот не надо насиловать природу просто. Нет бы вот по шерсти кактусы глотать, а вы всё не с того конца заглотунть стараетсь

P>Проблема в том, что у кактуса иголки во все стороны равномерно смотрят. Нельзя сказать, куда "по шерсти".

Довольно большое количество дотнетовских проектов, как бы намекает, что это просто вы не умеете их готовить...

Здравствуйте, Patalog, Вы писали:

C>>Ну давай к примеру возьмем класс System.String, покажешь, в каком месте он заточен под винду?
P>Данубожемой, вот с первой жеж буквы — system это у нас что? Система. А система у мелкомягких какая? Правильно, венда.
P>Ergo, System.String заточен под винду!!111
Тогда Java, JavaScript и HTML DOM тоже заточен под винду.

Здравствуйте, netch80, Вы писали:

N>А всего-то надо было при формулировке стандарта .NET подумать не только про виндовую среду... впрочем, видимо, это было не в интересах MS.
В стандарте нет ничего платформозависимого.
А вот в рантайме, есть много вещей, которые сложно перенести в силу того, что в других ОС не хватает каких-то важных кусков.

Один из них многопоточность.
В самом центре .NET-ового thread pool и всего асинхронного IO лежит IO completion port.
Это объект ядра, уникальный для винды (в *nix какие-то потуги, а именно kqueue и epoll, появились на много лет позже, и намного хуже работают), и хорошо интегрированный в остальные API (в linux почему-то epoll только для сокетов, а для файлов не особо совместимый native AIO).
Соответственно, асинхронный IO (и построенные на его основе технологии вроде async-await) на других платформах неизбежно будут глючить и/или тормозить.

Второй из них 3D графика.
На всех современных .NET платформах годные GPU с эффективными и стабильными дровами к ним.
Поэтому в современной венде, hardware-accelerated 3D graphics используется даже для отображения текста и 2D графики.
Именно это позволило построить поверх .NET всякие WPF и Silverlight, с быстрой и красивой графикой, плавной анимацией и пиксельными шейдерами, прекрасно работающие даже на слабых ARM процессорах с FullHD экранами.

Соответственно, «подумать не только про виндовую среду» означало бы, что .NET лишился бы существенных преимуществ, и стал бы ещё одной Java, которая конечно переносима ОК, только ни на одной платформе нормально не работает

Здравствуйте, Константин, Вы писали:

К>В самом центре .NET-ового thread pool и всего асинхронного IO лежит IO completion port.
К>Это объект ядра, уникальный для винды (в *nix какие-то потуги, а именно kqueue и epoll, появились на много лет позже, и намного хуже работают), и хорошо интегрированный в остальные API (в linux почему-то epoll только для сокетов, а для файлов не особо совместимый native AIO).
AIO никто не использует, так как для файлового IO проще использовать пулы потоков. Под Виндой, кстати, тоже из-за некоторых приколов типа блокирующегося CloseHandle.

За пределами файлового IO, epoll работает быстрее Overlapped IO из-за лучшей оптимизации TCP-стека в Линуксе.

К>Соответственно, асинхронный IO (и построенные на его основе технологии вроде async-await) на других платформах неизбежно будут глючить и/или тормозить.
Хех. Разработчики Nodejs, libev и других мультиплексирующих систем под Юниксы недоумевают.

http://www.salmanq.com/blog/net-and-node-js-performance-comparison/2013/03/

Здравствуйте, Cyberax, Вы писали:

К>>В самом центре .NET-ового thread pool и всего асинхронного IO лежит IO completion port.
К>>Это объект ядра, уникальный для винды (в *nix какие-то потуги, а именно kqueue и epoll, появились на много лет позже, и намного хуже работают), и хорошо интегрированный в остальные API (в linux почему-то epoll только для сокетов, а для файлов не особо совместимый native AIO).
C>AIO никто не использует, так как для файлового IO проще использовать пулы потоков.
Проще не значит эфективнее.

C>Под Виндой, кстати, тоже
Нет, под виндой не тоже: в .NET это прекрасно работает.

C>приколов типа блокирующегося CloseHandle
Он блокируется только если есть pending операции.
При правильном использовании (сначала подождать завершения pending IO потом закрывать) ничо не блокируется.

C>За пределами файлового IO, epoll работает быстрее Overlapped IO из-за лучшей оптимизации TCP-стека в Линуксе.
Подтверждения "лучшей оптимизации TCP-стека в Линуксе" есть какие-то?

К>>Соответственно, асинхронный IO (и построенные на его основе технологии вроде async-await) на других платформах неизбежно будут глючить и/или тормозить.
C>Хех. Разработчики Nodejs, libev и других мультиплексирующих систем под Юниксы недоумевают.
Разработчики этих систем не пишут на .NET.
Чтобы посмотреть, что получается при портировании, смотрите производитиельность Node.js на винде: они там не то что IOCP, даже overlapped IO не смогли, используют select, с ожидаемым результатом по производительности.
Если бы .NET framework проектировался кросс-платформенным, об эффективном асинхронном IO можно было бы забыть, см. например состояние этого в Java.

C>http://www.salmanq.com/blog/net-and-node-js-performance-comparison/2013/03/
C>[img]
C>http://1-ps.googleusercontent.com/h/www.salmanq.com/wp-content/uploads/2013/03/performance-comparison-net-nodejs.png.pagespeed.ce.1YsnSc2NdF.png
C>[/img]
На красивом графике мы видим, что уже 200 одновременных запросах (что в условиях того теста всего лишь 67 запросов в секунду) .NET становится быстрее NodeJS.
Ничего удивительного для меня в этом нет: очевидно же, что на винде, где multiplexed IO развивается ещё с 1993 года, оно будет лучше работать.

Здравствуйте, Константин, Вы писали:

К>Если бы .NET framework проектировался кросс-платформенным, об эффективном асинхронном IO можно было бы забыть, см. например состояние этого в Java.

Я правильно понимаю, что на .net подразумевается писать исключительно серверы, причём рассчитанные на работу с тысячами одновременных запросов? )

Здравствуйте, alex_public, Вы писали:

К>>Если бы .NET framework проектировался кросс-платформенным, об эффективном асинхронном IO можно было бы забыть, см. например состояние этого в Java.
_>Я правильно понимаю, что на .net подразумевается писать исключительно серверы, причём рассчитанные на работу с тысячами одновременных запросов? )
Среда, где не особо считают ресурсы, это только PC, причём только стационарные.
Даже на ноутах с таблетками имеет значение эффективность кода — времени CPU может и не очень жалко т.к. мощи много, жалко батарейку.

А уж на мобильниках и подавно — там и камни слабые, и батареи маленькие.
Сравните например производительность Nokia Lumia 510 с Samsung Galaxy Mini 2 (в обоих Snapdragon S1 MSM7227A).
Или, в следующем поколении, например Nokia Lumia 525 с Sony Xperia M (в обоих Snapdragon S4 MSM8227).

Здравствуйте, Константин, Вы писали:

К>Среда, где не особо считают ресурсы, это только PC, причём только стационарные.
К>Даже на ноутах с таблетками имеет значение эффективность кода — времени CPU может и не очень жалко т.к. мощи много, жалко батарейку.

К>А уж на мобильниках и подавно — там и камни слабые, и батареи маленькие.
К>Сравните например производительность Nokia Lumia 510 с Samsung Galaxy Mini 2 (в обоих Snapdragon S1 MSM7227A).
К>Или, в следующем поколении, например Nokia Lumia 525 с Sony Xperia M (в обоих Snapdragon S4 MSM8227).

А причём тут это всё? ) Я подразумевал совсем не то, что вне нагруженных серверов наплевать на ресурсы. Я намекаю, что асинхронный IO будет эффективнее обычного многопоточного только на очень узком круге задач.

Здравствуйте, alex_public, Вы писали:

_>Я подразумевал совсем не то, что вне нагруженных серверов наплевать на ресурсы.
_>Я намекаю, что асинхронный IO будет эффективнее обычного многопоточного только на очень узком круге задач.
Это ошибка так считать.
Как только число одновременно работающих файлов/сокетов сравняется с числом ядер, асинхронный IO станет эффективнее.
Если в системе есть и другие активные процессы, "эффективнее" станет "в разы эффективнее".
А если число файлов на пару порядков превысит число ядер, у вас тупо кончится память, потому что потоки очень дорогой системный ресурс.

«обычный многопоточный IO» более-менее пригоден только для hello world, и ещё для очень узкого класса приложений, например что-то вроде офиса, когда все данные в RAM, а от IO требуется только [де]сериализация раз в полчаса на быстрый локальный диск.
Посмотрите ради интереса, какое API использует скажем chromium для работы с диском и сетью.

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

Здравствуйте, Константин, Вы писали:

К>Как только число одновременно работающих файлов/сокетов сравняется с числом ядер, асинхронный IO станет эффективнее.

Нет, эффективнее он будет при намного большем числе задач.

К>Если в системе есть и другие активные процессы, "эффективнее" станет "в разы эффективнее".

В разы при десятках потоков? ) Это даже не смешно.

К>А если число файлов на пару порядков превысит число ядер, у вас тупо кончится память, потому что потоки очень дорогой системный ресурс.

На пару порядков — это около 400 потоков? И снова смешная цифра... Винда конечно не самая лучшая система, но не настолько же: http://www.rsdn.ru/forum/philosophy/5380354

К>«обычный многопоточный IO» более-менее пригоден только для hello world, и ещё для очень узкого класса приложений, например что-то вроде офиса, когда все данные в RAM, а от IO требуется только [де]сериализация раз в полчаса на быстрый локальный диск.

И что это за обычные десктопные приложения, которые требует сотен одновременных IO потоков? )

К>Посмотрите ради интереса, какое API использует скажем chromium для работы с диском и сетью.

http://www.chromium.org/developers/design-documents/threading угу) И ни слова про эффективность, исключительно архитектурные нюансы.

К>Например, по этой причине из нового WinAPI повыкидывали вызовы, которые могут блокировать вызывающий поток хотя бы на 50 миллисекунд.

Ну посмотрим как много софта перейдёт на это дело... )

Здравствуйте, Константин, Вы писали:

C>>AIO никто не использует, так как для файлового IO проще использовать пулы потоков.
К>Проще не значит эфективнее.
Примерно значит. Дело в том, что для AIO (что в Винде, что в Линуксе) всё равно в итоге используется поток в ядре — для создания объектов, поиска данных в кэше, обслуживания очереди и т.п. Выигрыш от AIO будет, если есть очень большая очередь IO-запросов.

Дело только в том, что по сравнению с сетью у дискового IO меньше масштабируемость. Обычно даже пара десятков параллельных writer'ов или reader'ов — это слишком много для вращающихся дисков.

C>>Под Виндой, кстати, тоже
К>Нет, под виндой не тоже: в .NET это прекрасно работает.
Тоже.

C>>приколов типа блокирующегося CloseHandle
К>Он блокируется только если есть pending операции.
К>При правильном использовании (сначала подождать завершения pending IO потом закрывать) ничо не блокируется.
Нет такой гарантии — и на практике оно тормозит. Кстати, такой операции вообще в overlapped нет.

C>>За пределами файлового IO, epoll работает быстрее Overlapped IO из-за лучшей оптимизации TCP-стека в Линуксе.
К>Подтверждения "лучшей оптимизации TCP-стека в Линуксе" есть какие-то?
http://www.slideshare.net/PrincipledTechnologies/comparing-network-performance-red-hat-enterprise-linux-6-vs-microsoft-windows-server-2012 — для примера

К>>>Соответственно, асинхронный IO (и построенные на его основе технологии вроде async-await) на других платформах неизбежно будут глючить и/или тормозить.
C>>Хех. Разработчики Nodejs, libev и других мультиплексирующих систем под Юниксы недоумевают.
К>Разработчики этих систем не пишут на .NET.
А что, .NET магически имеет свой IO-стек?

К>Чтобы посмотреть, что получается при портировании, смотрите производитиельность Node.js на винде: они там не то что IOCP, даже overlapped IO не смогли, используют select, с ожидаемым результатом по производительности.
Не надо говорить о том, чего не знаешь. В libuv (и nodejs) используется Overlapped IO. См.: https://github.com/joyent/libuv/blob/master/src/win/core.c

К>Если бы .NET framework проектировался кросс-платформенным, об эффективном асинхронном IO можно было бы забыть, см. например состояние этого в Java.

C>>http://1-ps.googleusercontent.com/h/www.salmanq.com/wp-content/uploads/2013/03/performance-comparison-net-nodejs.png.pagespeed.ce.1YsnSc2NdF.png
К>На красивом графике мы видим, что уже 200 одновременных запросах (что в условиях того теста всего лишь 67 запросов в секунду) .NET становится быстрее NodeJS.
Эээ.. Вообще-то, на графике показано, что до 200 соединений у nodejs меньше латентность. Т.е. работает она быстрее. Более 200 соединений тестов просто нет.

К>Ничего удивительного для меня в этом нет: очевидно же, что на винде, где multiplexed IO развивается ещё с 1993 года, оно будет лучше работать.
Нет, его задизайнили в 93-м и с тех пор вынуждены это пииииии поддерживать из-за невозможности сделать полноценный рефакторинг. В Линуксе оно началось с тупой реализации, которую потом несколько раз переписали до того, что она сейчас лучшая в мире.

Здравствуйте, Константин, Вы писали:

К>«обычный многопоточный IO» более-менее пригоден только для hello world, и ещё для очень узкого класса приложений, например что-то вроде офиса, когда все данные в RAM, а от IO требуется только [де]сериализация раз в полчаса на быстрый локальный диск.
К>Посмотрите ради интереса, какое API использует скажем chromium для работы с диском и сетью.
Блокирующийся IO для файлового IO и epoll/kqueue/overlapped для сети. То что они сегрегируют IO и процессы-рендереры не считаем — внутри дочерних процессов используется только асинхронный API для всего.

Здравствуйте, alex_public, Вы писали:

_>Я намекаю, что асинхронный IO будет эффективнее обычного многопоточного только на очень узком круге задач.

В этот узкий круг, помимо серверов, входят, как минимум, смартфоны. Именно поэтому в WP искусственно покоцан весь синхронный IO из API.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>В этот узкий круг, помимо серверов, входят, как минимум, смартфоны. Именно поэтому в WP искусственно покоцан весь синхронный IO из API.

С чего бы это? )

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>К какой части высказывания вопрос?

К первой. )

Здравствуйте, alex_public, Вы писали:

НС>>В этот узкий круг, помимо серверов, входят, как минимум, смартфоны. Именно поэтому в WP искусственно покоцан весь синхронный IO из API.
_>С чего бы это? )
тут речь о наблюдаемой производительности (aka perceived performance).

Под wp/winrt большинство тяжёлых операций можно выполнить только асинхронно. Благодаря этому надо очень постараться, чтобы завесить UI-поток (и с определённой долей вероятности такое приложение не пройдёт в маркет). В прочих мобильных ОС ситуация прямо противоположная

Здравствуйте, Константин, Вы писали:

К>В стандарте нет ничего платформозависимого.
К>А вот в рантайме, есть много вещей, которые сложно перенести в силу того, что в других ОС не хватает каких-то важных кусков.
К>Один из них многопоточность.
К>В самом центре .NET-ового thread pool и всего асинхронного IO лежит IO completion port.

В моём случае всё, что нужно было для целевого приложения, уже было перенесено. Там даже обычного poll() хватало с головой для работы, потому что не было "10k" параллельных клиентов с отдельными соединениями на каждого, а был один большой сокет на всё. Плюс несколько небольших пулов ниток для медленных партнёров типа БД.

К>Это объект ядра, уникальный для винды (в *nix какие-то потуги, а именно kqueue и epoll, появились на много лет позже, и намного хуже работают),

Последнее утверждение требует обоснования, как минимум про kqueue.

К> и хорошо интегрированный в остальные API (в linux почему-то epoll только для сокетов, а для файлов не особо совместимый native AIO).

И в Linux, и во FreeBSD тот же AIO работает неплохо. Правда, в случае Linux нет адекватной связи между AIO и epoll (или я её не знаю). Для FreeBSD EVFILT_AIO подключает статус завершения операции.

К>Соответственно, асинхронный IO (и построенные на его основе технологии вроде async-await) на других платформах неизбежно будут глючить и/или тормозить.

Я не увидел достаточно обоснований для такого вывода.

К>Второй из них 3D графика.

Как уже сказал, мне она тут совершенно пофиг, у меня другие задачи.

К>Соответственно, «подумать не только про виндовую среду» означало бы, что .NET лишился бы существенных преимуществ, и стал бы ещё одной Java, которая конечно переносима ОК, только ни на одной платформе нормально не работает

"Нормально" для каких целей? Сеть — штука на 99% кроссплатформенная.

Здравствуйте, netch80, Вы писали:

К>> и хорошо интегрированный в остальные API (в linux почему-то epoll только для сокетов, а для файлов не особо совместимый native AIO).
N>И в Linux, и во FreeBSD тот же AIO работает неплохо. Правда, в случае Linux нет адекватной связи между AIO и epoll (или я её не знаю).
Есть несколько вариантов:
1) Использовать сигналы для нотификаций — напрямую или через signalfd().
2) eventfd() для превращения event'ов в дескрипторы для epoll()

Здравствуйте, Константин, Вы писали:

_>>Я подразумевал совсем не то, что вне нагруженных серверов наплевать на ресурсы.
_>>Я намекаю, что асинхронный IO будет эффективнее обычного многопоточного только на очень узком круге задач.
К>Это ошибка так считать.
К>Как только число одновременно работающих файлов/сокетов сравняется с числом ядер, асинхронный IO станет эффективнее.

С этим вполне можно согласиться (хотя детали организации могут портить картину).

К>Если в системе есть и другие активные процессы, "эффективнее" станет "в разы эффективнее".
К>А если число файлов на пару порядков превысит число ядер, у вас тупо кончится память, потому что потоки очень дорогой системный ресурс.

Серьёзно, винда на среднем десктопе от 400 ниток уже выжирает память? Что-то мне даже про неё не верится. Linux спокойно выдержит тысяч 30 при дефолтных настройках и миллионы при разумном тюнинге. Кажется, Вы что-то таки спутали.
Или речь про адресное пространство в 32 битах? Тогда не надо говорить про "дорогой системный ресурс", это не системный ресурс, а ресурс процесса.

Если принять за основу, что нить в Windows очень дорога в держании и переключении, то неудивительно стремление MS к IOCP — выигрыш идёт действительно в разы. В Linux разница значительно меньше.

К>«обычный многопоточный IO» более-менее пригоден только для hello world, и ещё для очень узкого класса приложений, например что-то вроде офиса, когда все данные в RAM, а от IO требуется только [де]сериализация раз в полчаса на быстрый локальный диск.
К>Посмотрите ради интереса, какое API использует скажем chromium для работы с диском и сетью.

Это показывает пока что только то, что его изначально рассчитывали в том числе и на системы, где нить является крайне дорогой сущностью (как по Вашему описанию в Windows).
API в стиле "заказать операцию, ждать callback", кроме того, универсально тем, что оно достаточно легко превращается с помощью врапперов в API с ожиданием результата, если требуется таки синхронная реализация (в первый раз такую технологию использовали, кажется, ещё в OS/360). Но это значит всего лишь, что выставлены в userland ядерные потроха (с минимальной защитой).

К>Например, по этой причине из нового WinAPI повыкидывали вызовы, которые могут блокировать вызывающий поток хотя бы на 50 миллисекунд.

И в результате 99% индусов будут писать в духе

    startOperation();
    waitOnEvent(operation_finished);

эффективно умножая эти старания разработчиков WinAPI на ноль.

Здравствуйте, Cyberax, Вы писали:

К>>> и хорошо интегрированный в остальные API (в linux почему-то epoll только для сокетов, а для файлов не особо совместимый native AIO).
N>>И в Linux, и во FreeBSD тот же AIO работает неплохо. Правда, в случае Linux нет адекватной связи между AIO и epoll (или я её не знаю).
C>Есть несколько вариантов:
C>1) Использовать сигналы для нотификаций — напрямую или через signalfd().

Похоже. Но сигналов тут ограниченное количество.

C>2) eventfd() для превращения event'ов в дескрипторы для epoll()

Примеры, которые я вижу, используют io_submit(), который фиг так просто вызовешь.
Интересно, почему не lio_listio().

Здравствуйте, netch80, Вы писали:

N>Серьёзно, винда на среднем десктопе от 400 ниток уже выжирает память? Что-то мне даже про неё не верится. Linux спокойно выдержит тысяч 30 при дефолтных настройках и миллионы при разумном тюнинге. Кажется, Вы что-то таки спутали.
N>Если принять за основу, что нить в Windows очень дорога в держании и переключении, то неудивительно стремление MS к IOCP — выигрыш идёт действительно в разы. В Linux разница значительно меньше.
Дело не столько в "дорога в держании и переключении", сколько в накладных расходах на kernel switch и загруженный впустую планировщик. Сравни сам:

        static void Main(string[] args)
        {
            //RunTasks().Wait();
            RunThreads();
        }

        static int s_TaskCount;
        static async Task RunTasks()
        {
            int i = 0;
            while (true)
            {
                i++;
                Task.Run(async () =>
                    {
                        Interlocked.Increment(ref s_TaskCount);
                        await Task.Delay(5000).ConfigureAwait(false);
                        Interlocked.Decrement(ref s_TaskCount);
                    });

                i++;
                if (i % 100 == 0)
                {
                    await Task.Yield();
                    Console.WriteLine(s_TaskCount.ToString("N"));
                }
            }
        }

        static int s_ThreadsCount;
        static void RunThreads()
        {
            int i = 0;
            while (true)
            {
                new Thread(() =>
                    {
                        Interlocked.Increment(ref s_ThreadsCount);
                        Thread.Sleep(5000);
                        Interlocked.Decrement(ref s_ThreadsCount);
                    },
                    100 * 1024).Start();

                i++;
                if (i % 100 == 0)
                {
                    Console.WriteLine(s_ThreadsCount.ToString("N"));
                    Thread.Yield();
                }
            }
        }

Вариант с потоками под x86 затыкается с OutOfMemory уже на ~3000 потоков (несмотря на стек в 100 кб), под x64 — стабилизируется где-то на 30k потоков.
Вариант с тасками спокойно пережёвывает 800k одновременно работающих тасков.

Если перейти на пул потоков с IOCP при должном везении получается нечто среднее.

N>И в результате 99% индусов будут писать в духе

    startOperation();
    waitOnEvent(operation_finished);

С вероятностью выше >>0.5 не пройдёт тест в маркете. Даже не ручное тестирование, а WACK tool.

Здравствуйте, netch80, Вы писали:

C>>Есть несколько вариантов:
C>>1) Использовать сигналы для нотификаций — напрямую или через signalfd().
N>Похоже. Но сигналов тут ограниченное количество.
Для простой нотификации сойдёт — просто прервать epoll и дальше посмотреть что там пришло.

C>>2) eventfd() для превращения event'ов в дескрипторы для epoll()
N>Примеры, которые я вижу, используют io_submit(), который фиг так просто вызовешь.
N>Интересно, почему не lio_listio().
Должно работать и с ним.

Здравствуйте, Sinix, Вы писали:

S>Под wp/winrt большинство тяжёлых операций можно выполнить только асинхронно. Благодаря этому надо очень постараться, чтобы завесить UI-поток (и с определённой долей вероятности такое приложение не пройдёт в маркет). В прочих мобильных ОС ситуация прямо противоположная

Ну так а зачем запускать тяжёлые операции в UI потоке, а не в отдельном? )

Здравствуйте, alex_public, Вы писали:

_>Ну так а зачем запускать тяжёлые операции в UI потоке, а не в отдельном? )
В терминах мобильных приложений к "тяжёлым" относится всё, что может завесить поток больше, чем на 50 миллисекунд. Т.е. любой ввод-вывод как минимум.

Жёстко конечно, зато я не видел ни одного намертво зависшего приложения под wp/winrt, в отличие от всех прочих платформ.

Здравствуйте, Sinix, Вы писали:

S>Дело не столько в "дорога в держании и переключении", сколько в накладных расходах на kernel switch и загруженный впустую планировщик. Сравни сам:
S>...
S>Вариант с потоками под x86 затыкается с OutOfMemory уже на ~3000 потоков (несмотря на стек в 100 кб), под x64 — стабилизируется где-то на 30k потоков.

Это исключительно проблемы .net'a. ) Аналогичный код на C++ спокойно стабилизируется где-то на 11 000 потоков на древнейшей машине (WinXP 32 бита, Core2Duo, 2Гб). Т.е. на современном процессоре было бы под 50К (на тех же 32 битах).

S>Вариант с тасками спокойно пережёвывает 800k одновременно работающих тасков.

Естественно. Потому как этот тест измеряет совсем другое. Тут скорее соревнование в накладных расходах на создание потока/задачи. И т.к. здесь время работы (а не жизни) потока микроскопическое в сравнение с процессом создания потока (а у внутренних задачек тут всё хорошо), то такой вариант естественно получается невыгодным. А вот если эти же 5 секунд поток/задача будут заняты вычислениями, то у нас будет совсем другой расклад...

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

Здравствуйте, Sinix, Вы писали:

_>>Ну так а зачем запускать тяжёлые операции в UI потоке, а не в отдельном? )
S>В терминах мобильных приложений к "тяжёлым" относится всё, что может завесить поток больше, чем на 50 миллисекунд. Т.е. любой ввод-вывод как минимум.

И как это отвечает на мой вопрос? )

S>Жёстко конечно, зато я не видел ни одного намертво зависшего приложения под wp/winrt, в отличие от всех прочих платформ.

Похоже что данного преимущества недостаточно для популярности платформы. Кстати, сама винда это показывала в далёком прошлом: более открытая платформа выигрывает, даже если она более глючная.

Здравствуйте, alex_public, Вы писали:

_>Это исключительно проблемы .net'a. ) Аналогичный код на C++ спокойно стабилизируется где-то на 11 000 потоков на древнейшей машине (WinXP 32 бита, Core2Duo, 2Гб). Т.е. на современном процессоре было бы под 50К (на тех же 32 битах).
Вот тут я не уверен честно говоря

От .net-а там всего ничего, почти всё уходит в нативные вызовы. Как вариант — выложите бинарник, проверю.
Кстати, а в запускаюшем коде есть что-то типа Thread.Yield? Без него "рабочие" потоки скорее ждут своей очереди на завершение чем работают. С тасками так счётчик растёт до нескольких миллионов, что конечно же неверно.

S>>А вот если эти же 5 секунд поток/задача будут заняты вычислениями, то у нас будет совсем другой расклад...
Ну да. Тогда максимально эффективным будет подход "поток на ядро" (плюс-минус). Таски/пулы потоков в принципе именно этим и занимаются, просто делают балансировку незаметной для пользователя

_>Но вообще, я конечно же согласен, что в случае многих тысяч одновременных задач правильнее переходит от системной многозадачности, к внутренней рукопашной (и как следствие этого, асинхронный IO). Только это же у нас опять же получается крайне узкая область применения, о чём я и говорил изначально.
Это во многом зависит от дизайна языка и фреймворка. Для дотнета замена абсолютно прозрачна. Для скалы/эрланга — незаметна в принципе.

Здравствуйте, Sinix, Вы писали:

S>С вероятностью выше >>0.5 не пройдёт тест в маркете. Даже не ручное тестирование, а WACK tool.

Пройдет.

Я в одном месте UI на несколько секунд завешиваю, чтобы картинку в памяти нарисовать
и еще есть несколько мест, где я делаю примерно вот так:

  someObject.SomeMethodAsync().AsTask().Wait();

Тестирование уже раз 50 проходил, проблем не было.

Здравствуйте, Sinix, Вы писали:

S>Вот тут я не уверен честно говоря

От .net-а там всего ничего, почти всё уходит в нативные вызовы. Как вариант — выложите бинарник, проверю.

Легко: http://files.rsdn.ru/98162/test.exe

S>Кстати, а в запускаюшем коде есть что-то типа Thread.Yield? Без него "рабочие" потоки скорее ждут своей очереди на завершение чем работают. С тасками так счётчик растёт до нескольких миллионов, что конечно же неверно.

Thread.Yield это в реальности функция SwitchToThread из win api. И её добавление/убирание для потоков в данном случае естественно никак не влияет на ситуацию — не стоит путать кооперативную и вытесняющую многозадачность.

S>Это во многом зависит от дизайна языка и фреймворка. Для дотнета замена абсолютно прозрачна. Для скалы/эрланга — незаметна в принципе.

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

Но главный вопрос в другом: а зачем менять код с системных потоков на лёгкие для обычного ПО? Т.е. как у нас это соотносится с принципом Оккама? )

Здравствуйте, alex_public, Вы писали:

НС>>К какой части высказывания вопрос?
_>К первой. )

Это, как бы, наблюдаемый факт. Асинхронный IO меньше жрет батарейку и обеспечивает меньшую латентность на действия пользователя в условиях ограниченной многозадачности всех трех актуальных мобильных ОС.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Это, как бы, наблюдаемый факт. Асинхронный IO меньше жрет батарейку и обеспечивает меньшую латентность на действия пользователя в условиях ограниченной многозадачности всех трех актуальных мобильных ОС.

И где можно ознакомиться с результатами измерений? )

Здравствуйте, alex_public, Вы писали:

_>>>Ну так а зачем запускать тяжёлые операции в UI потоке, а не в отдельном? )
S>>В терминах мобильных приложений к "тяжёлым" относится всё, что может завесить поток больше, чем на 50 миллисекунд. Т.е. любой ввод-вывод как минимум.
_>И как это отвечает на мой вопрос? )
Очень просто. Сама возможность запустить операцию синхронно означает, что её будут использовать в UI-потоках. Просто потому, что оно не тормозит на машине разработчика. Поэтому единственный способ это предупредить — просто лишить программиста возможности запустить потенциально тормозной код синхронно.

_>Похоже что данного преимущества недостаточно для популярности платформы. Кстати, сама винда это показывала в далёком прошлом: более открытая платформа выигрывает, даже если она более глючная.
Дело не в открытости и не в технических возможностях, точнее, не только и не столько в них. Два примера:
* Урезанная донемогу wp куда популярней на мобильном рынке, чем "более открытая" winrt (понятно что сравниваем яблоки с апельсинами, ну да фиг с ним). Хотя с точки зрения обычного пользователя winrt практически не отличается по возможностям от типовых андроид/ios — приложений.
* Свободный от и до линукс на мобильном рынке не заметен в микроскоп, в отличие от "ограниченного" андроида.

S>>Вот тут я не уверен честно говоря

От .net-а там всего ничего, почти всё уходит в нативные вызовы. Как вариант — выложите бинарник, проверю.
_>Легко: http://files.rsdn.ru/98162/test.exe
Вот тут я в непонятках. Хоть убей, у меня выводит что-то типа 5183, т.е. 5k потоков. Win7x64.

Или от системы оно зависит куда сильнее, чем managed/unmanaged, или у нас код различается.

_>Thread.Yield это в реальности функция SwitchToThread из win api. И её добавление/убирание для потоков в данном случае естественно никак не влияет на ситуацию — не стоит путать кооперативную и вытесняющую многозадачность.
Немного влияет, по крайней мере под .net — запускающий (основной) поток периодически перестаёт молотить (а приоритет у него выше) и даёт завершиться ожидающим потокам. Но там разброс получается в 5-10%, т.е. в пределах погрешности. Для тасков разброс заметнее.

S>>Это во многом зависит от дизайна языка и фреймворка. Для дотнета замена абсолютно прозрачна. Для скалы/эрланга — незаметна в принципе.
_>Ну начнём с того, что для обычного десктопного ПО (с 1-10 одновременными задачами) асинхронная работа ещё и менее эффективна, чем синхронная. Правда для такого ПО опять же обычно глубоко наплевать на такие нюансы эффективности.
_>Но главный вопрос в другом: а зачем менять код с системных потоков на лёгкие для обычного ПО? Т.е. как у нас это соотносится с принципом Оккама? )
Для обычного десктопного характерны именно что долгие ожидания с промежуточными всплесками активности. Таски тут как раз идеально подходят, т.к. позволяют распределить нагрузку во время всплеска, не завешивая основной поток. При этом код практически не отличается от обычного синхронного.

Здравствуйте, Sinix, Вы писали:

S>Очень просто. Сама возможность запустить операцию синхронно означает, что её будут использовать в UI-потоках. Просто потому, что оно не тормозит на машине разработчика. Поэтому единственный способ это предупредить — просто лишить программиста возможности запустить потенциально тормозной код синхронно.

Т.е. по сути это не технологическое решение, а политическое — сделать платформу более устойчивой к программированию индусами... Ну в таком смысле может и могу согласиться. Собственно java и .net на этом и специализируются, но то что они win api пробуют повернуть туда же — это уже совсем разумно.

S>Вот тут я в непонятках. Хоть убей, у меня выводит что-то типа 5183, т.е. 5k потоков. Win7x64.

Или от системы оно зависит куда сильнее, чем managed/unmanaged, или у нас код различается.

Ну так .net вариант как я понял вообще вылетал, причём уже на 3К потоках? )

А так, вполне возможно, что создание потока на Win7x64 стоит в пару раз дороже, чем на WinXPx86. Вообще эта тема конечно же заслуживает более детального исследования, но у меня сейчас на это времени особо нет.

S>Немного влияет, по крайней мере под .net — запускающий (основной) поток периодически перестаёт молотить (а приоритет у него выше) и даёт завершиться ожидающим потокам. Но там разброс получается в 5-10%, т.е. в пределах погрешности. Для тасков разброс заметнее.

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

S>Для обычного десктопного характерны именно что долгие ожидания с промежуточными всплесками активности. Таски тут как раз идеально подходят, т.к. позволяют распределить нагрузку во время всплеска, не завешивая основной поток. При этом код практически не отличается от обычного синхронного.

Эммм, вообще то вопрос был немного не про это. Я спрашивал зачем заменять системные потоки лёгкими, а не зачем заменять однопоточный код на лёгкие потоки. ) Понятно что таски лучше линейного кода. Но чем они могут быть лучше своего многопоточного аналога? )

Здравствуйте, alex_public, Вы писали:

_>Эммм, вообще то вопрос был немного не про это. Я спрашивал зачем заменять системные потоки лёгкими, а не зачем заменять однопоточный код на лёгкие потоки. ) Понятно что таски лучше линейного кода. Но чем они могут быть лучше своего многопоточного аналога? )

Тем, что не привязаны к потокам системы. Как результат — можно распределять нагрузку прозрачно для пользовательского кода. Звучит скромно, на практике разница как между циклами и linq: основная часть рутинного кода спрятана под капот и многопоточный/асинхронный код получается очень легко.

Здравствуйте, Sinix, Вы писали:

S>Тем, что не привязаны к потокам системы. Как результат — можно распределять нагрузку прозрачно для пользовательского кода. Звучит скромно, на практике разница как между циклами и linq: основная часть рутинного кода спрятана под капот и многопоточный/асинхронный код получается очень легко.

Что-то сомневаюсь. Вот мы тут рассматривали для теста два примера на C# — они выглядели практически одинаково. И даже у варианта с Task'ми было чуть больше мусора (await'ы и т.п.).

Здравствуйте, alex_public, Вы писали:

_>Что-то сомневаюсь. Вот мы тут рассматривали для теста два примера на C# — они выглядели практически одинаково. И даже у варианта с Task'ми было чуть больше мусора (await'ы и т.п.).

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

Здравствуйте, Sinix, Вы писали:

S>Так в варианте с тасками и работы больше было. Вместо тупого блокирования потока он передавался следующей задаче, таски были настроены так чтобы для продолжения работы использовать первый свободный поток, а не исходный (.ConfigureAwait(false)). Попробуете так же лаконично записать это с "простыми" потоками?

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

Здравствуйте, alex_public, Вы писали:

_>Не понял, что надо записать лаконично простыми потоками? ) У нас есть два примера, реализующих одну и ту же функциональность. При этом вариант с тасками более замусорен.

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

Функциональность разная. Как и нагрузка на комп. У вас Test.exe на ~5000 потоках жрёт 170 мб. Если ограничить вариант на дотнете теми же пятью тысячами задач, получаем ~14мб private bytes.

Здравствуйте, Sinix, Вы писали:

S>Функциональность разная. Как и нагрузка на комп. У вас Test.exe на ~5000 потоках жрёт 170 мб. Если ограничить вариант на дотнете теми же пятью тысячами задач, получаем ~14мб private bytes.

То, что лёгкие потоки однозначно лучше системных в узкой нише "тысяч одновременных задач", мы уже давно выяснили. Вопрос в том, зачем нужны лёгкие потоки в обычных приложениях.

Здравствуйте, alex_public, Вы писали:

_>То, что лёгкие потоки однозначно лучше системных в узкой нише "тысяч одновременных задач", мы уже давно выяснили. Вопрос в том, зачем нужны лёгкие потоки в обычных приложениях.
Затем, что "лёгкие потоки" изначально строятся на continuation passing-модели в отличие от lock-n-wait для "обычных" потоков.

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

Для "классики" приходится или мириться с блокирующими ожиданиями, или переизобретать лёгкие потоки — очередь сообщений, шедулер, приоритеты и т.п.

Здравствуйте, alex_public, Вы писали:

_>То, что лёгкие потоки однозначно лучше системных в узкой нише "тысяч одновременных задач", мы уже давно выяснили

С чего ты взял что в тасках легкие потоки?

Здравствуйте, Sinix, Вы писали:

S>Отличие в том, что continuation passing позволяет писать эффективный асинхронный код даже если он будет работать в одном потоке. Большинство сценариев для десктопов, мобильного и веб-софта превосходно ложатся на "запусти, дай работать другому коду, продолжи по завершении".

То, что это возможно, я понимаю. Но вопрос "а зачем?" остаётся по прежнему... )

S>Для "классики" приходится или мириться с блокирующими ожиданиями, или переизобретать лёгкие потоки — очередь сообщений, шедулер, приоритеты и т.п.

Так а чем плохо то блокирующее ожидание в отдельном потоке?

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>С чего ты взял что в тасках легкие потоки?

Не в них, а они сами являются неким подобием. )

Здравствуйте, alex_public, Вы писали:

_>Не в них, а они сами являются неким подобием. )

Вот именно что неким подобием. Fine grained параллелизм никто 1 в 1 на физические потоки и не кладет, потому что накладные расходы весь выигрышь сожрут. Тем не менее с точки зрения ожидания ввода/вывода и т.п. это самые настоящие потоки.

Здравствуйте, alex_public, Вы писали:

S>>Для "классики" приходится или мириться с блокирующими ожиданиями, или переизобретать лёгкие потоки — очередь сообщений, шедулер, приоритеты и т.п.
_>Так а чем плохо то блокирующее ожидание в отдельном потоке?
1. Впустую тратятся ресурсы. Для десктопа некритично, для мобильного софта — очень важно.
2. Переход от одного потока к другому или освобождение блокировки требует обращения к объектам ядра. Т.е. о "лёгком" переключении и построении цепочек асинхронных действий можно забыть.
3. Слишком легко заблокировать UI-поток из-за вещей, который тяжело ловятся при тестировании. Например, сбойный винт или интернет на соплях — и "быстрый-быстрый" софт превращается в тыкву

Здравствуйте, Sinix, Вы писали:

S>1. Впустую тратятся ресурсы. Для десктопа некритично, для мобильного софта — очень важно.

С чего это впустую тратятся? )

S>2. Переход от одного потока к другому или освобождение блокировки требует обращения к объектам ядра. Т.е. о "лёгком" переключении и построении цепочек асинхронных действий можно забыть.

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

S>3. Слишком легко заблокировать UI-поток из-за вещей, который тяжело ловятся при тестировании. Например, сбойный винт или интернет на соплях — и "быстрый-быстрый" софт превращается в тыкву

В UI потоке и не надо такое вызывать. )

Здравствуйте, alex_public, Вы писали:

S>>1. Впустую тратятся ресурсы. Для десктопа некритично, для мобильного софта — очень важно.
_>С чего это впустую тратятся?)
время на переключение контекстов, память, объекты ядра. Мелочь конечно, но для типовой десктопной нагрузки: 99% спим, 1% изображаем бешеную активность они становятся сопоставимы с собственно полезной деятельностью.

S>>2. Переход от одного потока к другому или освобождение блокировки требует обращения к объектам ядра. Т.е. о "лёгком" переключении и построении цепочек асинхронных действий можно забыть.
_>Вообще то в случае обычных десктопных задач эти потоки будут не переключаться, а нормально исполняться параллельно, каждый на своём ядре процессора... )
Нет. Чисто вычислительных задач в десктопе очень мало, а вот затыков из-за IO, наоборот, много.

S>>3. Слишком легко заблокировать UI-поток из-за вещей, который тяжело ловятся при тестировании. Например, сбойный винт или интернет на соплях — и "быстрый-быстрый" софт превращается в тыкву

_>В UI потоке и не надо такое вызывать.
Осталось объяснить это 95% разработчиков

Здравствуйте, Sinix, Вы писали:

S>время на переключение контекстов, память, объекты ядра. Мелочь конечно, но для типовой десктопной нагрузки: 99% спим, 1% изображаем бешеную активность они становятся сопоставимы с собственно полезной деятельностью.

Это вряд ли. Ну точнее если время исполнения (а не жизни!) потока становится сравнимым со временем его создания (как кстати было в том нашем тестовом примерчике), то тогда действительно потоки становятся весьма не эффективными. Но это явно вырожденный случай.

S>Нет. Чисто вычислительных задач в десктопе очень мало, а вот затыков из-за IO, наоборот, много.

И? ) Это как-то отменяет многоядерность современных процессоров? )

S>Осталось объяснить это 95% разработчиков

Вот, с таким объяснением (индусоориентированность) пользы лёгких потоков в десктопном софте я вполне могу согласиться. )))

Это именно что 99% асинхронных задач в wp/winrt — запулили в фоновый поток, чтобы не морозить UI из-за зависшей сети, оно отработало сразу, продолжаем в UI-потоке.

S>>Нет. Чисто вычислительных задач в десктопе очень мало, а вот затыков из-за IO, наоборот, много.
_>И? ) Это как-то отменяет многоядерность современных процессоров? )
S>>Осталось объяснить это 95% разработчиков

_>Вот, с таким объяснением (индусоориентированность) пользы лёгких потоков в десктопном софте я вполне могу согласиться. )))
Не в большей степени, чем индусоориентированность компиляторов, не дающих запихнуть string в int. По этому критерию самый тру-програмерский язык у нас, выходит, яваскрипт

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

Здравствуйте, Sinix, Вы писали:

S>Да ну?

Это именно что 99% асинхронных задач в wp/winrt — запулили в фоновый поток, чтобы не морозить UI из-за зависшей сети, оно отработало сразу, продолжаем в UI-потоке.

Ну так пришедшие по сети данных в большинстве случаев ещё и обработать надо. Логично это сделать в том же потоке и тогда всё получается вполне эффективно. )

S>Не в большей степени, чем индусоориентированность компиляторов, не дающих запихнуть string в int. По этому критерию самый тру-програмерский язык у нас, выходит, яваскрипт

Использование или неиспользование лёгких потоков — это вопрос скорее не языка, а подключаемых библиотек.

Здравствуйте, alex_public, Вы писали:

_>Ну так пришедшие по сети данных в большинстве случаев ещё и обработать надо. Логично это сделать в том же потоке и тогда всё получается вполне эффективно. )
Угу. Только обработка на современных компах — тоже копейки. Возвращаемся к тому, с чего начали: время исполнения потока становится сравнимым со временем его создания.

_>Использование или неиспользование лёгких потоков — это вопрос скорее не языка, а подключаемых библиотек.
В обоих случаях согласен, но, как показала практика, без поддержки асинхронности языком и без обязательных к использованию библиотек в массе никто асинхронностью не занимается. Просто потому, что правильно написать async-код (с передачей контекста, TLS, исключений и тп) — тот ещё гемморой. А самописные недоделки, особенно если их скрестить с чужим кодом, без всего вышеперечисленного бывает так выстреливают в ногу в продакшне, что лучше бы их и не было

Здравствуйте, Sinix, Вы писали:

N>>Если принять за основу, что нить в Windows очень дорога в держании и переключении, то неудивительно стремление MS к IOCP — выигрыш идёт действительно в разы. В Linux разница значительно меньше.
S>Дело не столько в "дорога в держании и переключении", сколько в накладных расходах на kernel switch и загруженный впустую планировщик. Сравни сам:
[...]
S>Вариант с потоками под x86 затыкается с OutOfMemory уже на ~3000 потоков (несмотря на стек в 100 кб), под x64 — стабилизируется где-то на 30k потоков.
S>Вариант с тасками спокойно пережёвывает 800k одновременно работающих тасков.

Цена переключения нитей меня удивляет. Как оно организовано в Windows?
Насколько я знаю разные Unix, там это очень дёшево — задача та же, проход через TSS не делается, вся цена — перезагрузка регистров (которую процессор может растянуть) и 1-2 конкретных страниц TLS.
Стиль работы планировщика в этом случае не знаю, но в Linux они переключаемые и постоянно обновляются на отработку маргинальных случаев

S>Если перейти на пул потоков с IOCP при должном везении получается нечто среднее.

N>>И в результате 99% индусов будут писать в духе
S>

S>    startOperation();
S>    waitOnEvent(operation_finished);
S>

S>С вероятностью выше >>0.5 не пройдёт тест в маркете. Даже не ручное тестирование, а WACK tool.

Как именно она проверяет такое?

Здравствуйте, netch80, Вы писали:

N>Цена переключения нитей меня удивляет. Как оно организовано в Windows?

Совсем точно я сейчас не напишу — надо открывать WinInternals Руссиновича и перечитывать пару глав, за практической ненадобностью позабыл давно. Принципиально всё везде более-менее одинаково, дьявол в деталях. Детали — всё в том же Руссиновиче, или (тезисно) вот в этой презенташке, с 19 страницы (pdf).

Если ничего не путаю, само переключение контекста по времени сопоставимо что в win, что в lin. В pdf-нике про singularity была вот такая табличка:

На конкретные цифры без уточнения версий win/lin/freebsd ориентироваться смысла нет, но нам важен порядок значений. Переключение контекста на объяснение "почему тормозим" не катит.

Из более-менее объективных причин у нас остаётся стоимость работы шедулера. В десктопной win шедулер заточен под примерно 300..1000 переключений в секунду:

A context switching rate of 300 per second per processor is a moderate amount; a rate of 1000 per second or more is high. Values at this high level may be a problem

Всё, что больше — на ваш страх и риск, как говорится

Если не лень — проверьте под lin, на скольки потоках загнётся?

N>>

    startOperation();
    waitOnEvent(operation_finished);

S>>С вероятностью выше >>0.5 не пройдёт тест в маркете. Даже не ручное тестирование, а WACK tool.
N>Как именно она проверяет такое?

Ну... Евгений Акиньшин выше написал, что на практике оно никак не отслеживается, т.е. тут я точно не прав.

А чтобы обломать — будет достаточно предупреждения при вызове блокирующих методов из ui-потока. Найти их — дело несложное, или правилом в FxCop, или инструментированием и запуском приложения. Т.е. технических причин почему оно так не делается точно нет.

Здравствуйте, alex_public, Вы писали:

S>>Не в большей степени, чем индусоориентированность компиляторов, не дающих запихнуть string в int. По этому критерию самый тру-програмерский язык у нас, выходит, яваскрипт

_>Использование или неиспользование лёгких потоков — это вопрос скорее не языка, а подключаемых библиотек.

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

Потому на игровых серверах WoT или Evo Online используется какой нибудь Stackless Python

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

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

Здравствуйте, Ночной Смотрящий, Вы писали:

_>>То, что лёгкие потоки однозначно лучше системных в узкой нише "тысяч одновременных задач", мы уже давно выяснили

НС>С чего ты взял что в тасках легкие потоки?

Таски и есть легкие потоки. Точнее это реализация легких потоков с помощью библиотеки, костылей в языке и такой то матери.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Вот именно что неким подобием. Fine grained параллелизм никто 1 в 1 на физические потоки и не кладет, потому что накладные расходы весь выигрышь сожрут. Тем не менее с точки зрения ожидания ввода/вывода и т.п. это самые настоящие потоки.

Правильно, в зеленых потоках все точно так же — с т.з. ожидания ввода-вывода это настоящие потоки.

Здравствуйте, Ikemefula, Вы писали:

I>Таски и есть легкие потоки.

Нет.

Здравствуйте, Ночной Смотрящий, Вы писали:

I>>Таски и есть легкие потоки.

НС>Нет.

И в чем отличие ?

Здравствуйте, Ikemefula, Вы писали:

I>И в чем отличие ?

In computer programming, green threads are threads that are scheduled by a virtual machine (VM) instead of natively by the underlying operating system. Green threads emulate multithreaded environments without relying on any native OS capabilities, and they are managed in user space instead of kernel space, enabling them to work in environments that do not have native thread support.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Здравствуйте, Ikemefula, Вы писали:

I>>И в чем отличие ?

НС>

НС>In computer programming, green threads are threads that are scheduled by a virtual machine (VM) instead of natively by the underlying operating system. Green threads emulate multithreaded environments without relying on any native OS capabilities, and they are managed in user space instead of kernel space, enabling them to work in environments that do not have native thread support.

Если смотреть первое выделение, то окажется, что зеленые потоки вообще никакие не зеленые, а то в реализациях то тут, то там могут использовать возможности OS.
Если второе, то таски из дотнета можно прикрутить к рантайме без нативной поддержки тредов.

Здравствуйте, alex_public, Вы писали:

_>В UI потоке и не надо такое вызывать. )

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

Здравствуйте, alex_public, Вы писали:

S>>время на переключение контекстов, память, объекты ядра. Мелочь конечно, но для типовой десктопной нагрузки: 99% спим, 1% изображаем бешеную активность они становятся сопоставимы с собственно полезной деятельностью.

_>Это вряд ли. Ну точнее если время исполнения (а не жизни!) потока становится сравнимым со временем его создания (как кстати было в том нашем тестовом примерчике), то тогда действительно потоки становятся весьма не эффективными. Но это явно вырожденный случай.

Это обычный случай в десктопе и мобайле. 90-99% времени это idle.

S>>Нет. Чисто вычислительных задач в десктопе очень мало, а вот затыков из-за IO, наоборот, много.

_>И? ) Это как-то отменяет многоядерность современных процессоров? )

S>>Осталось объяснить это 95% разработчиков

_>Вот, с таким объяснением (индусоориентированность) пользы лёгких потоков в десктопном софте я вполне могу согласиться. )))

Ну да, всё просто — все дураки, один ты д'Артаньян. Вероятно оттого, что ни десктопом, ни мобайлом не занимался.

Здравствуйте, IT, Вы писали:

IT>Здравствуйте, Aлeкceй, Вы писали:

IT>Забыл добавить.

IT>Если бы MS выпустил .NET под Линукс, то дни Java ну не то чтобы были сочтены, но мы бы её оттуда очень сильно подвинули, т.к. желающих очень много. А когда .NET обосновался бы на серверах, то можно было бы ставить вопрос о нужности Линукса на сервере и доказывать, что его обслуживание вовсе не дешевле Windows, а гемора при разработке больше. Т.е. .NET вполне мог бы оказаться тем поршнем, который помог бы выдавать Линукс с серверной части. А пока получается, что на серверах, за исключением веба, MS представлена очень слабо.

Ваш голос был услышан

Oh, and by the way<br />
<br />
ASP.NET vNext (and Rosyln) runs on Mono, on both Mac and Linux today. While Mono isn't a project from Microsoft, we'll collaborate with the Mono team, plus Mono will be added to our test matrix. It's our aspiration that it "just work."

Здравствуйте, Ikemefula, Вы писали:

I>>>Таски и есть легкие потоки.
НС>>Нет.
I>И в чем отличие ?

Сорри, что влажу, но таски — это не потоки, это абстракция уровнем выше. За Task может скрываться классический поток, шедулер TPL, шедулер ms sql, iocp-порт или вообще балансер для кластера, как в orleans.

Ближайшая аналогия для Task — запущенная операция. Она может завершиться, быть отменена, упасть с ошибкой, продолжена произвольным кодом после своего завершения и тд и тп. На поток это мало похоже

Здравствуйте, G2, Вы писали:

G2>Ваш голос был услышан

Ну хотя бы так

Уже можно говорить, что Моно это не просто там какие-то пацаны на коленке написали, а работа идёт с поддержкой Майкрософт.

Здравствуйте, Ikemefula, Вы писали:

I>Если второе, то таски из дотнета можно прикрутить к рантайме без нативной поддержки тредов.

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

Здравствуйте, Ночной Смотрящий, Вы писали:

I>>Если второе, то таски из дотнета можно прикрутить к рантайме без нативной поддержки тредов.

НС>Ага, если обеспечить отдельную поддержку зеленых потоков.

Это можно сделать прямо в прикладном коде.

Здравствуйте, Ikemefula, Вы писали:

I>Это можно сделать прямо в прикладном коде.

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

Здравствуйте, Ночной Смотрящий, Вы писали:

I>>Если второе, то таски из дотнета можно прикрутить к рантайме без нативной поддержки тредов.

НС>Ага, если обеспечить отдельную поддержку зеленых потоков.

А зачем они нужны в наше время?

Здравствуйте, Sinix, Вы писали:

S>Если не лень — проверьте под lin, на скольки потоках загнётся?
Если 5000 не убирать, то всё доходит до порядка 20000 потоков. Потом выполняются decrement'ы и оно снова начинается.

Если поставить sleep(50000), то у меня дошло до 30000, потом начало свопиться (на виртуалке около 4Гб). Нативная версия дошла до 32700.

#include <unistd.h>
#include <stdio.h>
#include <vector>
#include <boost/thread.hpp>
using namespace std;

int main()
{
    std::vector<boost::thread> all;
    for(int n = 0; n <1000000; ++n)
    {
        boost::thread::attributes attrs;
        attrs.set_stack_size(8192);

        boost::thread th(attrs, []() {sleep(50000);});
        all.push_back(std::move(th));
        if (n % 100 == 0)
            printf("%d\n", n);
    }
};

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Вот видишь, ты сам все понимаешь. А еще реальные сервера могут скрываться за каким нибудь сервисом типа акамая. А еще 100500 сайтиков на ПХП, крутящихся на одном сервере, статистику в сайтах тоже соответственную делают.

Работаю в конторе, которая занимается ПО для сайтиков.
Тесно сотрудничаем с МС. Процент реальных сайтов на винде не превышает 10%.
Могу поделится такой инфой — МС приплачивает крупным хостерам, чтобы парковали домены на винде.

Отсюда рост количества сайтов на винде у всяких netcraft. На самом деле тенденция совсем иная — винда упорно теряет свои позиции...

Вообще-то Tasks и обеспечивают абстрацию как в отношении процессора, так и ОСи. И они входят во многие portable subset. Это позволяет выполнять их независимо от того, как они реализованы на desktop или мобильном устройстве. Но когда внутренняя реализация критична, можно использовать платформенно-зависимые потоки, в этом случае они будут разными для разных ОСей.

Здравствуйте, Ilya81, Вы писали:

I>Вообще-то Tasks и обеспечивают абстрацию как в отношении процессора, так и ОСи. И они входят во многие portable subset. Это позволяет выполнять их независимо от того, как они реализованы на desktop или мобильном устройстве. Но когда внутренняя реализация критична, можно использовать платформенно-зависимые потоки, в этом случае они будут разными для разных ОСей.

См пост выше:

таски — это не потоки, это абстракция уровнем выше. За Task может скрываться классический поток, шедулер TPL, шедулер ms sql, iocp-порт или вообще балансер для кластера, как в orleans.

Вы точно мне отвечали?

Здравствуйте, Nikе, Вы писали:

НС>>Ага, если обеспечить отдельную поддержку зеленых потоков.

N>А зачем они нужны в наше время?

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

Потому серверы WoT или Eve Online написаны на пейтоне или стеклесс пейтоне, шоб сильнее было. Зеленая нитка на тормозном пейтоне переключается на другую быстрее чем мега-нативный высокосиплюсный код с потока на поток.

Здравствуйте, Ikemefula, Вы писали:

I>Как и раньше — ресурсы экономить. Для задач, где мало вычислений и много работы с сетью, IO и тд, незачем плодить нативные потоки.

С такими задачами прекрасно справляются и IOCP.

Здравствуйте, Ночной Смотрящий, Вы писали:

I>>Как и раньше — ресурсы экономить. Для задач, где мало вычислений и много работы с сетью, IO и тд, незачем плодить нативные потоки.

НС>С такими задачами прекрасно справляются и IOCP.

В своём уме IOCP руками никто не прогает, только пару маньяков, навроде тех что пишут nginx и подобные вещи. Зеленые потоки искаропки хорошо поддерживают асинхронную работу с IO.

Здравствуйте, Ikemefula, Вы писали:

I>В своём уме IOCP руками никто не прогает

Что значит руками? Таски поверх IOCP это все еще руками или уже нет? А FileStream.BeginRead?

I>Зеленые потоки искаропки хорошо поддерживают асинхронную работу с IO.

Для использования IOCP зеленые потоки не нужны.

Здравствуйте, Ночной Смотрящий, Вы писали:

I>>В своём уме IOCP руками никто не прогает

НС>Что значит руками? Таски поверх IOCP это все еще руками или уже нет? А FileStream.BeginRead?

Таски используют iocp так же как и зеленые потоки, ничуть не лучше и не хуже. А вот извраты FileStream.BeginRead в своём уме никто не использует, кроме как для мелочевки, которую без разницы на чем писать.

I>>Зеленые потоки искаропки хорошо поддерживают асинхронную работу с IO.

НС>Для использования IOCP зеленые потоки не нужны.

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

Без зеленых потоков получится моделька навроде той что в nginx. Разработчиков такого уровня в каждом регионе по пару штук.

Здравствуйте, Ikemefula, Вы писали:

I>Таски используют iocp

Сами таски не используют, используют их конкретные IO bound методы.

I>А вот извраты FileStream.BeginRead в своём уме никто не использует

А что там такого извратного?

НС>>Для использования IOCP зеленые потоки не нужны.
I>Не нужны это значит, что зеленые потоки для IOCP не являются обязательными

Нет, это значит что не нужны. Совсем.

I>Без зеленых потоков получится моделька навроде той что в nginx.

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

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Сами таски не используют, используют их конкретные IO bound методы.

I>>А вот извраты FileStream.BeginRead в своём уме никто не использует

НС>А что там такого извратного?

В кратце — асинхронная цепочка в таком вот стиле это АДЪ. попробуй написать скажем сумму последовательности, если у тебя одна переменная и методы навроде BeginRead, BeginWrite и тд.
Внезапно, даже в однопоточной модели возникают гонки в силу кооперативной многозадачности. В зеленых потоках эту проблему проще контролировать.

I>>Не нужны это значит, что зеленые потоки для IOCP не являются обязательными

НС>Нет, это значит что не нужны. Совсем.

Я боюсь даже спрашивать, как ты понимаешь слово "нужен". Вот С# не нужен, потому что есть N других языков программирования. Прикинь ?

I>>Без зеленых потоков получится моделька навроде той что в nginx.

НС>Моделька получится та, которая нужна. Например таски, которые работают с IOCP без всяких зеленых потоков.

Таски работают с IOCP ровно так же, как и зелёные потоки, один к одному, только зеленые потоки обычно проще тасков, там не надо поддержвать сто тыщ пиццот разных контекстов и потоковых моделей.

Есть разве что такое отличие — Микрософт всунула в таски все что только смогла придумать. Похоже, когда вижла без единого плагина виснет на часы при обращении к TFS, тамошние таски усилено чтото делают. Вероятно, разработчики в МС сами не понимают, как работают таски. А когда вижла зависает и сообщает что чем то занята, пудозреваю, это те же таски.

Здравствуйте, Ikemefula, Вы писали:

I>В кратце — асинхронная цепочка в таком вот стиле это АДЪ. попробуй написать скажем сумму последовательности

Сумма последовательности это CPU bound задача, при чем тут IOCP?

I>>>Не нужны это значит, что зеленые потоки для IOCP не являются обязательными
НС>>Нет, это значит что не нужны. Совсем.
I>Я боюсь даже спрашивать, как ты понимаешь слово "нужен".

То и понимаю. Зеленые потоки IOCP совершенно ортогональны.

НС>>Моделька получится та, которая нужна. Например таски, которые работают с IOCP без всяких зеленых потоков.
I>Таски работают с IOCP ровно так же, как и зелёные потоки, один к одному

Ага, а еще они работают с IOCP так же, как куча другого кода. Просто по тому что есть один единственный способ с ними работать

Здравствуйте, Ikemefula, Вы писали:

I>>А вот извраты FileStream.BeginRead в своём уме никто не использует
I>В кратце — асинхронная цепочка в таком вот стиле это АДЪ. попробуй написать скажем сумму последовательности, если у тебя одна переменная и методы навроде BeginRead, BeginWrite и тд.
I>Внезапно, даже в однопоточной модели возникают гонки в силу кооперативной многозадачности. В зеленых потоках эту проблему проще контролировать.

Есть такое подозрение, что таски ты вообще не использовал

TaskFactory.FromAsync(), дальше всё то же, что и с любыми другими тасками.

I>Таски работают с IOCP ровно так же, как и зелёные потоки, один к одному, только зеленые потоки обычно проще тасков, там не надо поддержвать сто тыщ пиццот разных контекстов и потоковых моделей.
I>Есть разве что такое отличие — Микрософт всунула в таски все что только смогла придумать. Похоже, когда вижла без единого плагина виснет на часы при обращении к TFS, тамошние таски усилено чтото делают. Вероятно, разработчики в МС сами не понимают, как работают таски. А когда вижла зависает и сообщает что чем то занята, пудозреваю, это те же таски.

А вот теперь — не подозрение, а твёрдая уверенность

Я бы всё-таки подучил матчасть перед спором. Потому что буквально все утверждения выше: "ExecutionContext не нужен", "таски нельзя отладить", "таски === 100500 потоковых моделей" и т.д. к реальности никак не относятся.

Здравствуйте, Ночной Смотрящий, Вы писали:

I>>В кратце — асинхронная цепочка в таком вот стиле это АДЪ. попробуй написать скажем сумму последовательности

НС>Сумма последовательности это CPU bound задача, при чем тут IOCP?

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

НС>Ага, а еще они работают с IOCP так же, как куча другого кода. Просто по тому что есть один единственный способ с ними работать

И внезапно оказывается, что в зеленых потоках код получается наиболее простым из всех вариантов реализации. Более того, он вообще мало отличим от синхронного.

Здравствуйте, Ikemefula, Вы писали:

I>Для демонстрации особенностей кооперативной многозадачности.

IOCP и BeginRead это не кооперативная многозадачность.

I>И внезапно оказывается, что в зеленых потоках код получается наиболее простым

Нет, не оказывается.

I> из всех вариантов реализации. Более того, он вообще мало отличим от синхронного.

Ты путаешь зеленые потоки и встраивание continuation monad в компиляторы.

Здравствуйте, Sinix, Вы писали:

S>Есть такое подозрение, что таски ты вообще не использовал

S>TaskFactory.FromAsync(), дальше всё то же, что и с любыми другими тасками.

Тебе нужно всего ничего — доказать, что в кооперативной многозадачности гонки невозможны.

I>>Таски работают с IOCP ровно так же, как и зелёные потоки, один к одному, только зеленые потоки обычно проще тасков, там не надо поддержвать сто тыщ пиццот разных контекстов и потоковых моделей.
I>>Есть разве что такое отличие — Микрософт всунула в таски все что только смогла придумать. Похоже, когда вижла без единого плагина виснет на часы при обращении к TFS, тамошние таски усилено чтото делают. Вероятно, разработчики в МС сами не понимают, как работают таски. А когда вижла зависает и сообщает что чем то занята, пудозреваю, это те же таски.

S>А вот теперь — не подозрение, а твёрдая уверенность

Я правильно понимаю, проблемы с тасками у их создателя показывают что проблемы с тасками у меня ? Браво !

S>Я бы всё-таки подучил матчасть перед спором. Потому что буквально все утверждения выше: "ExecutionContext не нужен", "таски нельзя отладить", "таски === 100500 потоковых моделей" и т.д. к реальности никак не относятся.

Ты немного додумал за меня, процентов на 90. Вместо "ExecutionContext не нужен" было " не надо поддержвать сто тыщ пиццот разных контекстов и потоковых моделей"

Таски нельзя отладить — речь была про APM-модель. Будет гаранировано АДЪ. Собственно, с тасками у микрософта пока что не сильно лучше.

Я показал задачу — один поток, один ресурс, несколько асинхронных читателей-писателей сделаных чз BeginXXX и EndXXX и задача, можно самую примитивную — сумму элементов какой нибудь последовательсности.

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

P.S. задача и её решение есть в этом форуме, на джаваскрипте. Поиск не работает, так что помочь не могу.

Здравствуйте, Ikemefula, Вы писали:

S>>TaskFactory.FromAsync(), дальше всё то же, что и с любыми другими тасками.
I>Тебе нужно всего ничего — доказать, что в кооперативной многозадачности гонки невозможны.
Внезапно...

Напомню контекст, твой прошлый пост:

А вот извраты FileStream.BeginRead в своём уме никто не использует
В кратце — асинхронная цепочка в таком вот стиле это АДЪ. попробуй написать скажем сумму последовательности, если у тебя одна переменная и методы навроде BeginRead, BeginWrite и тд.
Внезапно, даже в однопоточной модели возникают гонки в силу кооперативной многозадачности. В зеленых потоках эту проблему проще контролировать.

Можешь объяснить, при чём тут вообще кооперативная многозадачность и какой магией зелёные потоки будут отличаться от тасков?

S>>А вот теперь — не подозрение, а твёрдая уверенность

I>Я правильно понимаю, проблемы с тасками у их создателя показывают что проблемы с тасками у меня ? Браво !

Нет, пойнт в другом: ты вбрасывашь цепочку вообще никак не связанных утверждений аля

Микрософт всунула в таски все что только смогла придумать
разработчики в МС сами не понимают, как работают таски
когда вижла зависает и сообщает что чем то занята, пудозреваю, это те же таски

причём все, такое впечатление, только что из пальца высосан. И делаешь вывод: у тасков есть проблемы.

Сорри, но ни один человек, понимающий, как устроены таски, что с их помощью можно делать, что нельзя, такой бред не напишет. И тем более не будет доказывать сначала, что таски — это зелёные потоки, затем, парой постов ниже — что таски используют iocp так же как и зеленые потоки и сразу же, что таски неудобны, а в зелёных потоках всё ок.
Какому из твоих утверждений верить?

I>Ты немного додумал за меня, процентов на 90. Вместо "ExecutionContext не нужен" было " не надо поддержвать сто тыщ пиццот разных контекстов и потоковых моделей"
В тасках ровно одна модель. За неё прячется практически что угодно — от обычных потоков до акторов и динамического раскидывания вызовов по кластеру. Только не надо начинать за "это всё не нужно"

I>Таски нельзя отладить — речь была про APM-модель. Будет гаранировано АДЪ. Собственно, с тасками у микрософта пока что не сильно лучше.
Ты 100% не использовал Parallel Stacks Window. Т.е. с тасками по сути не работал, о чём и было сказано выше. Про отладку в VS 1013 с поддержкой awiat и прочих плюшек даже начинать не буду.

I>Я показал задачу — один поток, один ресурс, несколько асинхронных читателей-писателей сделаных чз BeginXXX и EndXXX и задача, можно самую примитивную — сумму элементов какой нибудь последовательсности.

Observable.FromAsync(...).Sum();

или

var t = await source.Select(s=>Task.FromAsync(s.BeginXXX, ...)).WhenAll()
t.Sum(t=>t.Result);

+ возможно plinq (c ходу не вспомню, можно ли там прикрутить APM).

I>P.S. задача и её решение есть в этом форуме, на джаваскрипте. Поиск не работает, так что помочь не могу.
Что, проще вышеперечисленного?

Здравствуйте, Ночной Смотрящий, Вы писали:

I>>Для демонстрации особенностей кооперативной многозадачности.

НС>IOCP и BeginRead это не кооперативная многозадачность.

Спасибо, капитан. Зато асинхронщина в одном потоке, которая возникает из за IOCP и BeginRead, аккурат кооперативная многозадачность и есть.

I>>И внезапно оказывается, что в зеленых потоках код получается наиболее простым

НС>Нет, не оказывается.

Мой вариант задачи и её решения есть в этом форуме, а твоего нет и скорее всего никогда не будет. Так шта...

I>> из всех вариантов реализации. Более того, он вообще мало отличим от синхронного.

НС>Ты путаешь зеленые потоки и встраивание continuation monad в компиляторы.

А где я говорил про монады и компиляторы ?

Здравствуйте, Ikemefula, Вы писали:

НС>>IOCP и BeginRead это не кооперативная многозадачность.
I>Спасибо, капитан. Зато асинхронщина в одном потоке

"У рыб нет меха, поэтому блох у нее нет. А вот если бы мех был ...".

I>, которая возникает из за IOCP и BeginRead, аккурат кооперативная многозадачность и есть.

Не знаю что у тебя там возникает, но таски прекрасно справляются без кооперативной многозадачности.

I>>>И внезапно оказывается, что в зеленых потоках код получается наиболее простым
НС>>Нет, не оказывается.
I>Мой вариант задачи и её решения есть в этом форуме, а твоего нет и скорее всего никогда не будет. Так шта...

Ссылки давай, я за тобой не слежу что и где ты писал.

Здравствуйте, Sinix, Вы писали:

S>Напомню контекст, твой прошлый пост:
S>

S>А вот извраты FileStream.BeginRead в своём уме никто не использует
S>В кратце — асинхронная цепочка в таком вот стиле это АДЪ. попробуй написать скажем сумму последовательности, если у тебя одна переменная и методы навроде BeginRead, BeginWrite и тд.
S>Внезапно, даже в однопоточной модели возникают гонки в силу кооперативной многозадачности. В зеленых потоках эту проблему проще контролировать.

S>Можешь объяснить, при чём тут вообще кооперативная многозадачность и какой магией зелёные потоки будут отличаться от тасков?

Если в одном потоке всякие IOCP, BeginXXX, EndXXX, то асинхронщина здесь и есть та самая кооперативная многозадачность.

S>Нет, пойнт в другом: ты вбрасывашь цепочку вообще никак не связанных утверждений аля
S>

S>Микрософт всунула в таски все что только смогла придумать
S>разработчики в МС сами не понимают, как работают таски
S>когда вижла зависает и сообщает что чем то занята, пудозреваю, это те же таски

Связь вполне простая — всунули столько, что сами не смогли это осмыслить, пример — вижла.

S>Сорри, но ни один человек, понимающий, как устроены таски, что с их помощью можно делать, что нельзя, такой бред не напишет. И тем более не будет доказывать сначала, что таски — это зелёные потоки, затем, парой постов ниже — что таски используют iocp так же как и зеленые потоки и сразу же, что таски неудобны, а в зелёных потоках всё ок.
S>Какому из твоих утверждений верить?

Таски это плохая реализация зеленых потоков. Все смешали в кучу — и асинхронщину, и контексты и потоки, все до чего смогли дотянуться.

I>>Ты немного додумал за меня, процентов на 90. Вместо "ExecutionContext не нужен" было " не надо поддержвать сто тыщ пиццот разных контекстов и потоковых моделей"
S>В тасках ровно одна модель. За неё прячется практически что угодно — от обычных потоков до акторов и динамического раскидывания вызовов по кластеру. Только не надо начинать за "это всё не нужно"

Там много больше, чем одна модель. Из того, что все все перечисленное по отдельности нужно, вовсе не значит, что мешанина из всего этого и есть то самое наилучшее решение.

I>>Таски нельзя отладить — речь была про APM-модель. Будет гаранировано АДЪ. Собственно, с тасками у микрософта пока что не сильно лучше.
S>Ты 100% не использовал Parallel Stacks Window. Т.е. с тасками по сути не работал, о чём и было сказано выше. Про отладку в VS 1013 с поддержкой awiat и прочих плюшек даже начинать не буду.

Я await сам написал, когда этого в языке еще не было. Так шта..

I>>Я показал задачу — один поток, один ресурс, несколько асинхронных читателей-писателей сделаных чз BeginXXX и EndXXX и задача, можно самую примитивную — сумму элементов какой нибудь последовательсности.
S>

S>

S>+ возможно plinq (c ходу не вспомню, можно ли там прикрутить APM).

Итого — кода у тебя нет. До свидания.

I>>P.S. задача и её решение есть в этом форуме, на джаваскрипте. Поиск не работает, так что помочь не могу.
S>Что, проще вышеперечисленного?

Разумеется. Обычный код который выглядит как синхронный. В ём даже await не будет.

Здравствуйте, Ночной Смотрящий, Вы писали:

I>>, которая возникает из за IOCP и BeginRead, аккурат кооперативная многозадачность и есть.

НС>Не знаю что у тебя там возникает, но таски прекрасно справляются без кооперативной многозадачности.

Не могут они без этого справляться. Таски унутре continuation-based, то есть, практически кооперативная многозадачность.

I>>Мой вариант задачи и её решения есть в этом форуме, а твоего нет и скорее всего никогда не будет. Так шта...

НС>Ссылки давай, я за тобой не слежу что и где ты писал.

Можно даже проще

var i = 0;

function read() { return i; }

function write(v) { i = v; }


write(++read()); // ничего военного, простой синхронный код

Теперь представь,

1 что i это разделяемый ресурс, а read и write сделаны в духе APM, т.е. Begin-End
2 есть N читателей и писателей и все жаждут сделать одновременно
3 все это разумеется в одном физическом потоке.

скажем, если сделать это в лоб, и таких операций будет 100, то в синхронном варианте результат будет 100, а в асинхронном это будет какое то число, в зависимости от того, какие задержки между begin-end-read-write.

Вот эту проблему нужно решать всегда, когда ты пишешь в APM стиле чтото более сложное чем hello world. Более того, в тасках она растёт в полный рост и решать её нужно руками, но попроще чем в APM. В Зеленых потоках её тоже надо решать, при чем еще проще, чем в тасках.

Здравствуйте, Ikemefula, Вы писали:

S>>Можешь объяснить, при чём тут вообще кооперативная многозадачность и какой магией зелёные потоки будут отличаться от тасков?
I>Если в одном потоке всякие IOCP, BeginXXX, EndXXX, то асинхронщина здесь и есть та самая кооперативная многозадачность.
Нет. Хотя бы потому, что IOCP и "в одном потоке" не соотносятся вообще никак, почитай как оно работают. Запрос инициируется с рабочего потока, запихивается в очередь iocp, по завершению — продолжает выполнение в потоке из IOCP-пула. Кооперативной многозадачности тут нет: обработчики iocp будут выполняться параллельно вплоть до исчерпания пула потоков.

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

S>>Нет, пойнт в другом: ты вбрасывашь цепочку вообще никак не связанных утверждений аля

Микрософт всунула в таски все что только смогла придумать
разработчики в МС сами не понимают, как работают таски
когда вижла зависает и сообщает что чем то занята, пудозреваю, это те же таски

I>Связь вполне простая — всунули столько, что сами не смогли это осмыслить, пример — вижла.
Эмм... а мсье смотрел отладчиком, где и как используются таски в VS? А то за уверенность — 5, за знания — 0 получается

Если коротко, таски в VS на сегодня не используются практически нигде, там где используются — совмещены с await и не блокируют UI-поток студии.

S>>Какому из твоих утверждений верить?
I>Таски это плохая реализация зеленых потоков. Все смешали в кучу — и асинхронщину, и контексты и потоки, все до чего смогли дотянуться.
Мы по кругу ходим. Таски — это _не_ зелёные потоки. Это реализация вообще другой модели, эдакая смесь futures + continuation-passing.

S>>В тасках ровно одна модель. За неё прячется практически что угодно — от обычных потоков до акторов и динамического раскидывания вызовов по кластеру. Только не надо начинать за "это всё не нужно"

I>Там много больше, чем одна модель. Из того, что все все перечисленное по отдельности нужно, вовсе не значит, что мешанина из всего этого и есть то самое наилучшее решение.
Блин, этот спор мне чем-то напоминает "linq зло, т.к. в словарях и базах данных операции почти не перекрываются": такой же сфероконизм без аргументации. Если коротко — таски покрывают типовые задачи почти для всей асинхронщины так же, как linq — операции по фильтрации/проекции данных.

И да, таски не отменяют прочих API, не запрещают специфичных расширений и не всегда идеально смешиваются. Точно так же, как linq. Что, выбрасываем?

I>>>Таски нельзя отладить — речь была про APM-модель. Будет гаранировано АДЪ. Собственно, с тасками у микрософта пока что не сильно лучше.
S>>Ты 100% не использовал Parallel Stacks Window. Т.е. с тасками по сути не работал, о чём и было сказано выше. Про отладку в VS 1013 с поддержкой awiat и прочих плюшек даже начинать не буду.

I>Я await сам написал, когда этого в языке еще не было. Так шта..
Сорри, но не катит. "Использовал A" и "Разработал B и назвал его A" — не одно и то же. Возвращаюсь к вопросу: так какой там "гарантированный АДЪ" с отладкой тасков?

I>Итого — кода у тебя нет. До свидания.
Троллинг тоже не катит. "Поскипал код в ответе" и "кода у тебя нет" — тоже разные вещи.

Здравствуйте, Ikemefula, Вы писали:

НС>>In computer programming, green threads are threads that are scheduled by a virtual machine (VM) instead of natively by the underlying operating system. Green threads emulate multithreaded environments without relying on any native OS capabilities, and they are managed in user space instead of kernel space, enabling them to work in environments that do not have native thread support.

I>Если смотреть первое выделение, то окажется, что зеленые потоки вообще никакие не зеленые, а то в реализациях то тут, то там могут использовать возможности OS.
I>Если второе, то таски из дотнета можно прикрутить к рантайме без нативной поддержки тредов.

Определение не идеальное, но вполне понятное. "Native OS capabilities" имеются в виду не вообще, а именно на поддержку нескольких нитей.
Например, одна из классических реализаций — libc_r во FreeBSD — работала так:

все системные вызовы, которые могут блокироваться, заменяются на врапперы, которые переводят соответствующую активность на ожидание в select()

по таймерному сигналу планировщик может переключить нить, системно- и платформенно-зависимыми средствами сохранив и восстановив полный контекст (регистры процессора)

опять же системно-зависимыми средствами строятся стеки нитей (через mmap() с MAP_STACK)

Реализация была не идеальная — некоторые блокировки не ловились, не было вкусняшек типа per-thread page fault, где-то вместо select() приходилось поллить, non-blocking на fd мог мешать соседям... но несмотря на это получалась вполне себе многонитевая обстановка без явной поддержки в программе.

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

Здравствуйте, Sinix, Вы писали:

S>Нет. Хотя бы потому, что IOCP и "в одном потоке" не соотносятся вообще никак, почитай как оно работают. Запрос инициируется с рабочего потока, запихивается в очередь iocp, по завершению — продолжает выполнение в потоке из IOCP-пула. Кооперативной многозадачности тут нет: обработчики iocp будут выполняться параллельно вплоть до исчерпания пула потоков.

Это просто конкретная реализация. node.js построен унутре на IOCP модели, и нет никакого "продолжает выполнение в потоке из IOCP-пула", там всего один поток, другого в принципе быть не может.

S>Это всё упрощённо и очень схематично конечно, реализации могут быть разные. Но варианта "асинхронщина здесь и есть та самая кооперативная многозадачность" точно не будет. За бесполезностью

Ога, после твоих слов node.js перестал существовать, да еще и задним числом.

I>>Связь вполне простая — всунули столько, что сами не смогли это осмыслить, пример — вижла.
S>Эмм... а мсье смотрел отладчиком, где и как используются таски в VS? А то за уверенность — 5, за знания — 0 получается

Если коротко, таски в VS на сегодня не используются практически нигде, там где используются — совмещены с await и не блокируют UI-поток студии.

Ты определись, используются или нет. Не важно, где и с чем совмещены. Кроме того, я не говорил, что они блокирую UI, я говорил что вижла висит. UI, буквально, живой, но от него толку нет.
Вобщем, прекращай за меня додумывать.

I>>Таски это плохая реализация зеленых потоков. Все смешали в кучу — и асинхронщину, и контексты и потоки, все до чего смогли дотянуться.
S>Мы по кругу ходим. Таски — это _не_ зелёные потоки. Это реализация вообще другой модели, эдакая смесь futures + continuation-passing.

А что по твоему унутре зеленых потоков, чудеса и магия ? Там все те же самые continuation, отсюда возможность переключать выполнение ниток руками. При желании колбеки можно упаковать во что угодно, хоть в futures, хоть в stackless короутины. См пейтон.

I>>Там много больше, чем одна модель. Из того, что все все перечисленное по отдельности нужно, вовсе не значит, что мешанина из всего этого и есть то самое наилучшее решение.
S>Блин, этот спор мне чем-то напоминает "linq зло, т.к. в словарях и базах данных операции почти не перекрываются": такой же сфероконизм без аргументации. Если коротко — таски покрывают типовые задачи почти для всей асинхронщины так же, как linq — операции по фильтрации/проекции данных.

Таски при необходимости одной лишь асинхронщины это какая то катастрофа. Более громоздкого решения сложно даже придумать.

S>И да, таски не отменяют прочих API, не запрещают специфичных расширений и не всегда идеально смешиваются. Точно так же, как linq. Что, выбрасываем?

Таски это прежде всего переусложненный всеобъемлющий всемогутор. Их имеет смысл использовать только когда нужно всё и сразу. Хуже всего, что язык прибили гвоздями к либе.

Если бы в С# был экспрешном и работал как yield в Питоне, для той же асинхронщины можно сделать более простое и эффективное решение, где не надо ломать часами голову, исправляя чей то дедлок.

I>>Я await сам написал, когда этого в языке еще не было. Так шта..
S>Сорри, но не катит. "Использовал A" и "Разработал B и назвал его A" — не одно и то же. Возвращаюсь к вопросу: так какой там "гарантированный АДЪ" с отладкой тасков?

Реши задачу, поговорим.

I>>Итого — кода у тебя нет. До свидания.
S>Троллинг тоже не катит. "Поскипал код в ответе" и "кода у тебя нет" — тоже разные вещи.

Это не троллинг, это факт. Реши задачу и я покажу тебе все что ты хочешь прямо в твоем коде.

Здравствуйте, Ikemefula, Вы писали:

S>>Нет. Хотя бы потому, что IOCP и "в одном потоке" не соотносятся вообще никак, почитай как оно работают. Запрос инициируется с рабочего потока, запихивается в очередь iocp, по завершению — продолжает выполнение в потоке из IOCP-пула. Кооперативной многозадачности тут нет: обработчики iocp будут выполняться параллельно вплоть до исчерпания пула потоков.
I>Это просто конкретная реализация. node.js построен унутре на IOCP модели, и нет никакого "продолжает выполнение в потоке из IOCP-пула", там всего один поток, другого в принципе быть не может.
Эхх...
1. Вообще-то Node.js не однопоточен, он только притворяется. Это к слову о "ExecutionContext не нужен", если что

2. Называть недостаток js преимуществом... ну, не знаю

I>Кроме того, я не говорил, что они блокирую UI, я говорил что вижла висит. UI, буквально, живой, но от него толку нет.
?

А когда вижла зависает и сообщает что чем то занята, пудозреваю, это те же таски.

Но ок, спорить не буду за очевидной бессмысленностью — придётся сначала выяснять, с чего ты решил что проблема вообще в тасках, а затем мы съедем ещё на какую-нибудь тему. Нафиг-нафиг

I>>>Таски это плохая реализация зеленых потоков.
S>>Мы по кругу ходим. Таски — это _не_ зелёные потоки. Это реализация вообще другой модели, эдакая смесь futures + continuation-passing.
I>А что по твоему унутре зеленых потоков, чудеса и магия ? Там все те же самые continuation, отсюда возможность переключать выполнение ниток руками. При желании колбеки можно упаковать во что угодно, хоть в futures, хоть в stackless короутины. См пейтон.
1. Велосипед содержит резину и шестерёнки.
2. Камаз содержит резину и шестерёнки.
3. Будем доказывать тождество?

S>>Блин, этот спор мне чем-то напоминает "linq зло, т.к. в словарях и базах данных операции почти не перекрываются": такой же сфероконизм без аргументации. Если коротко — таски покрывают типовые задачи почти для всей асинхронщины так же, как linq — операции по фильтрации/проекции данных.
I>Таски при необходимости одной лишь асинхронщины это какая то катастрофа. Более громоздкого решения сложно даже придумать.
Снова повторю вопрос — ты использовал код с await на практике? Куда уж проще-то?

S>>И да, таски не отменяют прочих API, не запрещают специфичных расширений и не всегда идеально смешиваются. Точно так же, как linq. Что, выбрасываем?
I>Таски это прежде всего переусложненный всеобъемлющий всемогутор. Их имеет смысл использовать только когда нужно всё и сразу.
Ок, что у нас из основного интерфейса в тасках — Start/Wait/Continuation/Cancellation — не используется практически в любом из вариантов? Остальная магия, включая шедулеры, нужна в первую очередь для инфраструктурщиков и большинством разработчиков напрямую не используется никогда.

I>Хуже всего, что язык прибили гвоздями к либе.
Не более, чем foreach к IEnumerable<>. Обычный биндинг по паттерну, попробуй найти task вот тут

I>Если бы в С# был экспрешном и работал как yield в Питоне, для той же асинхронщины можно сделать более простое и эффективное решение, где не надо ломать часами голову, исправляя чей то дедлок.
В сотый раз — за await/task может быть любая реализация, дедлоки детектятся из коробки, см первый рисунок тут. Изучите наконец тему, по которой спорите!

I>>>Итого — кода у тебя нет. До свидания.
S>>Троллинг тоже не катит. "Поскипал код в ответе" и "кода у тебя нет" — тоже разные вещи.
I>Это не троллинг, это факт. Реши задачу и я покажу тебе все что ты хочешь прямо в твоем коде.

Да ладно, т.е. самому дописать до

        static async Task<int> Sample()
        { 
            Func<int, int> future = i => i*10;

            var items = Enumerable.Range(0, 10);

            var tasks = items.Select(i => Task.Factory.FromAsync<int, int>(
                future.BeginInvoke, future.EndInvoke,
                i, null));

            await Task.WhenAll(tasks);

            return tasks.Sum(t => t.Result);
        }

        static void Main(string[] args)
        {
            Console.WriteLine(Sample().Result);
            Console.ReadKey();
        }

лень?

Всё как просил —

А вот извраты FileStream.BeginRead в своём уме никто не использует
В кратце — асинхронная цепочка в таком вот стиле это АДЪ. попробуй написать скажем сумму последовательности, если у тебя одна переменная и методы навроде BeginRead, BeginWrite и тд.

Где там АДЪ?

Здравствуйте, Sinix, Вы писали:

Я скипнул пока что

S>Да ладно, т.е. самому дописать до
S>

S>

S>лень?

От тебя требовалось сделать разделяемый ресурс и ты с этим не справился.

1 некоторая переменная, котороую читают и пишут писатели-читатели
2 доступ к ней делается через begin-end

У тебя вообще нет разделяемого ресурса и ты сделал совсем не то АПИ про которое мы говорили.

Можешь поискать в данном форуме решение от vdimas, если очень хочется, все что я обещал показать тебе, я показал ему.

Здравствуйте, Ikemefula, Вы писали:

I>От тебя требовалось сделать разделяемый ресурс и ты с этим не справился.
Сорри, но я завязываю.

Попробуй перечитать свою постановку задачи. Чтоб далеко не лазил — вот цитата:

А вот извраты FileStream.BeginRead в своём уме никто не использует
В кратце — асинхронная цепочка в таком вот стиле это АДЪ. попробуй написать скажем сумму последовательности, если у тебя одна переменная и методы навроде BeginRead, BeginWrite и тд.

и найди там слова "разделяемый ресурс".

Тем не менее, если так хочется ресурс<>последовательность, рекомендую посмотреть в сторону rx. .FromAsync() там тоже есть, остальное элементарно.

Закругляюсь, спасибо, было приятно поспорить.

Здравствуйте, Ikemefula, Вы писали:

НС>>Не знаю что у тебя там возникает, но таски прекрасно справляются без кооперативной многозадачности.
I>Не могут они без этого справляться.

Они не просто могут, они справляются.

I> Таски унутре continuation-based, то есть, практически кооперативная многозадачность.

Нет. Continuation там для описания зависимостей, а не для многозадачности. Многозадачность там обычная, вытесняющая.
Ты ваот что путаешь, похоже: зеленые потоки могут использоваться в качестве варианта реализации continuation monad практически в лоб. Таски же реализуют СМ по другому. Ты же думаешь что все реализации СМ это зеленые потоки.

I>Более того, в тасках она растёт в полный рост и решать её нужно руками, но попроще чем в APM. В Зеленых потоках её тоже надо решать, при чем еще проще, чем в тасках.

Ага, значит все таки таски это не зеленые потоки.

Здравствуйте, Ikemefula, Вы писали:

I>А что по твоему унутре зеленых потоков, чудеса и магия ? Там все те же самые continuation, отсюда возможность переключать выполнение ниток руками.

Да не переключает в тасках никто выполнение нитей. Совсем. Пока конкретная таска выполняется, она владеет потоком ОС монопольно.

I>Если бы в С# был экспрешном и работал как yield в Питоне

Переведи на русский.

Здравствуйте, netch80, Вы писали:

N>Что за "таски" в дотнете, не знаю

http://en.wikipedia.org/wiki/Task_Parallel_Library#Task_Parallel_Library

Здравствуйте, Sinix, Вы писали:

S>Попробуй перечитать свою постановку задачи. Чтоб далеко не лазил — вот цитата:
S>

S>А вот извраты FileStream.BeginRead в своём уме никто не использует
S> В кратце — асинхронная цепочка в таком вот стиле это АДЪ. попробуй написать скажем сумму последовательности, если у тебя одна переменная и методы навроде BeginRead, BeginWrite и тд.

S>и найди там слова "разделяемый ресурс".

Я выделил. Здесь вроде понятно, что переменную нужно читать-писать асинхронными методами.

S>Тем не менее, если так хочется ресурс<>последовательность, рекомендую посмотреть в сторону rx. .FromAsync() там тоже есть, остальное элементарно.

Нет, не элементарно. FromAsync ничего не меняет.

См код который я показал НС

когда выполняется несколько операций одновременно, всилу асинхроннщины в IOCP, есть временные промежутки между write и read одной операции.
read вернул 5, write должен модифицировать именно это значение — инвариант. Но в силу наличия промежутка из за шедулинга, одна из операций успеет чего нибудь сделать — или прочитать, или записать. итого, write нарушает инвариант.

вот эта хрень растет из IOCP, а ты мне хотел показать, как синхронный код выполнить асинхронно, т.е. исключить IOCP.

Если тебе это непонятно — тренируйся.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>>>Не знаю что у тебя там возникает, но таски прекрасно справляются без кооперативной многозадачности.
I>>Не могут они без этого справляться.

НС>Они не просто могут, они справляются.

Они именно её и используют, в т.ч..

I>> Таски унутре continuation-based, то есть, практически кооперативная многозадачность.

НС>Нет. Continuation там для описания зависимостей, а не для многозадачности.

continuation нужны для того, что бы работали операции которые завязаны например на тот же таймер. По другому это в принципе невозможно.

>Многозадачность там обычная, вытесняющая.

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

Смотри внимательно:

static void Main(string[] args)
        {
            for (int i = 0; i < 100; i++)
            {
                Operation();
            }

            Console.ReadLine();
        }

        static async void Operation()
        {
            var value = await Read();

            Write(value + 1);
        }

        private static async Task<int> Read()
        {
            await Task.Delay(Delay);

            return _resource;
        }

        private static async void Write(int value)
        {
            await Task.Delay(Delay);

            _resource = value;
            Console.WriteLine(_resource);
        }

        private static int Delay {
            get {
                return (int) ((Rnd.Next() / (double)int.MaxValue) * 1000);
            }
        }

        private static int _resource = 0;
        static Random Rnd = new Random();

Надо объяснять, что Operation асинхронная ?
Надо объяснять, что это кооперативная многозадачность ?

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

Теперь покажи ,как ты эту асинхронщину исправишь своими мега-тасками.

НС>Ты ваот что путаешь, похоже: зеленые потоки могут использоваться в качестве варианта реализации continuation monad практически в лоб. Таски же реализуют СМ по другому. Ты же думаешь что все реализации СМ это зеленые потоки.

ты лучше подумай, для чего нужен event loop для async-await.

I>>Более того, в тасках она растёт в полный рост и решать её нужно руками, но попроще чем в APM. В Зеленых потоках её тоже надо решать, при чем еще проще, чем в тасках.

НС>Ага, значит все таки таски это не зеленые потоки.

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

Здравствуйте, Ikemefula, Вы писали:

НС>>Они не просто могут, они справляются.
I>Они именно её и используют, в т.ч..

Нет. Никаких зеленых потоков внутри тасков нет. От слова совсем.

I>>> Таски унутре continuation-based, то есть, практически кооперативная многозадачность.
НС>>Нет. Continuation там для описания зависимостей, а не для многозадачности.
I>continuation нужны для того, что бы работали операции которые завязаны например на тот же таймер.

Нет. Continuation описывают зависимости между тасками чтобы обеспечить правильный порядок их исполнения. Частный случай такой зависимости — фьючерсы.

>>Многозадачность там обычная, вытесняющая.
I>Многозадачность зависит не от тасков.

Зависит от конкретного таска. Но простейший таск, который создается вызовом Task.Run, использует многозадачность, обеспечиваемую ОС. Стандартные IO bound таски работают, опять же, через механизм ОС — IOCP. Никаких зеленых потоков в штатных реализациях тасков нет.

I> Если я запущу одновремено две асинхронные цепочки в одном потоке, они будут работать по правилам кооперативной многозадачности

Нет.

class Program
{
    private static Task<int> MyTask()
    {
        return Task.Run(
            () =>
            {
                Thread.Sleep(100);
                return Thread.CurrentThread.ManagedThreadId;
            });
    }

    private async static void Do()
    {
        var id1 = await MyTask();
        var id2 = await MyTask();
        Console.WriteLine("id1 = " + id1);
        Console.WriteLine("id2 = " + id2);
    }

    static void Main()
    {
        Do();
        Console.Read();
    }
}

У меня выводит:

id1 = 3
id2 = 4

Кооперативная говоришь?

I>ты лучше подумай, для чего нужен event loop для async-await.

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

НС>>Ага, значит все таки таски это не зеленые потоки.
I>Разница только в дизайне. В одном случае сделали инструент, а в другом получился всемогутор, которым даже авторы не умеют пользоваться.

Смысл фразы непонятен.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Да не переключает в тасках никто выполнение нитей. Совсем. Пока конкретная таска выполняется, она владеет потоком ОС монопольно.

А эвентлуп каким то чудом узнает, что вон тот колбек он идет от этого таска, а не от того

Пиши еще

I>>Если бы в С# был экспрешном и работал как yield в Питоне

НС>Переведи на русский.

Здесь все просто

var x = yield(Task.SomeAwaitable())

получается тот же await

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Нет. Никаких зеленых потоков внутри тасков нет. От слова совсем.

А я и не говорил, что они унутре. Ты вероятно, с кем то еще споришь

НС>Нет. Continuation описывают зависимости между тасками чтобы обеспечить правильный порядок их исполнения. Частный случай такой зависимости — фьючерсы.

I>> Если я запущу одновремено две асинхронные цепочки в одном потоке, они будут работать по правилам кооперативной многозадачности

НС>Нет.
НС> Thread.Sleep(100);
НС>Кооперативная говоришь?

И по твоему Thread.Sleep асинхронный ? Да ты, я вижу, непростой

Замени его на Таймер, что бы получить асинхронность и объясни результаты.

А еще лучше прекратить валять дурака и запустить код, который я тебе дал

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

Ога. Это если ты Thread.Sleep вызываешь.

НС>Смысл фразы непонятен.

Я заметил это по Thread.Sleep

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Да не переключает в тасках никто выполнение нитей. Совсем. Пока конкретная таска выполняется, она владеет потоком ОС монопольно.

Как и зеленый поток, вообще говоря

Выполнение ты сам переключаешь. Например, так —

var x = await Something(...)

await отдаёт управление шедулеру, а он сам решит, чего и когда продолжить.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>>>Не знаю что у тебя там возникает, но таски прекрасно справляются без кооперативной многозадачности.
I>>Не могут они без этого справляться.
I>> Таски унутре continuation-based, то есть, практически кооперативная многозадачность.
НС>Нет. Continuation там для описания зависимостей, а не для многозадачности. Многозадачность там обычная, вытесняющая.

Я посмотрел ссылку, которую ты прислал, про TPL. И вижу следующее:

A Task Manager contains a global queue of Tasks, which are then executed. In addition, it also encapsulates multiple threads onto which the Tasks are executed. By default, as many threads as there are processors (or processor cores) on the system are created, though this number may be manually modified. Each thread is associated with a thread-specific queue of Tasks. When idle, each thread picks up a batch of Tasks and puts them on its local queue, where they are then executed, one by one. If the global queue is empty, a thread will look for Tasks in the queues of its peers, and will take the Tasks which have been in the queue the longest (task stealing).

Исходя из неё, в этом средстве нет никакого варианта переключиться на другую задачу, если текущая ушла в блокирующее ожидание. Да, ОС переключит в этом случае на другую нить, но текущая будет всё равно занята. А если все нити (как написано, по умолчанию их количество равно количеству логических процессоров) будут таким образом заняты, весь task manager остановится. То есть всё это не более чем пул нитей с каким-то хилым закосом под человеческую морду.
Да, я здесь сужу именно по отсутствию информации про такие механизмы в статье. Но косвенным подтверждением является то, что статья в MSDN Magazine разливается соловьём про разные вычисления (CPU-bound) и ни слова про ввод-вывод, зато явно что это "пул с возможностью остановить и подождать". Ещё одно подтверждение — логика планирования — каждый забирает по пачке задач, но потом могут обмениваться очередями — однозначный расчёт на потенциально долгое выполнение одной задачи.

А в этом случае "таски прекрасно справляются без кооперативной многозадачности" уже некорректно, как только мы говорим про I/O. Там, где на IOCP и аналогах можно зашедулить пару тысяч одновременных I/O операций, тут ты это не сделаешь в принципе.

Здравствуйте, Ikemefula, Вы писали:

I>>>А вот извраты FileStream.BeginRead в своём уме никто не использует
НС>>А что там такого извратного?
I>В кратце — асинхронная цепочка в таком вот стиле это АДЪ. попробуй написать скажем сумму последовательности, если у тебя одна переменная и методы навроде BeginRead, BeginWrite и тд.

Ну а откуда предложение делать через одну переменную? Пусть будут хотя бы две

А так — да, писали в таком стиле. Более того, кто пишет на каком-нибудь Erlang иначе и не работает, потому что в языке вместо циклов рекурсия

Хотя там обычно преимущество — что действия типа file:read(), gen_server:call() шедулят переключение с текущего процесса (green thread в терминах более распространённых), но возвращают в него же с результатом. Но есть и такие, которые могут только вызвать callback, которому нужно передать полный контекст. Вот тогда начинается рисование FSM.

I>Внезапно, даже в однопоточной модели возникают гонки в силу кооперативной многозадачности. В зеленых потоках эту проблему проще контролировать.

Почему проще?

Здравствуйте, Sinix, Вы писали:

S>Напомню контекст, твой прошлый пост:
S>

S>А вот извраты FileStream.BeginRead в своём уме никто не использует
S>В кратце — асинхронная цепочка в таком вот стиле это АДЪ. попробуй написать скажем сумму последовательности, если у тебя одна переменная и методы навроде BeginRead, BeginWrite и тд.
S>Внезапно, даже в однопоточной модели возникают гонки в силу кооперативной многозадачности. В зеленых потоках эту проблему проще контролировать.

S>Можешь объяснить, при чём тут вообще кооперативная многозадачность и какой магией зелёные потоки будут отличаться от тасков?

См. мой предыдущий ответ. С тасками названного тобой образца заполнение всех нитей ожиданием I/O заблокирует пул в целом. Более того, ожидание чего-то через Task.Wait() может дать такой же результат, если нет свободных нитей, и поставленная в очередь задача не может из-за этого выполниться. Если егойный task manager решает это временным порождением новых нитей, то это грязный хак, не отменяющий порочность механизма (и ещё неизвестно, сколько ему надо, чтобы понять ситуацию). Если же он в состоянии при любом переходе исполняющей нити в ожидание переключать эту нить на другую задачу — то фактически мы имеем подложкой под task manager — не OS threads, а green threads.

S>Нет, пойнт в другом: ты вбрасывашь цепочку вообще никак не связанных утверждений аля
S>

S>Микрософт всунула в таски все что только смогла придумать
S>разработчики в МС сами не понимают, как работают таски
S>когда вижла зависает и сообщает что чем то занята, пудозреваю, это те же таски

S>причём все, такое впечатление, только что из пальца высосан. И делаешь вывод: у тасков есть проблемы.

А что в таком случае происходит, когда "вижла" зависает? (BTW, что такое "вижла"? Visual Studio или что-то другое? я вашего жаргона не знаю)

I>>Ты немного додумал за меня, процентов на 90. Вместо "ExecutionContext не нужен" было " не надо поддержвать сто тыщ пиццот разных контекстов и потоковых моделей"
S>В тасках ровно одна модель. За неё прячется практически что угодно — от обычных потоков до акторов и динамического раскидывания вызовов по кластеру. Только не надо начинать за "это всё не нужно"

Мнэээ... там таки есть гарантия, что спящая в ожидании задача освободит тред, или нет?
Если её нет на распространённой платформе — то о чём говорить?

I>>Таски нельзя отладить — речь была про APM-модель. Будет гаранировано АДЪ. Собственно, с тасками у микрософта пока что не сильно лучше.
S>Ты 100% не использовал Parallel Stacks Window. Т.е. с тасками по сути не работал, о чём и было сказано выше. Про отладку в VS 1013 с поддержкой awiat и прочих плюшек даже начинать не буду.

Простите, а с каких это пор неиспользование возможности _отладчика_ для "тасков" означает неработу с ними "по сути"?

Здравствуйте, Ikemefula, Вы писали:

I>Без зеленых потоков получится моделька навроде той что в nginx. Разработчиков такого уровня в каждом регионе по пару штук.

nginx в общем-то очень простой, хоть и объёмный. Пул тредов с FSM в каждой плюс немного мелких плюшек вокруг (например, файловый AIO делать через ядерный AIO или как?) Хотя это я, может, недооцениваю сложность подхода через FSM для прогерских ширнармасс. Мне было бы в разы сложнее поднять такой проект в целом и не обломиться, чем сделать именно такую реализацию на FSM и IOCP-с-аналогами, пока есть время и деньги

Если уж искать пример сложной логики, которую фиг так прямо переложишь на IOCP/epoll/etc. это работа с БД, драйвер FS и тому подобное, где развилок логики чуть более чем дохрена и контексты значительно более сложные, а клиентов не тысячи. По тому, что я вижу на СУБД, они делают сессии целыми нитями или даже процессами (под Unix, где это относительно дёшево).

BTW если ты вспомнил про nginx — вспомни и историю http cache "Oops!" (разработка одесской команды под руководством Игоря Хасилева). У них была организация — одна нить на клиента (в отличие от конкурента squid, который стоял на poll+FSM). Но у них были сплошь Sun с соляркой, где нити поддерживались честно и их можно было плодить. Ни Linux ни FreeBSD тогда (считаем, 1997-2002) нормальных нитей не держали, и на них Oops не выживал. А с увеличением количества клиентов (был у нас такой безумный период, когда внешних каналов почти не было — их только после оранжевой революции появилось, из-за изгнания старых взяточников из НКРЗ; прокси были тогда крайне важны) — и Oops перестал держать, в то время как squid справлялся, особенно с новыми плюшками вроде cache peering.

Здравствуйте, Ikemefula, Вы писали:

I>И по твоему Thread.Sleep асинхронный ? Да ты, я вижу, непростой
I>Замени его на Таймер, что бы получить асинхронность и объясни результаты.

Ничего не понял.

НС>>Не нужен, таски прекрасно работают и в консольных приложениях. Нужен для синхронизации в случае GUI.
I>Ога. Это если ты Thread.Sleep вызываешь.

Это неважно что ты вызываешь. Любая CPU bound задача будет вести себя аналогично. И колбеки IOCP тоже будут порождаться в других потоках.

НС>>Смысл фразы непонятен.
I>Я заметил это по Thread.Sleep

А по русски повторить не можешь?

Здравствуйте, netch80, Вы писали:

N> То есть всё это не более чем пул нитей с каким-то хилым закосом под человеческую морду.

Нет. Это вообще не про пул нитей.

N>Но косвенным подтверждением является то, что статья в MSDN Magazine разливается соловьём про разные вычисления (CPU-bound) и ни слова про ввод-вывод

С IO bound там тоже все хорошо.

N>однозначный расчёт на потенциально долгое выполнение одной задачи.

С точностью до наоборот — таски заточены под fine grained паралллелизм, т.е. под много коротких задач.

N>Там, где на IOCP и аналогах можно зашедулить пару тысяч одновременных I/O операций, тут ты это не сделаешь в принципе.

Ты точно ничего не понял. Таски это не замена IOCP и для ввода-вывода этот самый IOCP в тасках используется напрямую.

Здравствуйте, Ikemefula, Вы писали:

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

Эвентлуп вообще ничего не узнает. Он используется только для отдачи результатов в основной поток при соответствующем контексте.

I>>>Если бы в С# был экспрешном и работал как yield в Питоне
НС>>Переведи на русский.
I>Здесь все просто
I>var x = yield(Task.SomeAwaitable())
I>получается тот же await

Стало еще меньше понятно о чем ты хотел сказать.

Здравствуйте, Ikemefula, Вы писали:

I>Как и зеленый поток, вообще говоря

Выполнение ты сам переключаешь. Например, так —
I>

I>var x = await Something(...)
I>

I>await отдаёт управление шедулеру, а он сам решит, чего и когда продолжить.

Ты по прежнему путаешь таски и реализацию continuation monad в компиляторе C#.

Здравствуйте, netch80, Вы писали:

N>По тому, что я вижу на СУБД, они делают сессии целыми нитями или даже процессами (под Unix, где это относительно дёшево).

Кто они? Касательно MSSQL, к примеру, IOCP прекрасно можно использовать — SqlCommand.ExecuteReaderAsync использует в конечном итоге IOCP на сокет сервера, то есть никаких потоков во время ожидания в пуле не блокируется.

Здравствуйте, Ночной Смотрящий, Вы писали:

N>> То есть всё это не более чем пул нитей с каким-то хилым закосом под человеческую морду.
НС>Нет. Это вообще не про пул нитей.

Естественно, это не "про" пул нитей. Но внутри это пул нитей, о чём статья явно говорит.

N>>Но косвенным подтверждением является то, что статья в MSDN Magazine разливается соловьём про разные вычисления (CPU-bound) и ни слова про ввод-вывод
НС>С IO bound там тоже все хорошо.

Объясни, как именно. Из указанных тобой ресурсов это не следует, скорее наоборот.

N>>однозначный расчёт на потенциально долгое выполнение одной задачи.
НС>С точностью до наоборот — таски заточены под fine grained паралллелизм, т.е. под много коротких задач.

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

N>>Там, где на IOCP и аналогах можно зашедулить пару тысяч одновременных I/O операций, тут ты это не сделаешь в принципе.
НС>Ты точно ничего не понял. Таски это не замена IOCP и для ввода-вывода этот самый IOCP в тасках используется напрямую.

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

Здравствуйте, Ночной Смотрящий, Вы писали:

N>>По тому, что я вижу на СУБД, они делают сессии целыми нитями или даже процессами (под Unix, где это относительно дёшево).
НС>Кто они?

mysql, postgresql, firebird.
СУБД без открытого кода движка я тут не рассматриваю по определению.

НС> Касательно MSSQL, к примеру, IOCP прекрасно можно использовать — SqlCommand.ExecuteReaderAsync использует в конечном итоге IOCP на сокет сервера, то есть никаких потоков во время ожидания в пуле не блокируется.

Это в T-SQL? Если да, то это уже не в счёт.

Здравствуйте, Sinix, Вы писали:

S>>>Можешь объяснить, при чём тут вообще кооперативная многозадачность и какой магией зелёные потоки будут отличаться от тасков?
I>>Если в одном потоке всякие IOCP, BeginXXX, EndXXX, то асинхронщина здесь и есть та самая кооперативная многозадачность.
S>Нет. Хотя бы потому, что IOCP и "в одном потоке" не соотносятся вообще никак, почитай как оно работают.

На MSDN описано лучше.

S> Запрос инициируется с рабочего потока, запихивается в очередь iocp, по завершению — продолжает выполнение в потоке из IOCP-пула. Кооперативной многозадачности тут нет: обработчики iocp будут выполняться параллельно вплоть до исчерпания пула потоков.

Не-а. Всё описанное тобой получается только в случае если ты сам, явно, определишь какой-то "пул" ниток, которые не будут делать ничего кроме как дёргать GetQueuedCompletionStatus(); но это будет _твоё_, как разработчика, решение. В то же время, если ты сделаешь в одной нити

создание IOCP

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

цикл типа "пока не приказали посинеть" из ожидания события и его обработки, включая помещение новых асинхронных операций с оповещением через тот же IOCP объект

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

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

S>Это всё упрощённо и очень схематично конечно, реализации могут быть разные. Но варианта "асинхронщина здесь и есть та самая кооперативная многозадачность" точно не будет. За бесполезностью

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

Здравствуйте, alex_public, Вы писали:

N>>Картинку видел. Но там нет никаких прямых данных о делении по "миру разработки". А косвенно, если пересчитать, мои данные ничуть этому не противоречат, если, например, в коробочном ПО C/C++ занимает процентов 90, а во внутреннем — 30 (а ява, например, 50), то в сумме получатся где-то те же цифры.
_>Да, в принципе такое возможно. Правда в таком случае мир коробочного ПО уж совсем мелкий должен быть, потому как в данных рассуждениях был забыт (кстати про него почему-то часто забывают тут) embedded мир. Который весьма не маленький и как раз в нём основное царство C, с вкраплениями asm и C++.

Embedded широк по количеству установок, но узок — по количеству людей, которые в нём работают. Тем более что сейчас всё больше такого embedded, где линукс запускается без особых тормозов...

_> Так что цифра в 70-80% программистов мира работающих на внутреннее ПО мне кажется всё же несколько завышенной. Хотя всё может быть, у меня нет прямых цифр на этот счёт.

Я тот источник тоже не могу найти, картина могла, конечно, сдвинуться существенно. Вообще сейчас деление по языкам в нём потеряло важность (PHP+JS это где? Это может быть и в домашнем раутере)

Здравствуйте, netch80, Вы писали:

N>Естественно, это не "про" пул нитей. Но внутри это пул нитей, о чём статья явно говорит.

Внутри может быть что угодно, читай внимательнее этот топик.

N>Объясни, как именно.

Что значит как именно? Когда я создаю таски, завязанные на ввод-вывод, используются абсолютно стандартные IOCP.

НС>>С точностью до наоборот — таски заточены под fine grained паралллелизм, т.е. под много коротких задач.
N>Не смешивай расчёт на идеальное применение

Это не идеальное применение, это design target при создании тасков.

НС>>Ты точно ничего не понял. Таски это не замена IOCP и для ввода-вывода этот самый IOCP в тасках используется напрямую.
N>Каким именно образом?

Вопрос непонятен.

N> "Таска" ставится без условий запустить её только если выполнилось какое-то внешнее условие, а возможности дешёвого ожидания в уже работающей задаче ты не показал.

А как я ее должен показать, интересно?

Здравствуйте, netch80, Вы писали:

N>mysql, postgresql, firebird.

Без понятия.

N>СУБД без открытого кода движка я тут не рассматриваю по определению.

Смешно.

Здравствуйте, Ночной Смотрящий, Вы писали:

N>>Естественно, это не "про" пул нитей. Но внутри это пул нитей, о чём статья явно говорит.
НС>Внутри может быть что угодно, читай внимательнее этот топик.

Почему я должен верить "этому топику" и не верить статье в MSDN Magazine?

N>> "Таска" ставится без условий запустить её только если выполнилось какое-то внешнее условие, а возможности дешёвого ожидания в уже работающей задаче ты не показал.
НС>А как я ее должен показать, интересно?

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

фиксирует время начала выполнения рабочей функции

делает sleep(M секунд)

фиксирует время конца выполнения рабочей функции и возвращает результат — сколько прошло с момента старта (в секундах)

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

Вариант 1. Задачи в спячке запустятся по количеству логических процессоров (далее nLR), и займут всё. В таком случае выполнение займёт до нескольких суток, максимальное возвращаемое значение будет около 1000000/nLR и график значений будет похоже на линейную функцию.

Вариант 2. Кто-то по дороге до системного Sleep() перехватит факт блокирующего вызова и вызовет переключение на исполнение другой задачи. В таком случае все значения будут близки к 100. Это будет означать, что фактически он работает поверх зелёных нитей.

Вариант 3. Пул, заметив, что все нити заняты, а задач в очереди ещё дофига, начнёт создавать новые нити и скидывать задачи на них. В зависимости от того, сколько в пределе он может позволить себе создать, среднее будет менее 1000000/nLR, но более 100. Далее можно будет оценить методы его работы. Например, если детект переполнения периодический, раз в секунду, а предельное количество нитей не ограничено, то среднее будет порядка 500000/nLR, а средние по квантилям покажут ровную лесенку.

Начинать с N=100, M=10, и увеличивать пока принципиальная картина не перестанет меняться.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Здравствуйте, netch80, Вы писали:

N>>mysql, postgresql, firebird.

НС>Без понятия.

N>>СУБД без открытого кода движка я тут не рассматриваю по определению.

НС>Смешно.

Я говорил о коде собственно СУБД (а не пользовательском в нём), и думаю, ты его не можешь увидеть тоже. Поэтому нет причин для смеха.

Здравствуйте, netch80, Вы писали:

N>Почему я должен верить "этому топику" и не верить статье в MSDN Magazine?

Потому что статья просто не раскрывает тему.

НС>>А как я ее должен показать, интересно?
N>Сделай следующий эксперимент. Поставь на выполнение в самом начале работы программы N задач, каждая из которых
N>

фиксирует время начала выполнения рабочей функции
N>

делает sleep(M секунд)
N>

фиксирует время конца выполнения рабочей функции и возвращает результат — сколько прошло с момента старта (в секундах)

И где здесь IOCP? CPU bound в чистом виде.

N>Вариант 2. Кто-то по дороге до системного Sleep() перехватит факт блокирующего вызова и вызовет переключение на исполнение другой задачи.

Не перехватит. Еще раз — таски это не зеленые потоки, никакой магии по прерыванию нити вне механики ОС в них нет, не стоит путать таски с continuation monad в шарпе. Если у тебя CPU bound задача, то она будет выполнятся в рамках тасков точно так же, как и при ручном забирании потока из пула. Если же тебе нужно притормозить таску не занимая поток — есть Task.Delay(), внутри которого, внезапно, IOCP на системном таймере.
Если же пытаться специально обмануть фремворк так, чтобы поставить его раком — это всегда можно сделать, безусловно.

Здравствуйте, netch80, Вы писали:

N>Я говорил о коде собственно СУБД (а не пользовательском в нём), и думаю, ты его не можешь увидеть тоже. Поэтому нет причин для смеха.

Когда в руках молоток — все вокруг кажется гвоздями.

Здравствуйте, Ночной Смотрящий, Вы писали:

N>>Почему я должен верить "этому топику" и не верить статье в MSDN Magazine?
НС>Потому что статья просто не раскрывает тему.

Судя по твоему же ответу ниже, она достаточно её раскрывает, применительно к теме данного обсуждения.

НС>>>А как я ее должен показать, интересно?
N>>Сделай следующий эксперимент. Поставь на выполнение в самом начале работы программы N задач, каждая из которых
N>>

фиксирует время начала выполнения рабочей функции
N>>

делает sleep(M секунд)
N>>

фиксирует время конца выполнения рабочей функции и возвращает результат — сколько прошло с момента старта (в секундах)
НС>И где здесь IOCP? CPU bound в чистом виде.

IOCP тут, действительно, ни при чём. А вот называть sleep(), который превращается в перевод треда в спящее состояние и ожидание прерывания от таймера (через прокладку в виде диспетчера), "CPU bound", это верх запутывания. Это чистое IO, и эффект от него такой же, как если бы задача сделала блокирующий read().

N>>Вариант 2. Кто-то по дороге до системного Sleep() перехватит факт блокирующего вызова и вызовет переключение на исполнение другой задачи.

НС>Не перехватит. Еще раз — таски это не зеленые потоки, никакой магии по прерыванию нити вне механики ОС в них нет,

Во! Это то, что я ожидал от тебя в данном треде. А теперь, возвращаясь на K сообщений назад:

НС>>>Не знаю что у тебя там возникает, но таски прекрасно справляются без кооперативной многозадачности.

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

НС> не стоит путать таски с continuation monad в шарпе.

Я не путаю, потому что последнего просто не знаю

Ну нету у меня шарпа в работе.

НС> Если у тебя CPU bound задача, то она будет выполнятся в рамках тасков точно так же, как и при ручном забирании потока из пула. Если же тебе нужно притормозить таску не занимая поток — есть Task.Delay(), внутри которого, внезапно, IOCP на системном таймере.
НС>Если же пытаться специально обмануть фремворк так, чтобы поставить его раком — это всегда можно сделать, безусловно.

Ты вцепился в sleep как финальную однозначность, поэтому вспоминаешь про Delay(). Хорошо, представим себе вместо этого чтение чего-то, что придёт в дескриптор только через минуту. Результат тот же (и см. выше про IO bound).

Здравствуйте, netch80, Вы писали:

N>IOCP тут, действительно, ни при чём. А вот называть sleep(), который превращается в перевод треда в спящее состояние и ожидание прерывания от таймера (через прокладку в виде диспетчера), "CPU bound", это верх запутывания.

С точки зрения тасков это CPU bound. Таски это не низкоуровневый механизм ядра, это прикладная библиотека высокого уровня. Зачем ты пытаешься навесить на нее абсолютно несвойственный ей функционал — мне непонятно.

N> Это чистое IO, и эффект от него такой же, как если бы задача сделала блокирующий read().

Ну так не надо делать блокирующий read.

НС>>Не перехватит. Еще раз — таски это не зеленые потоки, никакой магии по прерыванию нити вне механики ОС в них нет,
N>Во! Это то, что я ожидал от тебя в данном треде.

Я это пишу здесь ровно с первого сообщения.

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

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

НС>> не стоит путать таски с continuation monad в шарпе.
N>Я не путаю, потому что последнего просто не знаю

Ну нету у меня шарпа в работе.

Это на случай если ты принимаешь на веру то, что тут пишет Икемефула. Потому что на самом деле есть 2 сущности:
1) TPL ака таски. Это библиотека, которая появилась задолго до шарповских async/await, в 4 фреймворке. Цель ее создания — облегчение написания асинхронного fine grained кода. Первая версия создавалась прежде всего для внутреннего слоя PLINQ — декларативного использования асинхронности на задачах обработки последовательностей. Потом таски стали использовать в Reactive Extensions, потом в ASP.NET MVC. Это все еще до C# 5, который с поддержкой асинхронности.
2) async/await в C# 5+. Это вшитая в язык continuation monad. Если очень грубо, то компилятор разрезает линейный как бы синхронный исходный код по явно указанным точкам на куски, выстраивая зависимости между ними. А затем, на основании этой информации, создает FSM, который позволяет выполнять эти куски по отдельности (логика примерно та же, что и при реализации yield для итераторов). Соответственно, визуально это выглядит как будто кто то "прерывает" выполнение синхронного кода, но на самом деле никакого синхронного непрерывного кода при этом нет. Естественно, что обработать таким образом компилятор может только то что в исходниках, а не системные вызовы типа Thread.Sleep.
И да, здесь определенная связь с зелеными потоками есть — в других языках, о которых Икемефула упоминал, для реализации продолжений в основном используют зеленые потоки и реализуют эти самые продолжжения в лоб. Хуже того, лет 10 назад МС даже выкладывал в качестве демонстрации расширяемости CLR Host реализацию продолжений (yield) на системных файберах для обычного древнего C# 1.0.
Я же тут пытаюсь донести мысль, что то что зеленые потоки могут быть использованы для реализации async/await, не делает async/await зелеными потоками.

НС>>Если же пытаться специально обмануть фремворк так, чтобы поставить его раком — это всегда можно сделать, безусловно.
N>Ты вцепился в sleep как финальную однозначность, поэтому вспоминаешь про Delay(). Хорошо, представим себе вместо этого чтение чего-то, что придёт в дескриптор только через минуту. Результат тот же (и см. выше про IO bound).

Результат будет ровно тем же, что и при ручном обращении к IOCP. Таски не занимаются непосредственно своим содержимым, они лишь обеспечивают откработку зависимостей между разными тасками. Т.е., грубо, 99% работы TPL для IO bound заключается в том, чтобы по IOCP колбеку получить данные и запустить те таски, которые ждали либо завершения IO, либо его результата. А все эти танцы с пулом начинаются, только если тебе потом надо что то отработать без IOCP.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Ты по прежнему путаешь таски и реализацию continuation monad в компиляторе C#.

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

От тебя требуется объяснить, как же работает код.

То есть, в кратце, тебе надо пояснить, как будет работать в тасках асинхронный код навроде IOCP или таймера того же.

Надо объяснять, что наиболее близко к IOCP это сигнал от таймера, а не Thread.Sleep ?

Ощущение, что ты и sinix путаете две эти вещи.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Ты по прежнему путаешь таски и реализацию continuation monad в компиляторе C#.

Кстати говоря, await можно перепилить на колбеки и всунуть это в таски. Интересно, как ты в этом случае будешь выкручиваться.

Здравствуйте, Ночной Смотрящий, Вы писали:

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

НС>Эвентлуп вообще ничего не узнает. Он используется только для отдачи результатов в основной поток при соответствующем контексте.

Ты чего то путаешь. Если поток управления включает в себя эвентлуп, то ни про какой монопольное владение потоком речи быть не может.

Ты не виляй — я ведь привел пример, покажи, как же таска владеет потоком монопольно.

НС>>>Переведи на русский.
I>>Здесь все просто
I>>var x = yield(Task.SomeAwaitable())
I>>получается тот же await

НС>Стало еще меньше понятно о чем ты хотел сказать.

Неудивительно. await, yield — это прямое указание прерывания текущей задачи. Пока await/yield не вернет управление, будет выполняться другая таска.

То есть, await отдаёт управление шедулеру, а вернется управление через эвентлуп и тот же шедулер.

Скажем, как то иначе прикрутить к потоку IOCP или таймер будет сложновато, придется изобрести эвент-луп.

Здравствуйте, Ikemefula, Вы писали:

I>покажи, как же таска владеет потоком монопольно.

Я тебе уже наглядно продемонстрировал это. И, на всякий случай, никакого эвентлупа там нет, это консольное приложение.
Добавить туда еще идентификатор вызывающего потока и IOCP? Легко:

class Program
{
    private static async Task<int> MyTask()
    {
        var wc = new WebClient();
        var data = await wc.DownloadDataTaskAsync("http://rsdn.ru/forum/flame.comp/5089377.all");
        return Thread.CurrentThread.ManagedThreadId;
    }

    private async static void Do()
    {
        Console.WriteLine("cur = " + Thread.CurrentThread.ManagedThreadId);
        var id1 = await MyTask();
        var id2 = await MyTask();
        Console.WriteLine("id1 = " + id1);
        Console.WriteLine("id2 = " + id2);
    }

    static void Main()
    {
        Do();
        Console.Read();
    }
}

Вывод:

cur = 10
id1 = 19
id2 = 16

Никаких подозрений не появилось?

НС>>Стало еще меньше понятно о чем ты хотел сказать.
I>Неудивительно. await, yield — это прямое указание прерывания текущей задачи

Спасибо, КО. Только при чем тут таски? Это те самые продолжения, о которых я которое уже письмо твержу. Которые могут быть в том числе и при помощи зеленых потоков реализованы. И которые зелеными потоками не являются, и в современном шарпе реализованы тоже без них. Более того, async/await (и тем более yield) вполне можно использовать совсем без TPL, компилятор проверяет только символьное соответствие имен классов и методов.

I>Скажем, как то иначе прикрутить к потоку IOCP или таймер будет сложновато, придется изобрести эвент-луп.

Что значит "прикрутить к потоку IOCP или таймер" (системный таймер, кстати, тоже через IOCP обычно используют)? И как IOCP в тасках работает в консольном или веб приложении, где никаких эвентлупов нет?

Здравствуйте, Ikemefula, Вы писали:

НС>>Ты по прежнему путаешь таски и реализацию continuation monad в компиляторе C#.
I>Ты сказал, что никакой кооперативной многозадачности в тасках нет и быть не может.

Верно. У тебя логическая ошибка — из то что продолжения можно реализовать при помощи кооперативной многозадачности (и даже, для особых извращенцев, наоборот на продолжениях кооперативную многозадачность, запихнув обработку продолжений в цикл, не обязательно цикл выборки сообщений) вовсе не следует что продолжения являются кооперативной многозадачностью. Более того, по факту и для CPU bound и для IO bound задач никакой кооперативной многозадачности нет, используются механизмы ОС напрямую с многозадачностью вытесняющей. Если, конечно, не подсунуть контекст, запускающий таски в одном потоке (asp.net, к примеру, сейчас для cpu bound так делает. Впрочем, даже и в этом случае можно игнорировать контекст вызовом ConfigureAwait(false), но это так, лирика).

I>То есть, в кратце, тебе надо пояснить, как будет работать в тасках асинхронный код навроде IOCP или таймера того же.

Не понимаю вопроса. Он будет работать ровно так же, как и без тасков. Таски в случае IOCP, как я уже писал, нужны только для интеграции в общий граф зависимостей, непосредственно управление IOCP целиком на совести ОС.

Здравствуйте, Ikemefula, Вы писали:

I>Кстати говоря, await можно перепилить на колбеки и всунуть это в таски.

Чего, простите?

I> Интересно, как ты в этом случае будешь выкручиваться.

А почему я должен выкручиваться?

Здравствуйте, Ночной Смотрящий, Вы писали:

N>>IOCP тут, действительно, ни при чём. А вот называть sleep(), который превращается в перевод треда в спящее состояние и ожидание прерывания от таймера (через прокладку в виде диспетчера), "CPU bound", это верх запутывания.
НС>С точки зрения тасков это CPU bound.

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

НС> Таски это не низкоуровневый механизм ядра, это прикладная библиотека высокого уровня. Зачем ты пытаешься навесить на нее абсолютно несвойственный ей функционал — мне непонятно.

Я ничего такого не пытаюсь, не надо мне приписывать. Я показываю, что это не их назначение.

N>> Это чистое IO, и эффект от него такой же, как если бы задача сделала блокирующий read().
НС>Ну так не надо делать блокирующий read.

О! Что и требовалось показать. А в случае что честных, что зелёных веток (в том виде, как я их знаю) с этим проблем нет — блокирующий вызов будет сигналом к переключению.

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

Он этого не обещал, по крайней мере в этом треде. Ты как-то очень странно читаешь.

НС>>> не стоит путать таски с continuation monad в шарпе.
N>>Я не путаю, потому что последнего просто не знаю

Ну нету у меня шарпа в работе.
НС>Это на случай если ты принимаешь на веру то, что тут пишет Икемефула. Потому что на самом деле есть 2 сущности:
НС>1) TPL ака таски. Это библиотека, которая появилась задолго до шарповских async/await, в 4 фреймворке. Цель ее создания — облегчение написания асинхронного fine grained кода. Первая версия создавалась прежде всего для внутреннего слоя PLINQ — декларативного использования асинхронности на задачах обработки последовательностей. Потом таски стали использовать в Reactive Extensions, потом в ASP.NET MVC. Это все еще до C# 5, который с поддержкой асинхронности.
НС>2) async/await в C# 5+. Это вшитая в язык continuation monad. Если очень грубо, то компилятор разрезает линейный как бы синхронный исходный код по явно указанным точкам на куски, выстраивая зависимости между ними. А затем, на основании этой информации, создает FSM, который позволяет выполнять эти куски по отдельности (логика примерно та же, что и при реализации yield для итераторов). Соответственно, визуально это выглядит как будто кто то "прерывает" выполнение синхронного кода, но на самом деле никакого синхронного непрерывного кода при этом нет. Естественно, что обработать таким образом компилятор может только то что в исходниках, а не системные вызовы типа Thread.Sleep.

Это, действительно, слишком грубое объяснение. Потому что не покрывает даже вход в асинхронный контекст — вызов async функции из синхронного кода. Если компилятор не опознаёт, что здесь идёт вызов именно async функции, то вся эта кусочно-гнездовая развесистость может быть только в отдельных нитях, а если опознаёт (например, по типу возврата Task) — то нужно ли было вводить слово async для таких методов?
Далее, я не вижу, чтобы описывался какой-то интеллект по выходу за пределы этого в случае внешних работ; по описанию в MSDN их надо явно переваливать на всякие Task.Run(). То есть получается какой-то "домен" асинхронного выполнения, который не имеет чёткого синтаксического отделения от основного. В первую очередь это проблема с библиотеками. Могут ли библиотечные функции блокироваться в таком случае? Если нет, то как им это гарантированно запретить и что делать с такими попытками?
А есть ли средство аккуратной привязки контекста к месту исполнения (такого, как TLS в тредах), или надо тащить все параметры за собой?
А как писать своими средствами все эти ReadFileAsync()?
Извини, если некоторые вопросы покажутся глупыми, но описание в MSDN написано слишком изиотически, понять по нему детали реализации практически невозможно.

НС>И да, здесь определенная связь с зелеными потоками есть — в других языках, о которых Икемефула упоминал, для реализации продолжений в основном используют зеленые потоки и реализуют эти самые продолжжения в лоб. Хуже того, лет 10 назад МС даже выкладывал в качестве демонстрации расширяемости CLR Host реализацию продолжений (yield) на системных файберах для обычного древнего C# 1.0.

Почему так сразу и "хуже"?

НС>Я же тут пытаюсь донести мысль, что то что зеленые потоки могут быть использованы для реализации async/await, не делает async/await зелеными потоками.

Ну, кажется, ты споришь с кем-то, кого в этом треде вообще не было.

Здравствуйте, netch80, Вы писали:

N>"С точки зрения тасков" это вообще долгая задача.

Шо, с любым значением параметра?

N>Важно, что она выходит за пределы рекомендуемой применимости (хотя бы потому, что такими задачами можно забить весь пул и парализовать его).

Ну и? Что тебя удивляет? Я ж говорю, при желании TPL вполне можно поставить раком.

НС>> Таски это не низкоуровневый механизм ядра, это прикладная библиотека высокого уровня. Зачем ты пытаешься навесить на нее абсолютно несвойственный ей функционал — мне непонятно.
N>Я ничего такого не пытаюсь, не надо мне приписывать. Я показываю, что это не их назначение.

Что не их назначение? Прерывать вызов Thread.Sleep? А что, кто то утверждал обратное?

N>>> Это чистое IO, и эффект от него такой же, как если бы задача сделала блокирующий read().
НС>>Ну так не надо делать блокирующий read.
N>О! Что и требовалось показать.

Зачем тебе потребовалось эту очевидность показать?

N> А в случае что честных, что зелёных веток (в том виде, как я их знаю) с этим проблем нет — блокирующий вызов будет сигналом к переключению.

Честные ветки никуда не делись. А зеленые на Thread.Sleep прореагируют точно так же, как и TPL. Поэтому там есть своя альтернатива, возвращающая управление в менеджер. И вообще таски с этой задачей никак не связаны, они ее решать и не пытаются. Ее решают продолжения.
Еще раз, по буквам, уж не знаю как еще объяснить — таски вообще никак не связаны с кооперативной многозадачностью, абсолютно. Они обеспечивают эффективную реализацию fine grained параллелизма с удобным API, и все. А все игры с await — совсем другая механика.

N>Это, действительно, слишком грубое объяснение. Потому что не покрывает даже вход в асинхронный контекст — вызов async функции из синхронного кода.

А почему оно должно его покрывать? Это личное дело контекста. И контекст, в том числе, может вообще ничего не делать.

N> Если компилятор не опознаёт, что здесь идёт вызов именно async функции, то вся эта кусочно-гнездовая развесистость может быть только в отдельных нитях, а если опознаёт (например, по типу возврата Task) — то нужно ли было вводить слово async для таких методов?

Во-первых компилятор ничего не опознает, он делит код строго по await и никак иначе. Во-вторых async у методов действительно не обязателен, это уже вопросы контроля и читаемости, у Липперта в блоге есть на эту тему пост.

N>Далее, я не вижу, чтобы описывался какой-то интеллект по выходу за пределы этого в случае внешних работ

А он там должен быть?

N>по описанию в MSDN их надо явно переваливать на всякие Task.Run()

Вот уж этого точно не надо, это, по сути, равносильно использованию блокирующего API вместо IOCP.

N>. То есть получается какой-то "домен" асинхронного выполнения, который не имеет чёткого синтаксического отделения от основного. В первую очередь это проблема с библиотеками. Могут ли библиотечные функции блокироваться в таком случае? Если нет, то как им это гарантированно запретить и что делать с такими попытками?

Если честно, не очень понял вопросы.

N>А есть ли средство аккуратной привязки контекста к месту исполнения (такого, как TLS в тредах), или надо тащить все параметры за собой?

Оно к TLS и привязывается, ничего никуда тащить не надо.

N>А как писать своими средствами все эти ReadFileAsync()?

Исходники в большинстве случаев доступны. Там все тривиально. Вот пример:

public Task<byte[]> DownloadDataTaskAsync(Uri address)
{
        // Create the task to be returned
        var tcs = new TaskCompletionSource<byte[]>(address);

        // Setup the callback event handler
        DownloadDataCompletedEventHandler handler = null;
        handler = (sender, e) => HandleCompletion(tcs, e, (args) => args.Result, handler, (webClient, completion) => webClient.DownloadDataCompleted -= completion);
        DownloadDataCompleted += handler;

        // Start the async operation.
        try { DownloadDataAsync(address, tcs); }
        catch
        {
            DownloadDataCompleted -= handler;
            throw;
        }

        // Return the task that represents the async operation
        return tcs.Task;
}

DownloadDataAsync работает через IOCP.

N>Извини, если некоторые вопросы покажутся глупыми, но описание в MSDN написано слишком изиотически, понять по нему детали реализации практически невозможно.

В MSDN много описаний.

N>Почему так сразу и "хуже"?

Ну, чтобы совсем запутать

НС>>Я же тут пытаюсь донести мысль, что то что зеленые потоки могут быть использованы для реализации async/await, не делает async/await зелеными потоками.
N>Ну, кажется, ты споришь с кем-то, кого в этом треде вообще не было.

Кажется.

Здравствуйте, Ночной Смотрящий, Вы писали:

I>>Кстати говоря, await можно перепилить на колбеки и всунуть это в таски.

НС>Чего, простите?

Того. Ты в курсе, что await это просто сахар ?

I>> Интересно, как ты в этом случае будешь выкручиваться.

НС>А почему я должен выкручиваться?

Ну это не я асинхронщину реализую через Thread.Sleep()

Здравствуйте, Ночной Смотрящий, Вы писали:

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

Ты все еще забыл что речь про асинхронщину, например IOCP. Кооперативная многозадачность именно отсюда и растет. Просто потому, что иначе и способа другого нет — ты явно передаешь управление другому потоку, например шедулеру, или OС и тд и тд.

>Более того, по факту и для CPU bound и для IO bound задач никакой кооперативной многозадачности нет, используются механизмы ОС напрямую с многозадачностью вытесняющей.

Ну и цырк. А сигналы от таймера, пудозреваю, ты собираешься заменить на Thread.Sleep ?

Вобщем, я привел код — покажи где там вытесняющая многозадачность. Ткни пальцем. Начни с Task.Delay

I>>То есть, в кратце, тебе надо пояснить, как будет работать в тасках асинхронный код навроде IOCP или таймера того же.

НС>Не понимаю вопроса. Он будет работать ровно так же, как и без тасков.

Я смотрю ты все время что не понимаешь. Объясняю еще раз — IOCP это асинхронщина в чистом виде. Это, например, может быть вот так
операция 1 зашедулилась
операция 2 зашедулилась
операция 2 выполнилась
операция 1 выполнилась

Вот это IOCP, гарантии тебе никто не даст, что операции сохранят последовательность выполнения.

Тперь фокус, синхронный вариант, см мой JS

write(++read())

Предположим, поток ровно один. write затирает то значение, которое только что прочёл read. Инвариант такой.
Это понятно или надо объяснять ?

операция 1 чтение
операция 1 запись
операция 2 чтение
операция 2 запись

а теперь, внезапно, это становится асинхронным. Какой будет порядок выполнения — а хрен его знает.
может и такой — 1 прочитал, 2 прочитал, 2 записал 1 записал, опаньки, вторая запись затирает совсем не то значение, которое вернул её read

Здравствуйте, Ночной Смотрящий, Вы писали:

I>>покажи, как же таска владеет потоком монопольно.

НС>Я тебе уже наглядно продемонстрировал это. И, на всякий случай, никакого эвентлупа там нет, это консольное приложение.

Ты ничего не показал. У меня код который демонстрирует проблемы. А твой код делает фигню.

НС>Никаких подозрений не появилось?

Нет. Если тебе непонятно, что делает мой код, так и говори.

I>>Неудивительно. await, yield — это прямое указание прерывания текущей задачи

НС>Спасибо, КО. Только при чем тут таски?

Таски умеют работать вот таким вот способом. И этот способ ничем не отличается от того, как работают зеленые потоки.

>Это те самые продолжения, о которых я которое уже письмо твержу. Которые могут быть в том числе и при помощи зеленых потоков реализованы. И которые зелеными потоками не являются, и в современном шарпе реализованы тоже без них.

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

НС>Что значит "прикрутить к потоку IOCP или таймер" (системный таймер, кстати, тоже через IOCP обычно используют)? И как IOCP в тасках работает в консольном или веб приложении, где никаких эвентлупов нет?

А кто тебе сказал, что там нет эвентлупов ? Ты почти любую функцию дернешь и он сам появится.
Можешь на таймерах проверить. Если он зависнет, значит эвентлупа точно нет

Главное с thread.sleep не перепутай

Здравствуйте, Ikemefula, Вы писали:

НС>>Я тебе уже наглядно продемонстрировал это. И, на всякий случай, никакого эвентлупа там нет, это консольное приложение.
I>Ты ничего не показал. У меня код который демонстрирует проблемы. А твой код делает фигню.

А, ну ну. Тогда объясни его вывод с учетом твоей теории про один поток и эвентлуп.

НС>>Никаких подозрений не появилось?
I>Нет.

I> Если тебе непонятно, что делает мой код, так и говори.

Мне неинтересен твой код, потому что код нужен предельно простой.

I>>>Неудивительно. await, yield — это прямое указание прерывания текущей задачи
НС>>Спасибо, КО. Только при чем тут таски?
I>Таски умеют работать вот таким вот способом.

Нет. Это целиком фича компилятора. Таски ничего подобного не делают.

I> И этот способ ничем не отличается от того, как работают зеленые потоки.

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

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

Есть. Достаточно посмотреть на IL.

НС>>Что значит "прикрутить к потоку IOCP или таймер" (системный таймер, кстати, тоже через IOCP обычно используют)? И как IOCP в тасках работает в консольном или веб приложении, где никаких эвентлупов нет?
I>А кто тебе сказал, что там нет эвентлупов ?

Я тебе сказал.

I> Ты почти любую функцию дернешь и он сам появится.

Продемонстрируй на том примере, что я привел.

I>Можешь на таймерах проверить. Если он зависнет, значит эвентлупа точно нет

Ты про который таймер? Который винформсный что ли?

Здравствуйте, Ночной Смотрящий, Вы писали:

N>>"С точки зрения тасков" это вообще долгая задача.
НС>Шо, с любым значением параметра?

В общем-то да, а что удивляет? Любая дополнительная задержка — помеха этому механизму. Даже вызов типа sleep(0), который в куче мест значит yield(), откладывает завершение задачи и освобождение исполняющей нити.
На практике, конечно, можно полагаться на кратковременность некоторых задержек типа чтения из файла на локальном диске, но всё равно можно помнить, что это хак. Особенно если такой пул один на весь процесс.

N>>>> Это чистое IO, и эффект от него такой же, как если бы задача сделала блокирующий read().
НС>>>Ну так не надо делать блокирующий read.
N>>О! Что и требовалось показать.
НС>Зачем тебе потребовалось эту очевидность показать?

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

В начале этой субветки меня заинтересовала фраза Ikemefula@ "Таски и есть легкие потоки". Её можно было понять разными вариантами. Например, очевидная экономия на создании и удалении нитей (которые обычно сильно дороже взятия готовых из пула). Работой поверх волокон (fibers) или местной реализации зелёных нитей. Явной подпоркой от компилятора (как уже убедились в основном по твоим рассказам, это случай не TPL, а async/await). Выбор между этими вариантами интересен с точки зрения "посмотреть, как же они делают", но для начала надо было продраться через перекосы стилей описания.
Сейчас я вижу, что скорее всего он ошибся ("таски" работают поверх обычных нитей, блокирующие вызовы не отлавливаются, поддержка компилятора не у них, а у async/await). Я правильно понял картину?
Если да, то сейчас самое интересное мне это можно ли оба механизма (что TPL, что async/await) регулировать: какая группа нитей их исполняет; какое управление пулом, особенно в маргинальных случаях типа "все нити заняты, а надо ещё что-то делать"; возможны ли клинчи (deadlocks) механизма управления; как это сочетается с сериализацией доступа к данным; и ещё много подобных вопросов.

НС>Честные ветки никуда не делись. А зеленые на Thread.Sleep прореагируют точно так же, как и TPL.

То есть зелёные у вас не умеют ловить блокирующие вызовы, понятно. А о какой именно их реализации ты говоришь в данном случае? Fibers?

НС>Еще раз, по буквам, уж не знаю как еще объяснить — таски вообще никак не связаны с кооперативной многозадачностью, абсолютно. Они обеспечивают эффективную реализацию fine grained параллелизма с удобным API, и все. А все игры с await — совсем другая механика.

Вот опять ты понимаешь термин "кооперативная многозадачность" в крайне узком и странном смысле. Я не вижу причин так сужать в принципе; для меня кооперативная многозадачность это когда нужно явно писать код в стиле "я хочу сейчас отдать управление". Это же соответствует википедии: "Тип многозадачности, при котором следующая задача выполняется только после того, как текущая задача явно объявит себя готовой отдать процессорное время другим задачам" и многим другим источникам. По этому определению async/await вообще не механизм кооперативной многозадачности: никто не обязывает его делать через неё; никто не обязывает при await отдавать управление (а может, результат уже готов? тогда его можно сразу и забрать). А вот то, что в пределах "тасков" рекомендуется не делать никаких блокирующих действий, а выносить их отдельно и/или пользоваться всеми этими APM и EAP — делает их ближе к тому, что под кооперативной многозадачностью понимает большинство.

N>>Это, действительно, слишком грубое объяснение. Потому что не покрывает даже вход в асинхронный контекст — вызов async функции из синхронного кода.
НС>А почему оно должно его покрывать? Это личное дело контекста.

Я про то, что покрывает объяснение, а не выполнение

НС> И контекст, в том числе, может вообще ничего не делать.

Ну что-то он таки делает. Как мы убедились по соседнему твоему сообщению, оба async метода стартовали в отдельных тредах. Это значит (вполне логично), что вызывающий не-async метод не подпадает под описанный тобой подход "разрезать на части, пригодные для включения в FSM управления".

N>> Если компилятор не опознаёт, что здесь идёт вызов именно async функции, то вся эта кусочно-гнездовая развесистость может быть только в отдельных нитях, а если опознаёт (например, по типу возврата Task) — то нужно ли было вводить слово async для таких методов?
НС>Во-первых компилятор ничего не опознает, он делит код строго по await и никак иначе.

А что в таком случае происходит при вызове методов типа XxxAsync()? Для полной реализации механизма ожидаемо, что там может переключаться управление на код запускаемого метода до момента, когда тот уйдёт в блокировку. А вместо этого мы видим категорическое использование отдельной нити. Как-то странно получается.

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

Ссылку, plz.

N>>Далее, я не вижу, чтобы описывался какой-то интеллект по выходу за пределы этого в случае внешних работ
НС>А он там должен быть?

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

N>>. То есть получается какой-то "домен" асинхронного выполнения, который не имеет чёткого синтаксического отделения от основного. В первую очередь это проблема с библиотеками. Могут ли библиотечные функции блокироваться в таком случае? Если нет, то как им это гарантированно запретить и что делать с такими попытками?
НС>Если честно, не очень понял вопросы.

Ну ответь по поводу типовых проблем абзацем выше, тогда вернёмся.

N>>А есть ли средство аккуратной привязки контекста к месту исполнения (такого, как TLS в тредах), или надо тащить все параметры за собой?
НС>Оно к TLS и привязывается, ничего никуда тащить не надо.

Как привязывается? Async метод наследует TLS вызывающего?

N>>А как писать своими средствами все эти ReadFileAsync()?
НС>Исходники в большинстве случаев доступны. Там все тривиально. Вот пример:
НС>public Task<byte[]> DownloadDataTaskAsync(Uri address)
[...]
НС> try { DownloadDataAsync(address, tcs); }
Сепульки — это для сепуления.
НС>DownloadDataAsync работает через IOCP.

Вот именно как он "работает через IOCP" и было интересно. Есть примеры реализации?

Здравствуйте, Ночной Смотрящий, Вы писали:

I>>Ты ничего не показал. У меня код который демонстрирует проблемы. А твой код делает фигню.

НС>А, ну ну. Тогда объясни его вывод с учетом твоей теории про один поток и эвентлуп.

Сначала ты объясни что в моем коде, я уже жду этого два дня, а потом я посмотрю твой код.

I>> Если тебе непонятно, что делает мой код, так и говори.

I>>Таски умеют работать вот таким вот способом.

НС>Нет. Это целиком фича компилятора. Таски ничего подобного не делают.

await это просто сахар, подумай головой. До введения await можно было написать ровно то же.

НС>Отличается. Зеленые потоки честно сохраняют стек и стейт процессора при переключении, а продолжения преобразуют код в FSM, где код режется на куски. Ничего общего, кроме конечной цели.

Ага, зеленые потоки это какая то магия

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

НС>Есть. Достаточно посмотреть на IL.

Нужны качественные отличия, а не другой IL

I>>А кто тебе сказал, что там нет эвентлупов ?

НС>Я тебе сказал.

Тест на таймере говорит что ты приврал малёк.

I>> Ты почти любую функцию дернешь и он сам появится.
НС>Продемонстрируй на том примере, что я привел.

I>>Можешь на таймерах проверить. Если он зависнет, значит эвентлупа точно нет

НС>Ты про который таймер? Который винформсный что ли?

Раскрой, наконец, глаза.

Здравствуйте, Ночной Смотрящий, Вы писали:

I>> Если тебе непонятно, что делает мой код, так и говори.

НС>Мне неинтересен твой код, потому что код нужен предельно простой.

Там и есть предельно простой код — запускается несколько асинхронных операций одновременно.
Что может быть проще — не ясно

В кратце — мой пример требует примерно вот такое решение

lock(sync)
{
  var x = await ReadAsync();
  await Write(++x);
}

Но, как ты в курсе, lock нельзя использовать в этом контексте, а в TPL нет примитивов синхронизации для асинхронного кода

Парадокс — асинхронный код писать можно, а асинхронных примитивов синхронизации нет

Теперь про IOCP — все проблемы один к одному распространяются на асинхронщину через IOCP.

Пока одна операция в шедулере, паралельная может даже успеть отработать. Что будет с разделяемым ресурсом — не ясно.

Здравствуйте, netch80, Вы писали:

I>>Внезапно, даже в однопоточной модели возникают гонки в силу кооперативной многозадачности. В зеленых потоках эту проблему проще контролировать.

N>Почему проще?

Проще в сравнении с олдскульным APM и всяким колбеками, точнее способом их реализации в том же дотнете например.

Вот например есть такая хрень

// чтение-запись с разделяемым ресурсом
lock(sync) {
  var x = await ReadAsync();
  await WriteAsync(Modify(x));
}

Сейчас нет возможности вставить lock. Отсюда получается фокус — разделяемый ресурс есть, а как с ним внятно работать, надо еще подумать.

В зеленом потоке нет никакой проблемы реализовать этот lock, без разницы, что унутре зеленого потока — continuation или coroutine.

Собственно, в тасках это тоже реализуемо, http://blogs.msdn.com/b/pfxteam/archive/2012/02/12/10266988.aspx

Все это, естественно, для асинхронного кода. Для Thread.Sleep это не нужно

Собственно меня сильно смущает, что в тасках реализовали всё подряд, а вот простую асинхронную модель как то забыли поддержать.

Здравствуйте, netch80, Вы писали:

N>В условиях, когда один из собеседников (ты) понимает и применяет термины

Традиционно ты скатился на спор о терминах. Дальше без меня.

N>Сейчас я вижу, что скорее всего он ошибся ("таски" работают поверх обычных нитей, блокирующие вызовы не отлавливаются, поддержка компилятора не у них, а у async/await). Я правильно понял картину?

Да.

N>Если да, то сейчас самое интересное мне это можно ли оба механизма (что TPL, что async/await) регулировать: какая группа нитей их исполняет; какое управление пулом, особенно в маргинальных случаях типа "все нити заняты, а надо ещё что-то делать";

Да.

N> возможны ли клинчи (deadlocks) механизма управления;

Да.

N> как это сочетается с сериализацией доступа к данным;

Перпендикулярно.

N> и ещё много подобных вопросов.

Задавай.

N>Я про то, что покрывает объяснение, а не выполнение

Зачем в объяснении общих механизмов включать переменную специфику?

N>Ну что-то он таки делает.

В консольных приложениях — ничего.

N>Это значит (вполне логично), что вызывающий не-async метод не подпадает под описанный тобой подход "разрезать на части, пригодные для включения в FSM управления".

Очевидно, раз там await отсутствует. При чем тут контекст?

N>А что в таком случае происходит при вызове методов типа XxxAsync()?

Что угодно. В случае IOCP просто создается операция и возвращается TaskCompletionSource, завязанная на колбек.

N>А вместо этого мы видим категорическое использование отдельной нити. Как-то странно получается.

Ничего странного, если внимательно читать то что я пишу.

N>Ссылку, plz.

http://blogs.msdn.com/b/visualstudio/archive/2011/02/07/8-part-async-series-by-eric-lippert.aspx

В какой конкретно части речь про модификатор async я не помню.

N>По-нормальному они должны быть все адресованы, проговорены, продуманы и описаны, включая типовые решения.

Многое из этого там присутствует, в управляющих механизмах TPL много всяких интересных алгоритмов. Но это уже детали, которые в контексте данного разговора нет смысла обсуждать. Интересно — можешь сам покопаться, информации в инете полно.

N>>>А есть ли средство аккуратной привязки контекста к месту исполнения (такого, как TLS в тредах), или надо тащить все параметры за собой?
НС>>Оно к TLS и привязывается, ничего никуда тащить не надо.
N>Как привязывается? Async метод наследует TLS вызывающего?

Да. Либо можно явно привязать/отвязать.

N>Сепульки — это для сепуления.

Что тебе непонятно? Код тривиальный.

НС>>DownloadDataAsync работает через IOCP.
N>Вот именно как он "работает через IOCP" и было интересно.

А это уже за пределами TPL, это старый древний код еще из первой версии фреймворка.

N> Есть примеры реализации?

public void DownloadDataAsync(Uri address, object userToken)
{
        if(Logging.On)Logging.Enter(Logging.Web, this, "DownloadDataAsync", address);
        if (address == null) 
                throw new ArgumentNullException("address");
        InitWebClientAsync();
        ClearWebClientState();
        AsyncOperation asyncOp = AsyncOperationManager.CreateOperation(userToken);
        m_AsyncOp = asyncOp;
        try {
                WebRequest request = m_WebRequest = GetWebRequest(GetUri(address));
                DownloadBits(request, null, new CompletionDelegate(DownloadDataAsyncCallback), asyncOp);
        } catch (Exception e) {
                if (e is ThreadAbortException || e is StackOverflowException || e is OutOfMemoryException) {
                        throw;
                }
                if (!(e is WebException || e is SecurityException)) {
                        e = new WebException(SR.GetString(SR.net_webclient), e);
                }
                DownloadDataAsyncCallback(null, e, asyncOp);
        }
        if(Logging.On)Logging.Exit(Logging.Web, this, "DownloadDataAsync", null);
}

...

private byte[] DownloadBits(WebRequest request, Stream writeStream, CompletionDelegate completionDelegate, AsyncOperation asyncOp) {
        WebResponse response = null;
        DownloadBitsState state = new DownloadBitsState(request, writeStream, completionDelegate, asyncOp, m_Progress, this);

        if (state.Async) {
                request.BeginGetResponse(new AsyncCallback(DownloadBitsResponseCallback), state);
                return null;
        } else {
                response = m_WebResponse = GetWebResponse(request);
        }

        bool completed;
        int bytesRead = state.SetResponse(response);
        do {
                completed = state.RetrieveBytes(ref bytesRead);
        } while (!completed);
        state.Close();
        return state.InnerBuffer;
}

BeginGetResponse — unmanaged метод, создает IOCP порт на сокет и вешает на него колбек из AsyncCallback. Все тривиально, что ты пытаешься найти мне до сих пор непонятно.
Ну и код захвата контекста, раз уж он тебя интересует:

AsyncOperation asyncOp = AsyncOperationManager.CreateOperation(userToken);

Если контекст не позволяет многопоточного исполнения, то колбек отмаршалится тем или иным способом в основной поток.

НС>AsyncOperation asyncOp = AsyncOperationManager.CreateOperation(userToken);
НС>

НС>Если контекст не позволяет многопоточного исполнения, то колбек отмаршалится тем или иным способом в основной поток.

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

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

Здравствуйте, Ikemefula, Вы писали:

I>Вот здесь и начаинается самое интересное

Оно может и начинается, только это старый добрый дотнет 2.0, а никак не таски.

I> — в силу этой асинхронщины две операции могут поменяться местами и это даст обычные гонки.

Могут.

I>То есть, в кратце, таски обязаны поддерживать кооперативную многозадачность.

Нет.

Здравствуйте, Ночной Смотрящий, Вы писали:

I>>Вот здесь и начаинается самое интересное

НС>Оно может и начинается, только это старый добрый дотнет 2.0, а никак не таски.

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

I>> — в силу этой асинхронщины две операции могут поменяться местами и это даст обычные гонки.

НС>Могут.

Итого:

Ты получил ответ на свой вопрос

НС>А что там такого извратного?

В кратце — асинхронная цепочка в таком вот стиле это АДЪ.

I>>То есть, в кратце, таски обязаны поддерживать кооперативную многозадачность.

НС>Нет.

См. свой ответ выше "это старый добрый дотнет 2.0"

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

Здравствуйте, netch80, Вы писали:

N>См. мой предыдущий ответ. С тасками названного тобой образца заполнение всех нитей ожиданием I/O заблокирует пул в целом.
Неа, 1 поток связан с кучей IOCP, по 1 потоку на ядро процессора, по умолчанию продолжение выполняется в отдельном потоке пула (но если хочется извратиться — никто не мешает).

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

N>Более того, ожидание чего-то через Task.Wait() может дать такой же результат, если нет свободных нитей, и поставленная в очередь задача не может из-за этого выполниться. Если егойный task manager решает это временным порождением новых нитей, то это грязный хак, не отменяющий порочность механизма (и ещё неизвестно, сколько ему надо, чтобы понять ситуацию). Если же он в состоянии при любом переходе исполняющей нити в ожидание переключать эту нить на другую задачу — то фактически мы имеем подложкой под task manager — не OS threads, а green threads.

Тут путаница

Task.Wait() — это не ожидание, это блокировка текущего потока до завершения задачи. Чтобы продолжить выполнение асинхронно, по завершению задачи используется Task.ContinueWith() или await. В этом случае никаких блокировок не будет.

Если речь про ожидание завершения внутри самой задачи, то как правило оно перекидывается на само API фреймфорка (которое в итоге работает через всё те же IOCP). Другими словами: если у класса есть async-API, то он не должен его реализовывать через блокирующие операции. Именно по той причине, что ты написал выше.

N>(BTW, что такое "вижла"? Visual Studio или что-то другое? я вашего жаргона не знаю)
Это лучше у Ikemefula спросить, из контекста — да, Visual Studio.

S>>В тасках ровно одна модель. За неё прячется практически что угодно — от обычных потоков до акторов и динамического раскидывания вызовов по кластеру. Только не надо начинать за "это всё не нужно"

N>Мнэээ... там таки есть гарантия, что спящая в ожидании задача освободит тред, или нет?
Угу. Если конечно автор кода не расставил блокировок по вкусу.

I>>>Таски нельзя отладить — речь была про APM-модель. Будет гаранировано АДЪ. Собственно, с тасками у микрософта пока что не сильно лучше.
S>>Ты 100% не использовал Parallel Stacks Window. Т.е. с тасками по сути не работал, о чём и было сказано выше. Про отладку в VS 1013 с поддержкой awiat и прочих плюшек даже начинать не буду.
N>Простите, а с каких это пор неиспользование возможности _отладчика_ для "тасков" означает неработу с ними "по сути"?

Task list + Stacks Window — первое, что упоминается в документации по отладке для тасков. Ну и в студии в режиме отладки Task list — на самом видном месте, не заметить сложно.

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

Здравствуйте, Ночной Смотрящий, Вы писали:

N>>В условиях, когда один из собеседников (ты) понимает и применяет термины
НС>Традиционно ты скатился на спор о терминах. Дальше без меня.

Это закономерно в подобных ситуациях, потому что у MS является традицией использовать термины в понимании "чуть не так", чем по остальным участникам отрасли. После этого любой спор о потрохах приводит к тому, что приходится выяснять, что же имелось в виду. И тут оказывается, что "таски" это не задачи, а конкретная TPL; "асинхронное" это не асинхронное вообще, а конкретно async+await; и тэ дэ и тэ пэ. На то, чтобы вернуть всё на место на свои ноги, требуются время и усилия.

В любом случае я буду формулировать вопросы по мере поступления времени и настроения, а вот будешь ли ты на них отвечать и как именно отвечать — посмотрим

N>>Если да, то сейчас самое интересное мне это можно ли оба механизма (что TPL, что async/await) регулировать: какая группа нитей их исполняет; какое управление пулом, особенно в маргинальных случаях типа "все нити заняты, а надо ещё что-то делать";
НС>Да.

Что именно "да"? Я тут задал минимум два вопроса.

N>>Я про то, что покрывает объяснение, а не выполнение

НС>Зачем в объяснении общих механизмов включать переменную специфику?

Так ты ж уже начал её рассказывать, при том, что у тебя не было сказано, что это "переменная специфика". И тут же в твоём примере оказалось, что оно работает заметно иначе, чем можно было бы предположить из прямого понимания твоего описания. Ты описывал про "разрезание" кода на части, переключающиеся как FSM под крышей общего шедулера. И тут оказывается, что в простейшем примере оба(!) два запущенных async-метода выполняются в отдельных нитях, не совпадающих с главной нитью. Если бы ты сказал "компилятор имеет право разрезать, а имеет — просто вынести в отдельные нити, в пул, etc. и ждать результата через стандартную синхронизацию; считайте, что он умеет выбирать оптимальный метод" — было бы честнее и проще. Но ты этого не говоришь.

N>>Ну что-то он таки делает.
НС>В консольных приложениях — ничего.

В чём тут принципиальность отличия консольных приложений от других?
В консольных не может быть асинхронных событий? А почему собственно?
С другой стороны, чем не-консольные приложения (а какие? flat GUI? WPF? что-то иное?) отличаются? Там можно реагировать через K секунд на нажатие кнопки?

N>>Это значит (вполне логично), что вызывающий не-async метод не подпадает под описанный тобой подход "разрезать на части, пригодные для включения в FSM управления".
НС>Очевидно, раз там await отсутствует. При чем тут контекст?

Теперь тебе это "очевидно". Хотя объяснял ты совершенно иначе.

N>>Ссылку, plz.
НС>http://blogs.msdn.com/b/visualstudio/archive/2011/02/07/8-part-async-series-by-eric-lippert.aspx

Вода мутная, одна штука. Очень мало внятных подробностей. С другой стороны, есть явно противоречащие вещи: "The whole point of async methods it that you stay on the current thread as much as possible." из "Whence await?" не согласуется с запуском первого async метода в отдельной нити.

N>>По-нормальному они должны быть все адресованы, проговорены, продуманы и описаны, включая типовые решения.
НС>Многое из этого там присутствует, в управляющих механизмах TPL много всяких интересных алгоритмов. Но это уже детали, которые в контексте данного разговора нет смысла обсуждать. Интересно — можешь сам покопаться, информации в инете полно.

Это ты про TPL. А про async/await? Ничто же формально не мешает запустить через async миллион работ типа "проверить живость вот такого URL".

N>>>>А есть ли средство аккуратной привязки контекста к месту исполнения (такого, как TLS в тредах), или надо тащить все параметры за собой?
НС>>>Оно к TLS и привязывается, ничего никуда тащить не надо.
N>>Как привязывается? Async метод наследует TLS вызывающего?
НС>Да. Либо можно явно привязать/отвязать.

Явно — это неинтересно, а вот наследование TLS при возможности реального исполнения в другой нити... что-то в этом есть парадоксальное.

НС>public void DownloadDataAsync(Uri address, object userToken)
[...]
НС> if (state.Async) {
НС> request.BeginGetResponse(new AsyncCallback(DownloadBitsResponseCallback), state);

Ага, вот и оно. То есть старые методы, которые вроде бы deprecated, никуда не делись и их просто завернули в обёртки. Спасибо.
Тогда ещё один вопрос. Зачем ко всяким BeginRead, BeginWrite обязательно парные EndRead, EndWrite и так далее, а не просто EndIO?

НС>BeginGetResponse — unmanaged метод, создает IOCP порт на сокет
~~~~~~~~~
О'кей, тут механика понятна.

НС> Все тривиально, что ты пытаешься найти мне до сих пор непонятно.

Ну за неимением опыта с данной платформой я не знаю, как формулировать поисковые запросы. Но на сейчас результат понятен.
Жаль, что работа с IOCP сделана unmanaged. Подозреваю, что её честный вынос на managed уровень дал бы возможность делать не менее удобные штуки своими силами, без маскирующего и местами запутывающего слоя.

Здравствуйте, netch80, Вы писали:

S>> Запрос инициируется с рабочего потока, запихивается в очередь iocp, по завершению — продолжает выполнение в потоке из IOCP-пула. Кооперативной многозадачности тут нет: обработчики iocp будут выполняться параллельно вплоть до исчерпания пула потоков.

N>Не-а. Всё описанное тобой получается только в случае если ты сам, явно, определишь какой-то "пул" ниток, которые не будут делать ничего кроме как дёргать GetQueuedCompletionStatus(); но это будет _твоё_, как разработчика, решение. В то же время, если ты сделаешь в одной нити
N>* создание IOCP
N>* создание и связь с этим IOCP некоторых начальных генераторов событий, типа слушающего сокета
N>* цикл типа "пока не приказали посинеть" из ожидания события и его обработки, включая помещение новых асинхронных операций с оповещением через тот же IOCP объект

Ну, т.е. разработаю свой пул для тасков с 0, причём пул, заточенный под обработку кучи очень коротких (или редких) сообщений (иначе забьётся нафиг)

Мы там выше говорим за стандартную реализацию в .NET, не про сфероконей.

Кстати, я там слишком сильно упростил — по умолчанию потоки для IOCP запускают продолжение завершившейся задачи в потоке из "нормального" пула. Именно чтобы не засорять iocp

N>у тебя получится ровно то, что говорит Ikemefula: "асинхронщина" через кооперативную многозадачность собственного исполнения. При этом ничто не мешает сделать несколько таких нитей и распределить работу между ними (например, раскидывая входящие соединения), каждую привязывать к своему IOCP.
Угу, нечто типа эвентлупа com/winforms. В принципе, можно, но в общем случае работать будет хуже, чем готовые таски.

N>А если не ограничиваться одной нитью, то всё равно получается "асинхронщина", но уже с усложнением (синхронизация доступа к общим ресурсам и т.п.)
Угу. Поэтому в tpl обычно не используют обшие изменяемые ресурсы, или запускают задачи, работающие с этим ресурсом через отдельный шедулер. Который и рулит блокировками или тупо запускает все задачи в одном потоке (тут в теории всплывают грабли с реэнтерабельностью, на практике они сами собой разруливается через всё тот же .ContinueWith()).

Здравствуйте, Sinix, Вы писали:

N>>См. мой предыдущий ответ. С тасками названного тобой образца заполнение всех нитей ожиданием I/O заблокирует пул в целом.
S>Неа, 1 поток связан с кучей IOCP,

Я сразу перебью тут — _как_? Насколько я вижу по докам, GetQueuedCompletionStatus[Ex] позволяет ждать события одновременно только с одного IOCP. Вариант "перебирать все в цикле" без ожидания, понятно, не устраивает.

Вообще, перечитав доку, я перестал понимать логику организации IOCP. В его юниксовых аналогах, привычных мне (kqueue, epoll) операция добавления ожидания к конкретному экземпляру IOCP выполняется явно, исключения — допустима и тоже явно, и есть явная заточка дизайна на 1 IOCP (kqueue, etc.) на нить. В случае виндового IOCP мы имеем CreateIoCompletionPort(), которая явно рассчитана на создание персонального IOCP каждому хэндлу (вариант присербиться к готовому выглядит как добавленный потом и сбоку), а убрать связь хэндла с IOCP нельзя вообще. Перебросить на другой — вероятно, тоже. То ли доки тут откровенно что-то недоговаривают, то ли этот механизм очень негибкий. (Про возможность асинхронных операций без явного IOCP я вообще не вспоминаю.)

S> по 1 потоку на ядро процессора, по умолчанию продолжение выполняется в отдельном потоке пула

Это если ты явно, сидя в задаче под TPL, заказываешь продолжение. Если же ты пытаешься делать блокирующую операцию (например, неявно, вследствие вызова библиотечной функции), нить будет ждать. Это мы с НС уже выяснили.

S>Чему там блокироваться? И при чём тут кооперативная многозадачность? Напомню, ув Ikemefula вторую страницу рассказывает, как по его мнению устроены таски, исходя из убеждения, что таски === зелёные потоки, только плохо написанные.

Ну вот я и пытался выяснить, что же именно он хочет сказать.
А "чему блокироваться" — повторяю: вызывая написанный не тобой код, ты в общем случае не знаешь, на что он способен и почему. Более того, есть обычные (хотя игнорируемые) случаи такой блокировки даже с твоим на 146% кодом, начиная с page fault при его исполнении. Да, с таким явным образом что-то сделать нельзя (частично можно оптимизировать работу VM через madvise() с аналогами), можно полагаться на статистические характеристики. Или можно явно это использовать — в Unix до появления sendfile() было стандартным приёмом в отдельной нити замапить файл в память и делать длинный write() в сокет; в отдельной — потому что страничные фолты блокируют нить.
Но даже без таких случаев можно нарваться на блокировки в совершенно неожиданном месте.

S>Тут путаница

Task.Wait() — это не ожидание, это блокировка текущего потока до завершения задачи. Чтобы продолжить выполнение асинхронно, по завершению задачи используется Task.ContinueWith() или await. В этом случае никаких блокировок не будет.

await дружит с TPL? При входе в ожидание по await движок TPL способен переключить на другую задачу?

S>Если речь про ожидание завершения внутри самой задачи, то как правило оно перекидывается на само API фреймфорка (которое в итоге работает через всё те же IOCP). Другими словами: если у класса есть async-API, то он не должен его реализовывать через блокирующие операции. Именно по той причине, что ты написал выше.

Ну опять же НС уже написал — что "внутре" там работа с IOCP через BeginXXX(), которые unmanaged. Что достаточно обидно. Вынести доступ к IOCP на верхний уровень могло дать результат не хуже.

N>>Простите, а с каких это пор неиспользование возможности _отладчика_ для "тасков" означает неработу с ними "по сути"?
S>Task list + Stacks Window — первое, что упоминается в документации по отладке для тасков. Ну и в студии в режиме отладки Task list — на самом видном месте, не заметить сложно.

Ты не понял. Я не про то, что если использовать отладчик, то в нём использовать соответствующие средства. Я про само использование отладчика. Для моих задач, например, такое средство непригодно (отладка может идти только через debug print). Но это не мешает использовать полный комплект средств, аналогичных тем, что тут обсуждаются: тут и FSM, и IOCP (в виде epoll), и пулы нитей, исполняющих задачи. Соответственно и мой интерес это "а что новенького придумали коллеги из другого лагеря?"

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

См. мой предыдущий абзац. Ты постановил отладка == использование инструмента "отладчик". Верю, что в случае GUI это вполне допустимо. Но все ли задачи, даже в пределах .NET + async/await, это GUI? Я не соглашаюсь с ним, что "таски нельзя отладить" без уточнения деталей, как он их использует. Но твоё возражение не менее некорректно.

Здравствуйте, netch80, Вы писали:

N>>>Если да, то сейчас самое интересное мне это можно ли оба механизма (что TPL, что async/await) регулировать: какая группа нитей их исполняет; какое управление пулом, особенно в маргинальных случаях типа "все нити заняты, а надо ещё что-то делать";
НС>>Да.
N>Что именно "да"? Я тут задал минимум два вопроса.

Можно регулировать в определенной степени. Подробности, извини, пересказывать не буду — это есть в МСДН.

N>>>Я про то, что покрывает объяснение, а не выполнение

НС>>Зачем в объяснении общих механизмов включать переменную специфику?
N>Так ты ж уже начал её рассказывать

Нет.

N>Ты описывал про "разрезание" кода на части, переключающиеся как FSM под крышей общего шедулера.

Так и есть.

N> И тут оказывается, что в простейшем примере оба(!) два запущенных async-метода выполняются в отдельных нитях

Именно это я и хотел продемонстрировать. Потому что в примере демонстрируются не продолжения, а именно TPL и то как он работает с IOCP. А вот почему ты из специально написанного для этого примера хочешь получить характеристики совсем другого механизма — мне непонятно.
Если ты хочешь увидеть преобразование кода и кооперативную многозадачность на базе этого — нужен другой пример.

N>Если бы ты сказал "компилятор имеет право разрезать, а имеет — просто вынести в отдельные нити, в пул, etc. и ждать результата через стандартную синхронизацию;

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

N>>>Ну что-то он таки делает.
НС>>В консольных приложениях — ничего.
N>В чём тут принципиальность отличия консольных приложений от других?

Разные контексты в TLS по умолчанию.

N>В консольных не может быть асинхронных событий?

В консольных нет ограничений по взаимодействию потоков с основным.

N>С другой стороны, чем не-консольные приложения (а какие? flat GUI? WPF? что-то иное?) отличаются?

Конструкторы винформсных и wpf контролов устанавливают специальный контекст синхронизации в TLS.

N> Там можно реагировать через K секунд на нажатие кнопки?

Там нельзя трогать кнопки из потоков, отличных от основного. Защита от дурака.

НС>>http://blogs.msdn.com/b/visualstudio/archive/2011/02/07/8-part-async-series-by-eric-lippert.aspx

N>Вода мутная, одна штука.

Это у Липперта то мутная вода? Тебе не угодишь. Вообще то это он пишет на редкость понятно, просто у тебя, скорее всего, не хватает базы для шарпа.

N>Это ты про TPL. А про async/await?

А async/await — довольно примитивная и детерминированная штука, никакого интеллекта там нет.

N>>>Как привязывается? Async метод наследует TLS вызывающего?
НС>>Да. Либо можно явно привязать/отвязать.
N>Явно — это неинтересно, а вот наследование TLS при возможности реального исполнения в другой нити... что-то в этом есть парадоксальное.

На практике вполне нормально. И применялось задолго до появления TPL, механизм контекстов синхронизации с версии 2.0 присутствует.

N>Ага, вот и оно. То есть старые методы, которые вроде бы deprecated

Кто сказал, что они deprecated?

N>, никуда не делись и их просто завернули в обёртки. Спасибо.

Я именно об этом с самого начала пишу — для IO bound используются совершенно обычные IOCP.

N>Тогда ещё один вопрос. Зачем ко всяким BeginRead, BeginWrite обязательно парные EndRead, EndWrite и так далее, а не просто EndIO?

Чтобы почистить неуправляемые ресурсы, если они там есть. Например чтобы позвать CloseHandle для хендла IOCP.

НС>>BeginGetResponse — unmanaged метод, создает IOCP порт на сокет
N> ~~~~~~~~~
N>О'кей, тут механика понятна.

Он вполне может быть и managed, это ничего принципиально не меняет.

N>Жаль, что работа с IOCP сделана unmanaged.

Еще раз — это совершенно необязательно. Ты точно так же и с тем же результатом можешь позвать CreateIoCompletionPort из managed кода. Unmanaged тут исключительно для перформанса применен. Вот реализация из Моно, чисто managed — https://github.com/mono/mono/blob/master/mcs/class/System/System.Net/HttpWebRequest.cs.

Здравствуйте, netch80, Вы писали:

N>await дружит с TPL?

Он на него по умолчанию опирается.

N> При входе в ожидание по await движок TPL способен переключить на другую задачу?

"Вход в ожидание" не есть фича await, это как раз задача TPL. Так что ответ очевиден.

N>Ну опять же НС уже написал — что "внутре" там работа с IOCP через BeginXXX(), которые unmanaged.

Ничего подобного я не говорил. Я говорил строго про конкретный BeginGetResponse в МС реализации.

Здравствуйте, netch80, Вы писали:

S>>Неа, 1 поток связан с кучей IOCP,
N>Я сразу перебью тут — _как_? Насколько я вижу по докам, GetQueuedCompletionStatus[Ex] позволяет ждать события одновременно только с одного IOCP. Вариант "перебирать все в цикле" без ожидания, понятно, не устраивает.

Что-то я не то с утра ляпнул

Разбирался в реализации под .net года три назад, так скорее всего могу врать. Емнип — создаём для каждого потока в IOCP-пуле по одному порту + словарь <ключ-задача>, поток ждёт в лупе GetQueuedCompletionStatus, получает ключ, достаёт из словаря задачу, запускает на выполнение.

N>Вообще, перечитав доку, я перестал понимать логику организации IOCP. В его юниксовых аналогах, привычных мне (kqueue, epoll) операция добавления ожидания к конкретному экземпляру IOCP выполняется явно, исключения — допустима и тоже явно, и есть явная заточка дизайна на 1 IOCP (kqueue, etc.) на нить.

Вполне возможно. Поскольку мне низкоуровневые детали понадобятся только, если я соберусь писать свой iocp-пул с нуля, детально в нативном API IOCP не копался.
Если рассматривать с точки зрения api дотнета — "оно просто работает". Фиговый ответ конечно, но поднимать матчасть сейчас времени нет, сорри

S>> по 1 потоку на ядро процессора, по умолчанию продолжение выполняется в отдельном потоке пула
N>Это если ты явно, сидя в задаче под TPL, заказываешь продолжение.
N>Если же ты пытаешься делать блокирующую операцию (например, неявно, вследствие вызова библиотечной функции), нить будет ждать. Это мы с НС уже выяснили.
Угу. Но куча взаимоблокирующих операций на тасках — это изврат какой-то, я често не могу сообразить, зачем так может понадобится писать.

N>Ну вот я и пытался выяснить, что же именно он хочет сказать.
N>А "чему блокироваться" — повторяю: вызывая написанный не тобой код, ты в общем случае не знаешь, на что он способен и почему.
Угу, но это уже почти к любой реализации относится (экзотику со 100% статической верификацией кода не рассматриваем). По-моему, тут таски и зелёные потоки ничем принципиально отличаться не будут.

S>>Тут путаница

Task.Wait() — это не ожидание, это блокировка текущего потока до завершения задачи. Чтобы продолжить выполнение асинхронно, по завершению задачи используется Task.ContinueWith() или await. В этом случае никаких блокировок не будет.

N>await дружит с TPL? При входе в ожидание по await движок TPL способен переключить на другую задачу?
Да, конечно. await по сути — синтаксический сахар к Task.ContinueWith().

S>>Если речь про ожидание завершения внутри самой задачи, то как правило оно перекидывается на само API фреймфорка (которое в итоге работает через всё те же IOCP). Другими словами: если у класса есть async-API, то он не должен его реализовывать через блокирующие операции. Именно по той причине, что ты написал выше.
Угу.

N>Ну опять же НС уже написал — что "внутре" там работа с IOCP через BeginXXX(), которые unmanaged. Что достаточно обидно. Вынести доступ к IOCP на верхний уровень могло дать результат не хуже.
В теории никто не мешает написать свою реализацию шедулера, который будет обрабатывать таски через Get/PostQueuedCompletionStatus(). Зачем оно может понадобиться — не соображу.

S>>Task list + Stacks Window — первое, что упоминается в документации по отладке для тасков. Ну и в студии в режиме отладки Task list — на самом видном месте, не заметить сложно.
N>Ты не понял. Я не про то, что если использовать отладчик, то в нём использовать соответствующие средства. Я про само использование отладчика.
Тут ещё проще — на дотнете почти все программируют под студией (сотые доли процентов любителей emacs и проценты xamarin-а не рассматриваем). Разобраться с нуля с тасками, не запуская отладку, или не читая материалов по сабжу... ну, можно, но это ещё больший хардкор чем емакс наверно

Ну а раз читал/отлаживал, то говорить "Таски нельзя отладить" совсем странно)

N>Соответственно и мой интерес это "а что новенького придумали коллеги из другого лагеря?"
С технической точки зрения — абсолютно ничего, максимум подтюнили пул потоков под частое переключение задач. Но и тут используется классическая work-stealing queue, т.е. ничего нового.

С прикладной точки зрения MS протащили асинхронность почти через всё клиентское API в winrt и добавили в языки синтаксический сахар для максимально простого использования этой асинхронности. Может, я чего и путаю, но в мейнстримных языках я ничего подобного не припомню.

S>>Согласись, глупо слушать про "таски нельзя отладить" от человека, который с ними работать и не пытался

N>Но твоё возражение не менее некорректно.
Угу. Там уже сам спор скатывался в никуда — любое долгое объяснение раздёргивалось на цитаты и каждая до бесконечности обсасывалась. Чтоб не спорить — фиг с ним, отладить нельзя, ибо сказано

Здравствуйте, Ikemefula, Вы писали:

I>Собственно меня сильно смущает, что в тасках реализовали всё подряд, а вот простую асинхронную модель как то забыли поддержать.

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

Как полувременное решение, есть готовые third-party-решения, и твой пример можно решить через

using (await lockKey.LockAsync())
{
  var x = await ReadAsync();
  await WriteAsync(Modify(x));
}

, или через compare-exchange loop, типа вот такой.

впрочем, если к ресурсу будет обращаться только код выше (допустим, он обёрнут в while(true)), то LockAsync() не нужен — await гарантирует сохранение порядка выполнения. Как оказывается на практике — подход из цепочки await-ов прекрасно масштабируется: для параллельной обработки запускаем асинхронно специализированный таск, дожидаемся завершения через await, продолжаем цепочку.

А вот с той самой параллельной (конкурентной) обработкой на сегодня конь не валялся.
LockAsync — это слишком низкий уровень для TPL, утонем в взаимоблокировках. Чтобы хоть как-то обмануть Амдалла, нужно или раскидывать данные ко отдельным обработчикам (см PLinq, tpl dataflow, rx), или стараться использовать lock-free где это возможно (см System.Collections.Concurrent).

Удобный синтаксис наподобие await к этому зоопарку пока не прикручен по одной простой причине — пока непонятно, какую из конкурирующих моделей выбрать

От:	alexanderfedin	http://alexander-fedin.pixels.com/
Дата:	03.03.13 22:13
Оценка:

	От:	alxrie
	Дата:	04.03.13 03:35
	Оценка:	-1

	От:	IObserver
	Дата:	04.03.13 06:39
	Оценка:

От:	Ikemefula	http://blogs.rsdn.org/ikemefula
Дата:	04.03.13 07:11
Оценка:

От:	a_g_99	http://www.hooli.xyz/
Дата:	04.03.13 07:46
Оценка:	+2 -8

От:	Евгений Акиньшин	grapholite.com
Дата:	04.03.13 08:02
Оценка:

От:	xvost	http://www.jetbrains.com/company/people/Pasynkov_Eugene.html
Дата:	04.03.13 08:08
Оценка:

	От:	vladimir.vladimirovich
	Дата:	23.03.13 13:30
	Оценка:

От:	dimgel	https://github.com/dimgel
Дата:	26.03.13 15:04
Оценка:

От:	IT	linq2db.com
Дата:	22.04.13 15:19
Оценка:	17 (12) +5

	От:	Ночной Смотрящий
	Дата:	22.04.13 16:34
	Оценка:

От:	netch80	http://netch80.dreamwidth.org/
Дата:	25.04.13 04:21
Оценка:

От:	TK	кывт.рф
Дата:	25.04.13 12:43
Оценка:

	От:	Klikujiskaaan
	Дата:	30.04.13 17:49
	Оценка:	+2

От:	velkin	http://blogs.rsdn.org/effective/
Дата:	31.01.14 14:31
Оценка:	+1

	От:	Yoriсk
	Дата:	05.03.13 08:27
	Оценка:

	От:	Yoriсk
	Дата:	21.03.13 10:07
	Оценка:

	От:	Yoriсk
	Дата:	21.03.13 10:32
	Оценка:

	От:	loginx
	Дата:	21.03.13 10:33
	Оценка:

От:	koandrew	http://thingselectronic.blogspot.ca/
Дата:	31.01.14 15:51
Оценка:

	От:	Константин
	Дата:	10.02.14 14:01
	Оценка:	+1 -1

	От:	alex_public
	Дата:	13.02.14 13:24
	Оценка:	2 (1) +1