Здравствуйте, Sinix, Вы писали:
S>Такой вопрос: а как сейчас с CAL к winserver? Насколько я помню, варианта всего два или затариваться External Connector+per-cpu CAL, или надеяться что не заметят
Понятия не имею.
Если нам не помогут, то мы тоже никого не пощадим.
Re[11]: Зачем Майкрософту рубить сук, на котором он сидит?
Здравствуйте, neFormal, Вы писали:
IT>>серверные приложения должны иметь возможность работать на Линухе. F>всё правильно
Ничего правильного. Голимая отмазка. Ещё ни разу в жизни не видел ни одного приложения в корпоративной среде, которому была бы нужна многоплатформенность. Если вдруг нужно поменять платформу, то это в первую очередь означает, что приложение серьёзно больно и его не только будут переносить в другое место, но ещё и серьёзно лечить, т.е. скорее всего переписывать с нуля. А многоплатформенность в корпоративной среде — это миф.
Если нам не помогут, то мы тоже никого не пощадим.
Re[14]: Зачем Майкрософту рубить сук, на котором он сидит?
Здравствуйте, IT, Вы писали:
NB>>ок. и что мешает тебе пропихнуть моно, а потом под шумок поменять серваки?
IT>Моно пока всерьёз никто не воспринимает. Хотя это, конечно, тоже больше отмазка, чем реальность. Да и не думаю, что с Моно всё так хорошо.
а ты попробуй, может чего получится... а там глядишь, и сервера виндовые подоспеют.
IT>Например, не уверен, что для Моно существует ADO.NET драйвер для DB2. Он для Windows наполовину нативный, а уже для Моно им вряд ли кто-то озаботился.
Здравствуйте, night beast, Вы писали:
IT>>Моно пока всерьёз никто не воспринимает. Хотя это, конечно, тоже больше отмазка, чем реальность. Да и не думаю, что с Моно всё так хорошо. NB>а ты попробуй, может чего получится... а там глядишь, и сервера виндовые подоспеют.
Пробовал. В ответ мидлфингер. На новом проекте этого не требуется. Здесь мы придумали обходной манёвр. Будем выбивать .NET и Sql Server. Но это может занять одних бумажек и согласований до полу года.
IT>>Например, не уверен, что для Моно существует ADO.NET драйвер для DB2. Он для Windows наполовину нативный, а уже для Моно им вряд ли кто-то озаботился. NB>здесь?
Надо попробовать будет ли оно работать с linq2db.
Если нам не помогут, то мы тоже никого не пощадим.
Re[19]: Зачем Майкрософту рубить сук, на котором он сидит?
[]
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.
Re[18]: Зачем Майкрософту рубить сук, на котором он сидит?
Здравствуйте, Cadet, Вы писали:
C>>>Ну давай к примеру возьмем класс System.String, покажешь, в каком месте он заточен под винду?
C>Ну ок, с натяжкой согласиться можно . Что в общем то не отменяет того факта, что это исключительно вопрос внутренней реализации программы, написанной на дотнете, и все манипуляции с внешними источниками, ака файлами, один шут по умолчанию производятся в UTF-8, см. дефолтные параметры в StreamWriter например.
Ну так это уже не про стринг будет, а про стринг райтер жеж...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re: Зачем Майкрософту рубить сук, на котором он сидит?
Здравствуйте, alexanderfedin, Вы писали:
A>Компания зарабатывает деньги не на продаже .NET, а на продаже операционной системы Windows. .NET — это средство для облегчения создания программ под Windows сторонним производителям, а не способ облегчить перенос этих программ на другие платформы.
С некоторых пор это средство для усложнения создания программ под Виндовс сторонним производителям.
Re[22]: Зачем Майкрософту рубить сук, на котором он сидит?
Здравствуйте, Erop, Вы писали:
N>>Так вот и не кушаем Но иногда кажется, что витамины из этого кактуса сильно полезнее. Тогда народ пробует свежесорванное, предварительно побрив E>Дык вот не надо насиловать природу просто. Нет бы вот по шерсти кактусы глотать, а вы всё не с того конца заглотунть стараетсь
Проблема в том, что у кактуса иголки во все стороны равномерно смотрят. Нельзя сказать, куда "по шерсти".
Re[23]: Зачем Майкрософту рубить сук, на котором он сидит?
Здравствуйте, Privalov, Вы писали:
N>>>Так вот и не кушаем Но иногда кажется, что витамины из этого кактуса сильно полезнее. Тогда народ пробует свежесорванное, предварительно побрив E>>Дык вот не надо насиловать природу просто. Нет бы вот по шерсти кактусы глотать, а вы всё не с того конца заглотунть стараетсь
P>Проблема в том, что у кактуса иголки во все стороны равномерно смотрят. Нельзя сказать, куда "по шерсти".
Довольно большое количество дотнетовских проектов, как бы намекает, что это просто вы не умеете их готовить...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[17]: Зачем Майкрософту рубить сук, на котором он сидит?
Здравствуйте, Patalog, Вы писали:
C>>Ну давай к примеру возьмем класс System.String, покажешь, в каком месте он заточен под винду? P>Данубожемой, вот с первой жеж буквы — system это у нас что? Система. А система у мелкомягких какая? Правильно, венда. P>Ergo, System.String заточен под винду!!111
Тогда Java, JavaScript и HTML DOM тоже заточен под винду.
Re[13]: Зачем Майкрософту рубить сук, на котором он сидит?
Здравствуйте, 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, которая конечно переносима ОК, только ни на одной платформе нормально не работает
Re[14]: Зачем Майкрософту рубить сук, на котором он сидит?
Здравствуйте, Константин, Вы писали:
К>В самом центре .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 и других мультиплексирующих систем под Юниксы недоумевают.
Здравствуйте, 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 года, оно будет лучше работать.
Re[16]: Зачем Майкрософту рубить сук, на котором он сидит?
Здравствуйте, Константин, Вы писали:
К>Если бы .NET framework проектировался кросс-платформенным, об эффективном асинхронном IO можно было бы забыть, см. например состояние этого в Java.
Я правильно понимаю, что на .net подразумевается писать исключительно серверы, причём рассчитанные на работу с тысячами одновременных запросов? )
Re[17]: Зачем Майкрософту рубить сук, на котором он сидит?
Здравствуйте, 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).
Re[18]: Зачем Майкрософту рубить сук, на котором он сидит?
Здравствуйте, Константин, Вы писали:
К>Среда, где не особо считают ресурсы, это только PC, причём только стационарные. К>Даже на ноутах с таблетками имеет значение эффективность кода — времени CPU может и не очень жалко т.к. мощи много, жалко батарейку.
К>А уж на мобильниках и подавно — там и камни слабые, и батареи маленькие. К>Сравните например производительность Nokia Lumia 510 с Samsung Galaxy Mini 2 (в обоих Snapdragon S1 MSM7227A). К>Или, в следующем поколении, например Nokia Lumia 525 с Sony Xperia M (в обоих Snapdragon S4 MSM8227).
А причём тут это всё? ) Я подразумевал совсем не то, что вне нагруженных серверов наплевать на ресурсы. Я намекаю, что асинхронный IO будет эффективнее обычного многопоточного только на очень узком круге задач.
Re[19]: Зачем Майкрософту рубить сук, на котором он сидит?
Здравствуйте, alex_public, Вы писали:
_>Я подразумевал совсем не то, что вне нагруженных серверов наплевать на ресурсы. _>Я намекаю, что асинхронный IO будет эффективнее обычного многопоточного только на очень узком круге задач.
Это ошибка так считать.
Как только число одновременно работающих файлов/сокетов сравняется с числом ядер, асинхронный IO станет эффективнее.
Если в системе есть и другие активные процессы, "эффективнее" станет "в разы эффективнее".
А если число файлов на пару порядков превысит число ядер, у вас тупо кончится память, потому что потоки очень дорогой системный ресурс.
«обычный многопоточный IO» более-менее пригоден только для hello world, и ещё для очень узкого класса приложений, например что-то вроде офиса, когда все данные в RAM, а от IO требуется только [де]сериализация раз в полчаса на быстрый локальный диск.
Посмотрите ради интереса, какое API использует скажем chromium для работы с диском и сетью.
Например, по этой причине из нового WinAPI повыкидывали вызовы, которые могут блокировать вызывающий поток хотя бы на 50 миллисекунд.
Re[20]: Зачем Майкрософту рубить сук, на котором он сидит?
Здравствуйте, Константин, Вы писали:
К>Как только число одновременно работающих файлов/сокетов сравняется с числом ядер, асинхронный IO станет эффективнее.
Нет, эффективнее он будет при намного большем числе задач.
К>Если в системе есть и другие активные процессы, "эффективнее" станет "в разы эффективнее".
В разы при десятках потоков? ) Это даже не смешно.
К>А если число файлов на пару порядков превысит число ядер, у вас тупо кончится память, потому что потоки очень дорогой системный ресурс.
К>«обычный многопоточный IO» более-менее пригоден только для hello world, и ещё для очень узкого класса приложений, например что-то вроде офиса, когда все данные в RAM, а от IO требуется только [де]сериализация раз в полчаса на быстрый локальный диск.
И что это за обычные десктопные приложения, которые требует сотен одновременных IO потоков? )
К>Посмотрите ради интереса, какое API использует скажем chromium для работы с диском и сетью.
http://www.chromium.org/developers/design-documents/threading угу) И ни слова про эффективность, исключительно архитектурные нюансы.
К>Например, по этой причине из нового WinAPI повыкидывали вызовы, которые могут блокировать вызывающий поток хотя бы на 50 миллисекунд.
Ну посмотрим как много софта перейдёт на это дело... )
Если нам не помогут, то мы тоже никого не пощадим.
