Здравствуйте, DarkGray, Вы писали:
V>>>>и это при ~17% реальной живой доле и отрицательной первой производной.
DG>>>при отрицательной относительной(долевой) первой производной
V>>Разумеется, коль приведены проценты.
DG>я о том, что уменьшение доли может ни о чем не говорить, если при этом увеличивается абсолютное кол-во. DG>такое поведение может быть обусловлено тем, что технология применяется в какой-то нише, которая хоть и растет, но медленнее чем другие ниши.
Ну... я бы не назвал ASP.Net нишевым. Самый что ни на есть ширпотреб в оригинальном смысле этого слова. Как и конкурирующие JSP или PHP. Дело в низлежащей платформе, конечно. Виртуализация линухов стоит дешевле виртуализазии виндов в плане железа, т.е. тоже самое железо потянет больше виртуальных узлов, если на этих узлах будут крутиться линуха. Ну и плюс гораздо более простое разделения, где можно писать, а где нет, в дереве директорий, позволяет накручивать десятки виртуалок практически на один и тот же экземпляр образа, с отличающейся подмонтированной частью для данных клиента. А это очень вкусно выглядит для хостеров. ИМХО доля линухов для хостинга будет только расти.
Здравствуйте, AndrewVK, Вы писали:
AVK>А интереса к реальному положению дел, судя по этому топику, у тебя нет.
А что такое реальное положение дел? Я беру последний выпущенный фреймворк (4-й) и пытаюсь выяснить: сработает ли прославленная JIT-оптимизация на простейшем, казалось бы, случае:
v.Aggregate(c, (acc, k) => acc += k, acc => acc);
Не срабатывает. Окей, я понимаю, что здесь массивная конструкция итераторов и ещё байт знает, что, с чем и плюсовый компилятор вряд ли управится. Ну хорошо, это перебор. Сделаем проще:
static T accumulate<T>(T init, T[] array, Func<T, T, T> func)
{
T result = init;
foreach (var x in array)
result = func(result, x);
return result;
}
c = accumulate(c, v, (acc, k) => acc + k);
Однако, этот вариант тоже беспощадно тормозит, правда, "всего лишь" вшестеро по сравнению с C++-ными лямбдами. Хотя, казалось бы, тут есть все условия для полного инлайнирования. Где оно? В смысле — может быть, инлайнинг и есть, но я не вижу вменяемого результата этого инлайнинга. Код полностью замкнут, это не библиотека с открытым API, размер массива — константа и т.п. Оптимизируй — не хочу.
Вот такое реальное положение дел. ЧЯДНТ?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, gandjustas, Вы писали:
V>>>Ты случайно не клиентскую DHTML-фичу имеешь ввиду? V>>>Шучу-шучу... Но по факту, в хорошем современном веб-приложении, особенно с модой на ajax, на клиенте выполняется всяко больше, чем на сервере. G>>По факту ты говоришь бред, то что выполняется на клиенте в веб-приложении — логика интефейса, а бизнес-логика на сервере.
V>Не прав. Первичная бизнес-логика обязательно и на клиенте тоже. Но и это не важно, коль мы обсуждаем динамику и распределение кода в % м/у клиентом и сервером. Абсолютно фиолетово с т.з. обсуждаемого, как ты назвал свой серверный код.
Что значит "первичная бизнес логика", чем она от вторичной отличается? Ты наверное не соображаешь что если дать возможность клиенту проводить вычисления, а потом посылать резльтаты на сервер, то это может быть не согласовано с логикой на сервере. Поэтому сейчас ни одно приложение не имеет логики на клиенте, на клиенте располагается код для обработки UI и не более того.
V>>>Ну и к тому же, более 90% от современного трафика составляет всё еще статический контент, в т.ч. графика. Поэтому насчет твоих "эра закончилась" — это у тебя от незнания ситуации публичный казус случился. G>>Это тут не при чем. Сервер может много ресурсов потратить чтобы выдать относительно небольшой json.
V>Какой именно сервер?
Лобой. Это чтобы ты понял что объе данных не коррелирует с полезностью и заратами.
G>>Один видеофайл будет в миллион раз больше, но пользы от него в миллион раз меньше.
V>С чего бы это? В бизнесе польза измеряется выручкой, а эффективная отдача медиа находится фактически на грани возможностей современного управления ресурсами.
Эффективная отдача заключается в том чтобы не забирвать канал, о отдавать ровно столько сколько клиент сможет принять учитывая характеристики канала и возможности клиента.
И одна из самых эффективных реализаций такого сейчас сделана угадай где? Правильно в самом ненативном silvelight. От тупо считывает разные файлы с сервера в разным bitrate в зависимости от загруженности канала.
V>>>Да и вообще, размер средней генерируемой HTML-странички, без учета скриптов и стилей (которые статичны у грамотных разработчиков, в отличие от нубов, юзающих server-side web controls) в районе 500 байт. Где там нужна эффективность? Поэтому и рулит PHP, а доля ASP.Net всё еще смехотворна. G>> G>>Посмотри сколько данный форум возвращает, и не говори бредятину.
V>И что, каждый байт генеренный? Вырежи пользовательские сообщения (статическая часть, которую можно было хоть в файлах хранить) и посмотри еще раз.
А какая разница? Из них же все равно надо склеить html, или ты думаешь что это бесплатно делается?
V>>>И если уж речь зашла об эффективности... где нужна эффективность для "тяжеловесных" операций, там вовсю пашет CGI или FastCGI/С++ аж бегом. G>>Приведи пример? Вот stackoverflow с тобой не согласен, а это на сегодня самый быстрорастущий ресурс.
V>Мде? Покажи мне, в каком месте он не согласен? Нашел ты, однако, "ресурс", который суть текстовый формум. Ты еще социальную сетку какую-нить приведи в пример. Я тебе быстро покажу, как ее реальное быстродействие замерить.
Ну замерь "реальное быстродействие" stackoverlow, посмотри какие там юзкейсы есть и статистика прям на главной. Ты смешон
V>>>Потому как подобные задачи на дотнете даже не взлетят. Дотнет там можно попользовать разве что вместо PHP-обертки, т.е. в кач-ве "подай-принеси" на этом и всё. (конкретно по ссылке высокоуровневая логика на матлаб, а тяжеловесные вычисления переписаны на С++) G>>Не вижу там C++, скорее всего твоя выдумка. Там какойнить PHP и flash.
V>Т.е. ты не в состоянии ни HTML код страницы прочесть, ни по ссылке сходить?
Я ссылку открыл, там на странице ни одного слова про C++ или native, веб-сервер Apache. Скорее всего там PHP. Для отображения используется flash.
G>>И что же мы не видим копортивных приложений на C++? все как-то java, да .NET или веб на PHP и Ruby. Видимо парсинг TDS далеко не самая большая проблема
V>Ну конечно, фигли там для нескольких десятков девочек-операционисток попу рвать? Подождут. Если они работали в свое время на Celeron-333, то теперь уж точно ниче страшного. Правда, в те времена ГУИ было честное и быстрое, в отличие от браузерного, но кто и когда этих девочек спрашивал?
Не понял о чем ты. Я спрашиваю почему на C++ мы не видим сотен сайтов если все так плохо у ASP.NET? Кстати большинство сайтов на ASP.NET прекрасно работают с достаточным быстродействием.
G>>И много ты таких видел? Я ни одного, все как-то пишут на .NET и не парятся.
V>Как тебя почитать, так ты окромя дотнета вообще ничего не видел... А я здесь при чем? V>
V>По данным Netcraft Web Server Survey за июнь 2011 года, доля веб-сервера Microsoft IIS на всех доменах в Сети продолжила падать и с майских 18,37% опустилась до уровня 16,82%. Это самый низкий показатель с конца 1997 года.
Да без разницы, возьми apache\php, с++ в вебе в микроскоп не видно. Хотя я уверен что у php парсер TDS работает не быстрее .NETного
V>>>Ты просто очень далек от современной ситуации в web, судя по твоим постам... G>> G>>Зато ты близок... сколько ты вебовых приложений написал то?
V>О! Можно вынимать и демонстрировать? V>Если за всю карьеру, то около десятка, из них 3 на ASP.Net. Есть с чем сравнить. А если брать не чистый веб, а всякие сервисы, просто многозвенки и распределенные архитекруты по различным протоколам (пару десятков протоколов навскидку), то, скажем так, на конкретно ASP.Net я могу посмотреть со всех сторон. Не только как "чисто-вебной" части, когда принимается решение на чем делать HTTP-часть, но и чуть раньше, как инструмент реализации GUI, когда принимается решение, делать ли веб-морду, или таки классический GUI-клиент. Например, однажды был взят ASP.Net для генерации Silverlight-приложений, которые отображаются во вкладках IE (!!!) локальным сервисом (вовсе не 80-й порт) в плагине к этому IE. Такое решение оказалось намного интересней в плане отзывчивости, чем GUI этого плагина на WPF + локальный WCF сервис. Еще пару раз брал ASP.Net как либу для нетривиального рантайм-редеринга текста (т.е. не как out-of-proc сервер, а именно как либу). Это помимо классического веба. Т.е. эту примочку к IIS раком ставить умеем вдоль и поперек, не переживай... и даже хакать и корректно юзать MS Embedded SQL с ASP.Net, чтобы сравняться по эффективности с MySQL на зачитке (смогешь так?).
Круто.. Я три на asp.net сделал за первый год. Причем особо извращений не было, даже лечил некоторые извращения таких умельцев "раком ставить".
MS SQL рвет как тузик грелку на любых нетривиальных запросах, так что тут и соревноваться не зачем.
V>Сравнить с аргуентами: "для моих задач хватает", "все пишут на ASP.Net"... и это при ~17% реальной живой доле и отрицательной первой производной.
Ты еще посмотри доля каких серверов растет. Ты удивишься, это nginx. Тупо потому что самый дешевый вариант для организации прокси. Для генерации контента он и не используется. Обычно им экранируют апач (который знатный трмоз если что).
V>>>Не надо говорить о том, о чем не имеешь ни малейшего представления. Вот я тебе пошлю свой вариант прототипа WPF-приложухи имеющей сравнимую сложность GUI. Берешься сделать его заметно эффективнее (заметно, это хотя бы 30%)? А то ля-ля в форуме разводить, это не мешки ворочать... G>>Плати бабло — сделаю. Мне не сложно.
V>Так и думал... V>но если уж речь о деньгах, то это имеет смысл только в виде пари, симметричности ради, т.к. мне тоже придется затратить время на макет и некую минимальную функциональность.
Так у тебя вроде еще прототип или как понимать фразу выше?
Здравствуйте, vdimas, Вы писали:
V>Опять же возможно... Но только за последние пару лет у нас уменьшилось кол-во бинарно подерживаемых версий gcc
Вот когда бекенд стандартизуют на 100% у всех компиляторов, а потом большую часть API всех часто используемых ОС тоже, тогда и можно будет сравнивать кроссплатформенность С++ и джавы.
... << RSDN@Home 1.2.0 alpha 5 rev. 1537 on Windows 7 6.1.7601.65536>>
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, gandjustas, Вы писали:
V>>>Быстрая сортировка. Нарисуй-ка inplace без foreach. G>>.Sort
V>Не вопрос, приведи ее "рефлекторное" тело и покажи, что там хватило конструкции foreach.
Зачем? Это ведь написаный, протестированный и отлаженный не мной код. Там OutOfRangeException не возникает. Я его использую и у меня не возникает.
Мы ведь говорим за код приложений.
V>Ты ведь не хочешь быть тем самым "программистом", который, не найдя в и-нете TSuperComponent считает задачу нерешаемой?
Ты удивишься но написание почти всего кроме быстрой сортировки на месте и умножения матриц не требует цикла for.
V>>>Опять read-only. G>>И че? Я вообще immutable юзаю, работает в некоторых сценариях быстрее + распараллеливание. V>Именно, в очень некоторых быстрее. В которых все остальные тоже юзают. Но где надо действительно быстрее, не катит.
Ну а там где не быстрее можно параллелить. А если не хватает CPU, то можно и на GPU. Причем для всего есть managed средства и почти нигде не надо писать for.
G>>Для моих задач быстродействия linq более чем хватает V>Дык, может это ключевое? Что же ты пытаешься тогда за всех расписываться?
Я зенимаюсь тем же, чем и тысячи других программситов, значит им тоже. А ты наверное один такой уникальный, или на пару с ГВ, кому быстродейтсвия не хватает категорически, хотя что за задачи — хз. Ни ты ни он не колетесь.
V>>>Да, пошли по 4-му кругу. И за все эти круги так и не было названо более одной unmanaged-ошибки... Потому как вторая названная якобы исключительно unmanaged ошибка — работа с уже удаленным объектом — это есть ошибка логики программы вообще-то, которая на unmanaged себя проявляет сразу, а на managed является той самой классической плавающей головной болью, когда работаем с никому уже ненужными экземплярами объектов. G>>Ага, только эта ошибка логики программы проявляется только в unmanaged
V>Именно, явно проявляется, о чем и речь! А в managed ее надо долго и нудно искать, и вообще сложно воспроизвести, т.к. ошибка дает себя знать не в момент, когда срабатывает ошибочный код, а по косвенным признакам.
Не, в managed просто нет таких ошибок или сразу exception. То что привел ГВ — чистой воды совпадение, причем полученное сочетанием десятка факторов, и далеко не все они являются безошибочными сами по себе.
V>>>Ты опять низвеграешься в пучину своей демагогии, что на дтонете надо всё делать правильно, и тогда будет просто супер, а на С++ обязательно надо делать неправильно. G>>Ты до сих пор не понял, в unmanaged больше возможностей сделать ошибку. В managed можно писать так что подобные ошибки в принципе исключаются.
V>Мы пока обсудили всего две ошибки, причем, характерная для native всего одна из них (и то не факт, при таком как у вас тестировании).
Из-за ошибки реинтерпретации памяти(обращения по невалидному указателю) и отсутствия контроля выхода за границы происходит большинство проблем unmanaged.
Попытка избежать проблем ведет к резкому усложнению и\или к снижению производительности.
V>>> Тем более, что бери любой опен-сорсный C#-проект, и смотри как реально пишут (если уж опенсорс по плюсам тут приводили). G>>Я вот активно юзаю опенсорсный Orchard CMS, хорошо пишут. Еще для SharePoint юзаю несколько проектов с codeplex. G>>Так вот во всех них обычный for крайне редко встречается.
V>Крайне редко, это сколько в абслютном кол-ве? Обложен ли каждый случай минимум 3-мя юнит-тестами, т.е. включающими граничные случаи?
V>>>Да ну? Даже внутри "святой коровы" самих дотнетных либ, идущих в поставках .Net? Ты о рефлекторе слышал когда-нить? G>>Вообще-то можно и исходники скачать. Я вот Linq и Rx смотрел, так там в принципе отсутствует код, аналог которого в unmanaged может падать.
V>Если смотрел так же как стандарт ECMA-335, значит не смотрел вообще. В телах реализации системных либ дотнета массивы используются чуть более, чем везде. К тому же, ты назвал либы, доля которых менее 1% в общей кодовой базе в поставке, но и там есть операции над массивами и по индексу в т.ч. Посмотри еще раз.
Меня не интересуют низкоуровневые детали, пусть хоть полностью в unmanaged перепишут. Меня как раз интересует прикладной код и библиотеки прикладного кода. Linq например импользуется чаще, чем StringBuilder и внутри первого нету for и массивов, а внутри второго есть.
G>>Есть два вида эффективности: высокая эффективность и достаточная эффективность. Так вот первая нужна только программистам чтобы понты на форумах кидать, а вторая нужна бизнесу.
V>Это ты только что сам придумал?
Нет, это правда жизни. Не бывает медленных программ, бывают недостаточно быстрые.
V>Вообще-то, эффективность нужна "лучше, чем у конкурентов", чтобы продавать коробочное ПО.
Не-а, когда обе программы "достаточно быстрые", то уже не быстродействие является главным козырем. Причем быстродействие десктопных программ это не только и не столько скорость выполнения кода.
V>И даже в заказном ПО при условии честных тендеров, как ни странно, тоже.
В заказном ПО как раз заранее характеристики обговариваются и никто не парится сделать максимально быстрым.
Хотя как раз в обоих случаях сроки разработки важнее скорости работы программы, особенно для первых версий, потому что начав продавать можно уже работать за деньги клиентов, а не их своего кармана.
G>>У меня был ровно одни случай когда .NET не обеспечивал достаточной эффективности. V>Действительно? Это лишь значит, что ты в отрасли совсем недавно и больше ничего.
Действительно? Только я за это время успел из рядового программиста стать преподавателем, MVP, очень востребованным специалистом и руководителем небольшой фирмы, по пути поработав и тилидом и немного ПМ.
V>>>Иначе бы никто не искал программистов С++ сегодня. G>>Ищут их в основном для саппорта. V>Нет.
Как раз да. Приведи ссылку где набирают C++ про новый проект, только не новую версию старого.
V>>>Подумай сам, нафига пишут огромное кол-во нейтива, ведь есть джава и дотнет? G>>Не пишется, а саппортится, пишется на порядки меньше. V>Опять мимо.
Ну конечно, у тебя просто прямое подключение к богу статистики и ты все лучше знаешь.
Итого на пару NET и Java в 4 раза рвут C++. При этом если посмотреть на вакансии C++ особенно в москве, то плакать хочется. ЗП
G>>>>При этом способы работы, которые уменьшают количество таких ошибок, приводят к снижению быстродействия.
V>>>В каком месте? G>>например умные указатели с подсчетом ссылок.
V>Приводил уже статистику: http://www.rsdn.ru/forum/philosophy/4506914.1.aspx
Ну это только твой кож, а если глянуть другие проекты...
V>>>Что и требовалось доказать... А по другому и быть не могло, с таким пещерным представлением о процессе тестирования ПО... По-сути, ты предлагаешь сваливать на клиента хлопоты по поиску ваших багов. Потому как ассерты — вещь исключительно динамическая. Мои поздравления. Никаких "волшебных ИНАЧЕ", как только что выяснилось выяснилось, нет и никогда не было. А есть обычная практика небольших контор, питающихся за счет несложного заказного ПО. Главное, надыбать клиента и можно окучивать до бесконечности. Но на рынке коробочного ПО подобные рассуждения выглядят как рассуждения сумашедших. G>>А с чего ты взял что ассерты заменяют другие виды тестирования? Ассерты заменяют только те самые "негативные" тесты. Не надо описывать такие сценарии в автотестах. Пусть code contracts занимается проверкой что они не произойдут.
V>Угу, ЧТД повторно. Свалить в кучу ассерты и контракты — это жесть, спасибо за море фана.
И то и другие — инструменты.
V>Ассерты должны искать ошибки самой программы, в то время как контракты — проверять допустимость аргументов, которые бывают любые, даже в программе без ошибок.
В CodeContracts тоже есть ассерты если что
V>Ассерты сами по себе ничего не проверяют, это не статическая, а динамическая штука. Ты напишешь проверку — будут у тебя проверять, не напишешь — будут проверять у клиента.
А если напишешь проверку то что? Кинуть exception? Ассерты говорят что какое-то условие должно выполнятся всегда, то есть вообще всегда — не выполняется, надо править программу, зачем еще что-то писать для того же резльтата? Если в процессе тестирования ассерт не выпадал, а выпал у клиента при нормальной работе, значит и процесс тестирования надо улучшать.
G>>>>Ты совсем не понимаешь для чего нужны автоматизированные тесты. Найти ошибку тестами крайне сложно, потому что ты пишешь тесты, тестируя ожидаемое поведение. Но поведение может оказаться совсем неожиданным, например если кто-то в процессе работы меняет часовой пояс. Стоит ли для такого писать тест? Что может программа предпринять в таком случае? А ничего и тест писать не стоит. V>>>Детсад. G>>Правда жизни. Ты много процесс тестирования организовывал?
V>Дык, нет у вас собственно процесса. Самодеятельность одна, основанная на субъективных представлениях о том, "как надо". Сорри, но к теме "качество ПО" и организации контроля ка-ва ПО ты пока в своей карьере еще не приближался.
Смешной ты, много ты процесс тестирования организовывал? Я то как раз прекрасно знаю про качество знаю и знаю где находится граница good enough.
G>>Тем не менее точность есть. Каждый просмотр подсчитывается. V>Это не есть точность, если не каждый фиксируется в базе.
Каждый
V>>>Да и нагрузка тут — не сотни тыщ запросов в секунду, так что даже если сбрасывать каждое приращение в базу — ниче страшного не будет. Это не тот порядок цифр. G>>Это очень высокий порядок цифр, для большинства приложений и такой не нужен.
V>Да понятно, кто над чем работает, у того такие представления. Мне всё время охота сказать, что "большинству нужен", но я прекрасно понимаю что это не так, або биография была бурная, делал даже автоматизацию офиса, поэтому ограничиваюсь фразой "много где нужен"...
Учитывая быстродействие и дешевизну железа — почти нигде не нужен
V>Интересуйся больше окружающим, сходи на другие разделы этого же форума, например. Хотя бы в multimedia.
О, да. Тут послушать так все минимум софтом для космических кораблей занимаются. А я занимаюсь софтом, который бабло приносит.
G>>Я вот активно юзаю опенсорсный Orchard CMS, хорошо пишут. Еще для SharePoint юзаю несколько проектов с codeplex. G>>Так вот во всех них обычный for крайне редко встречается.
V>Крайне редко, это сколько в абслютном кол-ве? Обложен ли каждый случай минимум 3-мя юнит-тестами, т.е. включающими граничные случаи?
Orchard: 57 for против 706 foreach, и это еще не считая linq.
Так что реально не более 1-2% от всего кода работы с коллекциями.
Здравствуйте, gandjustas, Вы писали:
V>>Не прав. Первичная бизнес-логика обязательно и на клиенте тоже. Но и это не важно, коль мы обсуждаем динамику и распределение кода в % м/у клиентом и сервером. Абсолютно фиолетово с т.з. обсуждаемого, как ты назвал свой серверный код. G>Что значит "первичная бизнес логика", чем она от вторичной отличается?
Наверно тем, что клиент не располагает всеми данными, и может лишь верифицировать поля по статическим ограничениям, либо по ограничениям, зависящим только от данных в рамках одной записи (грубо).
G>Ты наверное не соображаешь что если дать возможность клиенту проводить вычисления, а потом посылать резльтаты на сервер, то это может быть не согласовано с логикой на сервере.
Тихий ужас просто... Сервер на ASP.Net выдает динамические HTML-страницы, которые не согласованы с собственной логикой... Дай пожму твою мужественную руку! Это просто титанический труд... это ж еще суметь такое надо!
G>Поэтому сейчас ни одно приложение не имеет логики на клиенте, на клиенте располагается код для обработки UI и не более того.
Прямо сейчас я не видел ни одного вменяемого, где бы поля не верифицировались первично еще на клиенте. Ну и подгрузка и аплоад AJAX-данных всегда управляется логикой на клиенте, то бишь просто огромный пласт логики целиком едет на клиента и там прекрасно живет.
V>>>>Ну и к тому же, более 90% от современного трафика составляет всё еще статический контент, в т.ч. графика. Поэтому насчет твоих "эра закончилась" — это у тебя от незнания ситуации публичный казус случился. G>>>Это тут не при чем. Сервер может много ресурсов потратить чтобы выдать относительно небольшой json.
V>>Какой именно сервер? G>Лобой. Это чтобы ты понял что объе данных не коррелирует с полезностью и заратами.
Да понял я понял. Не коррелирует. Бывает такой Transact SQL в природе. Очень опасная для тебя штука, похоже, ведь может случится несогласование с логикой. Поэтому надо пол-базы грузануть, на управляемом коде перелопатить, а потом нести самую отпетую пургу, какую я только слышал, насчет корреляций объемов данных, затрат и полезности. Правда, просмотрев весь контекст, я вижу, что речь здесь может идти только о полезности программиста? А оно, соглашусь, ни с чем тут не коррелирует.
V>>С чего бы это? В бизнесе польза измеряется выручкой, а эффективная отдача медиа находится фактически на грани возможностей современного управления ресурсами. G>Эффективная отдача заключается в том чтобы не забирвать канал, о отдавать ровно столько сколько клиент сможет принять учитывая характеристики канала и возможности клиента.
Интересно. Не пояснишь на пальцах, а как возможно иначе для TCP? (в отличие от UDP, где это таки возможно)
G>И одна из самых эффективных реализаций такого сейчас сделана угадай где? Правильно в самом ненативном silvelight. От тупо считывает разные файлы с сервера в разным bitrate в зависимости от загруженности канала.
С какой версии сервелат перестал быть нейтивным? Из всех версий фреймворков, в нем закодировано в нейтиве больше всего, включая собственно сервелатное GUI и всё медиа. И уж управление QoS, если ты о нем, и диспетчеризация приоритетов в драйвере QoS, никогда не выполнялись в managed. Из managed можно разве что через pInvoke вызвать ф-ию открытия сокета с желаемыми предустановленными параметрами QoS, больше ничего. А уж как пойдут данные — от дотнета уже не зависит. Если же ты о проигрывателях медиа в сервелате, то при чем тут дотнет? Открой любой, даже самый старый проиграыватель, и в нем есть параметр — длина буфера (в ед. измерения времени). Проигрыватель медиа всегда подкачивает данные чуть вперед, но агрессивно не больше чем до заполнения буфера. Ну и надо понимать особенности TCP. Наиболее эффективно передавать данные с постоянной скоростью, т.е. с постоянным размером окна. Как только окно начинает дергаться, так кол-во служебной информации и общее кол-во пакетов возрастает.
V>>>>Да и вообще, размер средней генерируемой HTML-странички, без учета скриптов и стилей (которые статичны у грамотных разработчиков, в отличие от нубов, юзающих server-side web controls) в районе 500 байт. Где там нужна эффективность? Поэтому и рулит PHP, а доля ASP.Net всё еще смехотворна. G>>> G>>>Посмотри сколько данный форум возвращает, и не говори бредятину.
V>>И что, каждый байт генеренный? Вырежи пользовательские сообщения (статическая часть, которую можно было хоть в файлах хранить) и посмотри еще раз. G>А какая разница? Из них же все равно надо склеить html, или ты думаешь что это бесплатно делается?
Именно. Приклеить сообщение в 50 байт стоит практически столько же, сколько приклеить сообщение в 1000 байт. Не веришь — измерь сам скорость вставки в StringBuilder. Тоже самое касается парсера потока MS SQL, — единичное текстовое поле парсится за фактически константное время независимо от размеров, т.к. затраты на копирование области памяти в сравнении с затратами на обыгрывание всего остального — ничтожны.
G>Ну замерь "реальное быстродействие" stackoverlow, посмотри какие там юзкейсы есть и статистика прям на главной.
Легко, кидаешь куда-нить на локальное ГУИ ActiveX IE-контрол, смотришь в какие ID элементов что внести, пишешь скрипт, например на VBA, и после отправки замеряешь время получения обновленной страницы с твоим сообщением. У меня для социалок выходили 1,5-3 сек, при пинге 80ms. Вот и прикинь быстродейтвие. При том что для такого сценария, коль скрипт отрабатывает практически сразу, скорее всего TCP-коннекшен еще жив после запроса самой страницы. В общем, это такой порядок цифр, где обсуждать сразу нечего. Для сравнения, обычная многозвенка, с десктопной мордой, при отключенном нагиле каждому клиенту способна выдавать десятки "страниц" (форм) в секунду. Т.е. это не общая пропускная способность, а именно оборот по одному независимому клиентскому коннекту, которых тоже десятки. Ну и реакция аппликухи при изменении данных молниеносная, разумеется. Вот почему я веб терпеть до сих пор не могу, бо там не ГУИ, а издевательство над психикой.
G> Ты смешон
Мне тоже нескучно.
V>>Т.е. ты не в состоянии ни HTML код страницы прочесть, ни по ссылке сходить? G>Я ссылку открыл, там на странице ни одного слова про C++ или native, веб-сервер Apache. Скорее всего там PHP. Для отображения используется flash.
Значит, не смотрел. Там используется shockwave player, это не flash, хоть одной и той же конторой писанное. А исходники библиотеки доступны для скачивания.
V>>Ну конечно, фигли там для нескольких десятков девочек-операционисток попу рвать? Подождут. Если они работали в свое время на Celeron-333, то теперь уж точно ниче страшного. Правда, в те времена ГУИ было честное и быстрое, в отличие от браузерного, но кто и когда этих девочек спрашивал? G>Не понял о чем ты. Я спрашиваю почему на C++ мы не видим сотен сайтов если все так плохо у ASP.NET? Кстати большинство сайтов на ASP.NET прекрасно работают с достаточным быстродействием.
Наверно, потому что веб-технологии тормозные, сойдет и так. Но корпоративные приложения бывают далеко не только веб. Прямо на Оракле чудесно пишут приложухи, и прямо оттуда бинд на джаву. И клиенты — оч тонкие вебовские или десктопные морды. В одном из проектов сервер был хоть и дотнетный (сервер приложений, не веб), клиенты к нему были как дотнетные, так и нейтивные. А сам сервак вызывал основные достаточно тяжелые операции, писанные на плюсах. Целиком дотнетные были только задачи общения с базой (бо данных немного) и построения метаинформации для прикладных сущностей.
G>Да без разницы, возьми apache\php, с++ в вебе в микроскоп не видно. Хотя я уверен что у php парсер TDS работает не быстрее .NETного
Я тебе показал, что и ASP.Net не особо видно. Заметь, я не утверждал, что "все пишут сервера на плюсах", в отличие от тебя, так что не юли. Я говорил, что возможность такая есть и пишут. Даже взять начинку марштрутизаторов, например, с администрированием по HTTP, начинка обычно плюсовая, и ссылки на популярные HTTP-либы для этого тебе давались.
G>Круто.. Я три на asp.net сделал за первый год. Причем особо извращений не было, даже лечил некоторые извращения таких умельцев "раком ставить".
Супер! Хорошее приложение начинается от 3-5 человеколет, так что примерную "трудоемкость" своих проектов ты обрисовал. Если подобного уровня "проекты" в активы засчитывать, никакого резюме не хватит.
G>MS SQL рвет как тузик грелку на любых нетривиальных запросах, так что тут и соревноваться не зачем.
Кто кого рвет и на каких запросах? Соревновались тыщи раз до тебя — не рвет нифига на большом классе задач. Осообенно там, где для получения маленького объема данных надо перелопатить большой объем. Вы его просто готовить не умеете. А там, где действительно можно порвать MS SQL, там впору нейтивную числомолотилку вставлять, бо с числодроблением на дотнете из рук вон плохо.
G>Ты еще посмотри доля каких серверов растет. Ты удивишься, это nginx. Тупо потому что самый дешевый вариант для организации прокси. Для генерации контента он и не используется. Обычно им экранируют апач (который знатный трмоз если что).
Да плевать. Какое тебе дело, до сравнения долей всего остального вне ASP.Net? Ты что-то насчет "всех серверов на ASP.Net" утверждал? Утверждал. Глупость сморозил? Сморозил.
V>>но если уж речь о деньгах, то это имеет смысл только в виде пари, симметричности ради, т.к. мне тоже придется затратить время на макет и некую минимальную функциональность. G>Так у тебя вроде еще прототип или как понимать фразу выше?
Понимать так, что собеседник знает что говорит, бо экспериментировал именно со способами поднятия эффективности WPF-приложений. И вижу, что ты разводишь банальное ля-ля, делая далекоидущие выводы только лишь из того факта, что собеседник помимо всех прочих инструментов юзает С++. Если тебе удасться поднять быстродействие писанного мною для спора макета на оговоренные %, поверь, мне не жалко будет проиграть никаких денег. Бо оно того будет стоить.
Здравствуйте, gandjustas, Вы писали:
V>>Не вопрос, приведи ее "рефлекторное" тело и покажи, что там хватило конструкции foreach. G>Зачем? Это ведь написаный, протестированный и отлаженный не мной код. Там OutOfRangeException не возникает. Я его использую и у меня не возникает. G>Мы ведь говорим за код приложений.
И что? Твои задачи всегда проще, чем код библиотек фреймворка? Если да, то... то тем более не стоит свою рубаху на всех натягивать.
V>>Ты ведь не хочешь быть тем самым "программистом", который, не найдя в и-нете TSuperComponent считает задачу нерешаемой? G>Ты удивишься но написание почти всего кроме быстрой сортировки на месте и умножения матриц не требует цикла for.
Мде... Любая обработка сигналов и просто информации практически всегда требует цикла for. Даже такая тупая вещь как AI.
Кстати да, я действительно удивился.
G>>>Для моих задач быстродействия linq более чем хватает V>>Дык, может это ключевое? Что же ты пытаешься тогда за всех расписываться? G>Я зенимаюсь тем же, чем и тысячи других программситов, значит им тоже. А ты наверное один такой уникальный, или на пару с ГВ, кому быстродейтсвия не хватает категорически, хотя что за задачи — хз. Ни ты ни он не колетесь.
Если в личке спросишь, ссылок отсыплю. Но это не принципиально, ведь даже на этом сайте полно форумов, где ни слова о дотнете и много чего обсуждают.
G>Не, в managed просто нет таких ошибок или сразу exception.
Детсад.
V>>Если смотрел так же как стандарт ECMA-335, значит не смотрел вообще. В телах реализации системных либ дотнета массивы используются чуть более, чем везде. К тому же, ты назвал либы, доля которых менее 1% в общей кодовой базе в поставке, но и там есть операции над массивами и по индексу в т.ч. Посмотри еще раз. G>Меня не интересуют низкоуровневые детали, пусть хоть полностью в unmanaged перепишут. Меня как раз интересует прикладной код и библиотеки прикладного кода. Linq например импользуется чаще, чем StringBuilder и внутри первого нету for и массивов, а внутри второго есть.
Да я понял, что работа у тебя очень узкая: прочесть поле из базы, записать поле в базу. Не понял только, с какой стати столь далекоидущие выводы? Уж чего-чего, а этого твои оппоненты тоже наелись по самое нихочу. Просто стараются избегать подобной рутины. Не всегда получается, правда.
V>>Это ты только что сам придумал? G>Нет, это правда жизни. Не бывает медленных программ, бывают недостаточно быстрые.
Это верно, если программа одна такая на всю нишу. Гораздо чаще бывает такая банальность: лидер в какой-то нише и остальной невостребованный мусор.
G>Не-а, когда обе программы "достаточно быстрые", то уже не быстродействие является главным козырем.
Хе, обе. Твоя-то не будет.
V>>И даже в заказном ПО при условии честных тендеров, как ни странно, тоже. G>В заказном ПО как раз заранее характеристики обговариваются и никто не парится сделать максимально быстрым.
О максимальности речи и не идет. Но если приложение с неплохими характеристиками, надежное при этом, всяко больше шансов получить хороший следующий заказ.
G>Хотя как раз в обоих случаях сроки разработки важнее скорости работы программы, особенно для первых версий, потому что начав продавать можно уже работать за деньги клиентов, а не их своего кармана.
Ну так про макетирование и прочие вещи и на плюсах речь шла. Это универсальные подходы. Любая вменяемая разработки итеративна, иначе она не увидит свет.
G>>>У меня был ровно одни случай когда .NET не обеспечивал достаточной эффективности. V>>Действительно? Это лишь значит, что ты в отрасли совсем недавно и больше ничего. G>Действительно? Только я за это время успел из рядового программиста стать преподавателем, MVP, очень востребованным специалистом и руководителем небольшой фирмы, по пути поработав и тилидом и немного ПМ.
В 3 года можно уложиться. Все равно ведь не поверю, что в 2003-м, например, не сталкивался с задачами, где дотнета не хватало. Это значит, в эти года ты вообще всерьез ни с чем не сталкивался, бо ровно наоборот — под дотнет подходили только некоторые ниши.
G>Как раз да. Приведи ссылку где набирают C++ про новый проект, только не новую версию старого.
V>>>>Подумай сам, нафига пишут огромное кол-во нейтива, ведь есть джава и дотнет? G>>>Не пишется, а саппортится, пишется на порядки меньше. V>>Опять мимо. G>Ну конечно, у тебя просто прямое подключение к богу статистики и ты все лучше знаешь.
Тебе там на семинарах просто мозги промыли. У самой MS мильон относительно новых нейтивных разработок, например, сервера конференций. Любое медиа сейчас идет в нейтиве, VoIP тоже, вся связь, любая обработка сигналов, изображений, и просто информации. Огромный финансовый рынок, из которого даже если и торчат концы в дотнет и джаву, то это именно что лишь самые "наконечники". Есть EDI/HIPPA и прочее, перемалывающее многомегабайтные (!!!) электронные документы. Вот как-то вокруг всех этих направлений дейтельность и складывается. И разве я говорил, что не юзаю дотнет? Еще как юзаю, бо столько функционала нахаляву, и когда его характеристики позволяют, то почему бы и нет? Это же нормально. Но в половине случаев управляемые среды не катят. Я тут всего лишь делюсь опытом, а ты утверждаешь, что нам вообще не стоит этим заниматься, коль задача нерешаема на дотнете, а на С++ обязательно будут баги. А кто тогда будет их решать? Кто напишет тебе управляемую среду? Драйвер GPU? Фильтр под QoS? Шуструю игруху или отзывчивое офисное приложение? Пушкин? Почему участники этого форума не могут-то? Или это настолько в твоем представлении из "далекой галактики", что факт живого общения с людьми из "того" мира тебе кажется нереальностью или как?
И вообще, где ты видел указанные ЗП для спецов верхнего эшелона? Много ты видел афишируемых ЗП для руководителей проектов?
Хотя иногда и проскакивают цифры в 160к для специалиста. Это совсем плохая ЗП для Москвы или как, проясни?
Или вот это что:
Разработка серверной части высокопроизводительного приложения;
Участие в проектировании архитектуры одного из крупных проектов компании.
Это разве не серверная часть? И разве архитектуру разрабатывают не у новых проектов?
Короче, пора было тупо свернуться. У тебя кругозор ровно одной платформы. По остальному ты слышал звон, но не знаешь где он. Требуешь данных и ссылок, а в упор их не видишь. Эту избирательную "слепоту" посторонний человек тебе всё равно никогда не вылечит, только ты сам, если будет желание.
V>>Угу, ЧТД повторно. Свалить в кучу ассерты и контракты — это жесть, спасибо за море фана. G>И то и другие — инструменты.
Принципиально разные. Независимо от языка. Срабатывание ассерта в real-time требует принципиально другого сценария, чем срабатывание проверки контрактов. Во втором случае это могут быть просто неверно введенные пользователем данные, а в первом — это ошибка в самой программе. Необходимо как можно скорее выйти и не дать навредить. Однако, сам сценарий выхода должен зависеть от того, где мы находимся и что делает клиент. В общем, их ну никак нельзя сваливать в одну кучу. Конкретно в текущей области моей работы, самым лучшим сценарием на срабатывание run-time assert будет запись в лог координат ошибки и стека, выдача как можно более вежливого сообщения об ошибке в программе в какой-нить callback клиентскому коду, и немедленный выход.
V>>Ассерты должны искать ошибки самой программы, в то время как контракты — проверять допустимость аргументов, которые бывают любые, даже в программе без ошибок. G>В CodeContracts тоже есть ассерты если что
Серьезно? И то и другое что-то проверяет и может выплюнуть эксепшен. Да они же одинаковые? Не?
V>>Ассерты сами по себе ничего не проверяют, это не статическая, а динамическая штука. Ты напишешь проверку — будут у тебя проверять, не напишешь — будут проверять у клиента. G>А если напишешь проверку то что? Кинуть exception? Ассерты говорят что какое-то условие должно выполнятся всегда, то есть вообще всегда — не выполняется, надо править программу, зачем еще что-то писать для того же резльтата? Если в процессе тестирования ассерт не выпадал, а выпал у клиента при нормальной работе, значит и процесс тестирования надо улучшать.
Чем дальше в лес, тем толще партизаны. Т.е. вы таки постоянно привлекаете клиентов к тестированию? Везет, что еще могу сказать.
G>Смешной ты, много ты процесс тестирования организовывал? Я то как раз прекрасно знаю про качество знаю и знаю где находится граница good enough.
Спецов нанимал, они организовывали и тестеров учили. Как раз, чтобы отсебятину не пороть. Все твои "я то как раз прекрасно знаю" — сугубо субъективны. Если вы на клиенте отлаживаетесь, давай ты мне про кач-во ничего больше говорить не будешь?
G>О, да. Тут послушать так все минимум софтом для космических кораблей занимаются. А я занимаюсь софтом, который бабло приносит.
А остальные за голый интерес что ле работают? Чем ты занимаешься, уже поняли. Это проходили почти все в разное время. У тебя такой сейчас период, ну что ж... Дерзай.
Здравствуйте, gandjustas, Вы писали:
V>>Крайне редко, это сколько в абслютном кол-ве? Обложен ли каждый случай минимум 3-мя юнит-тестами, т.е. включающими граничные случаи?
G>Orchard: 57 for против 706 foreach, и это еще не считая linq.
G>Так что реально не более 1-2% от всего кода работы с коллекциями.
Ну отлично. Отображение крайне редко изменяющегося контента. Супер-пример.
Мне порой свои версии практически всех стандартных контейнеров писать приходится (или таскать из проекта в проект). И вообще делать много глупых приседаний... Например, чтобы ускорить парсинг HTML в пауке "всего лишь" в 25-30 раз, или изворачиваться в персистентном слое вручную полностью, чтобы получить в 45-55 раз (!!!) ускорение раздражающей до этого сериализации развесистых графов объектов... мелочи конечно, а клиентам очень приятно. Просто все эти "мелочи" имеют один побочный эффект: они открывают саму возможность для исполнения еще целого класса задач за счет сэкономленных процессорных тиков.
Поэтому вопрос "достаточности" не однозначен. В первых версиях надо чтобы "просто работало". Потом клиенту надо все больше и больше, а потом вообще львиную долю переписываешь на нейтиве (бывало и такое), бо всё что можно, дотнет честно отдал и самоудалился.
Здравствуйте, AndrewVK, Вы писали:
V>>Опять же возможно... Но только за последние пару лет у нас уменьшилось кол-во бинарно подерживаемых версий gcc
AVK>Вот когда бекенд стандартизуют на 100% у всех компиляторов, а потом большую часть API всех часто используемых ОС тоже, тогда и можно будет сравнивать кроссплатформенность С++ и джавы.
В реальной жизни переносимость на уровне исходников достаточна. кошмар был когда уже на этом уровне приходилось изворачиваться.
У джавы когда-то наблюдал под разные платформы шли разные инсталляхи аппликух. Да еще каждая с собой тащит свою версию фреймворка. Не знаю как последние годы, не слежу.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, samius, Вы писали:
V>>>Это зависит от способа обхода целевого мн-ва. Иногда целевым является именно шаблонный код обхода, который оперирует разными типами, но находящимися в похожих отношениях. Ведь обход для целей визитора бывает внешний и инкапсулированный, это прямо в паттерне сказано. В случае инкапсулированного обхода необязательно всем элементам мн-ва быть наследником одного базового класса/интерфейса, это может быть лес независимых иерархий. Так вот, виртуальная точка входа для callMeBack() реально нужна только в том узле, реальный тип которого неизвестен. Тут уж, конечно, полиморфизм + DD помогут. S>>А я и пишу про случай, когда реальный тип неизвестен. И virtual generic метод тут очень кстати.
V>Нарисуй плиз, какой из 2-х.
Не понял, кто именноо "какой". Обход? Способ обхода не влияет на то, можно ли обойтись без виртуальности. Например, рассмотрим телегу. Если мы знаем, что у телеги должны быть колеса, то организовать обход колес можно как изнутри телеги, так и извне. Никакой виртуальности при этом не надо, если известно как взять колеса и только лишь их на стадии компиляции. Другое дело — кузов телеги (как контейнер, куда можно положить неизвестно что, в том числе и колеса). Но и кузов мы можем обойти как изнутри телеги так и снаружи. Вот когда на этапе компиляции неизвестно, что конкретно в кузове, тогда без полиморфизма не обойтись при выборе метода, независимо от положения способа обхода.
Ты пишешь вроде бы о том же (я выделил выше), но зачем-то в контексте способа обхода.
Моя структура — типичное дерево аки на АлгТД (разве что типов листьев поболее чем один). Обход через внешний итератор.
S>>Это следует из того что реализация предполагает полиморфную рекурсию, тип Queue<a> определен через Queue<Tuple<a,a>>. А С++, как известно, в рантайме порождать типы не умеет.
V>А зачем порождать? Такие определения расчитаны на языки с зависимыми типами, а они не пользуют информацию о типах в рантайм, т.е. ничего не порождается. Зависимости м/у типами проверяются в compile-time, атем код считается доказанным.
Хорошо, пусть мы считаем что все необходимые типы порождены во время компиляции. Но в C++ мы и такого сказать не можем.
V>К тому же, берем дотнет, если a и Tuple будут value-type, то будет сгенерированы заново генерик-методы.. а это хана.
Я привел пример того что не позволяет система типов C++, но ты опять скатился к производительности. V>Я бы предложил для этого алгоритма эмулировать АлгТД, и не порождать ничего в рантайм.
Т.е. вместо Queue<T> и Queue<Tuple<T,T>> использовать что-то вроде Queue<std::vector<T>> или что-то вроде?
V>Да, конечно же O(1), время фиксированное, это я не то написал. Двусвязные списки как раз и нужны для операций на обоих концах за O(1).
Вот если бы они еще были иммутабельными
S>>Я тут не собирался рвать никакие очереди. Я привел пример структуры данных, которая реализуется на генериках и используется в рантайме. Но с удовольствием посмотрю на функциональную (неизменяемую) наколеночную очередь, которая порвет O(1) хотя бы алгоритмически
V>Ну так когда говорят "порвать многократно", то речь об коэф. при O(x).
Ты пропустил то что очередь неизменяемая?
S>>По-моему ты не разобрался в этой структуре данных. Она рассчитана на двухстороннюю выборку. И даже на логарифмическое обновление в середине.
V>Справедливости ради, сразу стало ясно, что структуры на immutable-элементах, а их без GC реализовать нереально.
Слишком сильное утверждение. Вполне себе работаю с иммутабл списком без GC. V>Именно поэтому я чуть отошел от конкретного алгоритма и высказался в том плане, что алгоритмы так или иначе надо брать, подходящие для инструмента. Если задача стоит в обычной двухсторонней очереди, то она давно решена для императивных языков.
А если задача в неизменяемой очереди? Впрочем, ее тоже можно решить без рекурсивного полиморфизма (см предыдущие главы той же книги). Только там вычислительная сложность будет уже не O(1), хотя те решения работают быстрее чем обсуждаемое по словам автора.
V>Насчет навигации в центр за время логарифм — приоритетные очереди в C++ как раз делают через std::map. Берется составной ключ, где одна составляющая приоритет, другая — монотонный номер (напр. тики процессора). В движке для конференций на C# тоже похоже делали, но на упорядоченном массиве (бо средняя длина очереди сообщений была около десятка). Т.е. задача-то известная, как и способы решения.
Жаль, что не подойдет там где нужна неизменяемая очередь.
S>>В том что инструмент накладывает ограничения на используемые алгоритмы — я согласен. В том что инструмент является определяющим при выборе алгоритмов — нет.
V>Является, к сожалению. Пока что очень неудобно разрабатывать проекты так, чтобы был сразу десяток инструментов доступен из-за плясок с сопряжением технологий. Берется один, максимум два инструмента, и приходится затем плясать в выбранных рамках в любой микро-задаче. Удачность выбора — второй вопрос, бо идеальных технологий и серебрянной пули не бывает.
Взять мой текущий проект — выбора инструмента практически не было. Несколько платформ, другие факторы (и человеческие), в итоге — C++. Но выбирать алгоритмы и структуры данных я могу. И вполне успешно использую местами совсем не характерные для инструмента неизменяемые структуры данных и алгоритмы.
Здравствуйте, vdimas, Вы писали:
V>В реальной жизни переносимость на уровне исходников достаточна.
Когда как. Если слой взаимодействия с платформой тоненький — можно и пережить. Но так бывает далеко не всегда.
V>У джавы когда-то наблюдал под разные платформы шли разные инсталляхи аппликух.
Потому что бутстраппер, создание ярлыков, регистрация анинсталлеров и тому подобные действия для каждой платформы разные.
V> Да еще каждая с собой тащит свою версию фреймворка
Это скорее плюс, чем минус.
... << RSDN@Home 1.2.0 alpha 5 rev. 1537 on Windows 7 6.1.7601.65536>>
Здравствуйте, MxMsk, Вы писали:
CS>>Пора переходить к конкретике. MM>Справедливости ради, конкретики нет с обеих сторон. Нужно обсуждать конкретные решения по части .Net и WPF, которые принимала команда Evernote.
У эвернота проблемы точно не с впф. У них уи как был поделкой, так и остался поделкой. Просто кажется, что на впфом занимались сиплюсники которые не в курсе дотнета. Да и в с++ они так себе. После того как евернот начал валиться с Access Violation, я тупо забил на него.
We know developers are hungry for information about native development. The GoingNative conference aims to provide current technical information to as many people as possible.
Register now!
GoingNative 2012 is a 48 hour technical event for those who push the boundaries of general purpose computing by exploiting the true capabilities of the underlying machine: C++ developers. Distinguished speakers include the creator of C++, Bjarne Stroustrup, C++ Standards Committee Chair, Herb Sutter, C++ template and big compute master, Andrei Alexandrescu, STL master Stephan T. Lavavej, and more! Official agenda will be released over the next month or so. Join us!
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Я вот, не знаю, будет ренессанс, не будет ренессанса, или [не]будет, но только в рамках MS. Но вот MS говорит о чём-то загадочном:
А что тут загадочного? VCшники решили устроить у себя междусобойчик. Ты участвуешь?
... << RSDN@Home 1.2.0 alpha 5 rev. 1537 on Windows 7 6.1.7601.65536>>
Здравствуйте, AndrewVK, Вы писали:
ГВ>>Я вот, не знаю, будет ренессанс, не будет ренессанса, или [не]будет, но только в рамках MS. Но вот MS говорит о чём-то загадочном:
AVK>А что тут загадочного?
Название странное. Я бы сказал — необычное.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
G>>>Для моих задач быстродействия linq более чем хватает V>>Дык, может это ключевое? Что же ты пытаешься тогда за всех расписываться? G>Я зенимаюсь тем же, чем и тысячи других программситов, значит им тоже. А ты наверное один такой уникальный, или на пару с ГВ, кому быстродейтсвия не хватает категорически, хотя что за задачи — хз. Ни ты ни он не колетесь.
Обычные задачи с приличным объемом данных и никакой магии. Если есть млрд айтемов, то лишние 100тиков на обработку ~30сек задержка, лишний байт — расход 1ГБ оперативки. Добавь сюда немножко активных клиентов, жесткие ограничения на время отклика системы и коктейль готов —
в дотнете перестает устраивать абсолютно все.
Поэтому и рулит PHP, а доля ASP.Net всё еще смехотворна.
57 for против 706 foreach, и это еще не считая linq. 
