R>видимо человек услышал про то, что .НЕТ хорошо дружит с SOAP'ом, а что SOAP по объему своих текстовых данных превышает во много раз бинарный поток — это и ежу ясно (и на этот SOAP огрызаются те, кто не подумав решил его использовать там, где ему не место... Была тут ветка на РСДН про XML с гневными эмоциями на него.). Он прежде всего сделан для передачи данных через фаерволы (та же Ява с SOAPом использует аж бегом). Если критичен траффик — свой алгоритм сжатия или еще какой-нибудь и вперед. .НЕТ конечно тут не при чем.
Даже в случае SOAP никто не мешает настроить веб-сервер так, чтобы он гнал SOAP трафик сжатым (это поддерживается на уровне HTTP -- трафик сжимается методом deflate). В этом случае не думаю, что трафик будет сильно отличаться от изначально бинарного
Здравствуйте, VladD2, Вы писали:
R>>А чему же ещё там быть критичным? Если тот же 7zip переписать под дотНЕТ, то архивировать он станет здорово дольше. Т.е. вместо 2-х часов будет работать, скажем, три. Это уже очень неприятно. Но это пример из повседневности. А вот если обсчёт какой-то задачи будет идти вместо 2-х месяцев — три, то это уже большие деньги. В таких задачах дотНЕТ действительно делать нечего.
VD>Квака подойдет для сравнения? Тогда воспользуйся поиском. Я тут как-то приводил результаты своих тестов. Скорость работы кваки откомпилированной под дотнет практически такая же, что в машинных кодах. Так что это выводы на ошибочных предпосылках.
Ее что, просто перекомпиляли под MC++? А чей хип она использует? Если просто перекомпиляли — то C++, тогда если ее переделать под GC то и получим требуемые тормоза. Бужет заметно, когда при FPS ~40 (а для хорошей сетевой игры столько и нужно), игра привстанет даже на 0.1сек.
Здравствуйте, Nick Notabene, Вы писали:
NN>Здравствуйте, oRover, Вы писали:
R>>Здравствуйте, Nick Notabene, Вы писали: NN>>>2oRover — SOAP — это как-то связано с мылом ??? )
R>>с мылом? Я про мыло где-то что-то говорил?
NN>Это была неудачная шутка. Что такое SOAP и XML я себе примерно представляю. Гыгы.
я просто не понял, что ты имел ввиду
NN>>>А если серьезно — траффик действительно растет на 10-15%. Я не разбирался подробно. Но SOAP я не использую.
R>>а что он так слабо растет? Я думал, больше будет расти. Никто не обещал, что это будет более компактный способ передачи. Сам подумай, что меньше по объему — бинарные или текстовые данные.
NN>Еще раз говорю — Я НЕ ИСПОЛЬЗОВАЛ SOAP. Смысла нету. Бинарные данные. 10-15% оверхеда, как тут кто-то красиво выразился.
так откуда ты знаешь, что траффик растет на 10-15% если не пробовал?
Хотя соглашусь с тобой, ты угадал (вычитал в умной книжке) — растет. Но он не для того, чтобы гонять данные.
R>>видимо человек услышал про то, что .НЕТ хорошо дружит с SOAP'ом, а что SOAP по объему своих текстовых данных превышает во много раз бинарный поток — это и ежу ясно (и на этот SOAP огрызаются те, кто не подумав решил его использовать там, где ему не место... Была тут ветка на РСДН про XML с гневными эмоциями на него.). Он прежде всего сделан для передачи данных через фаерволы (та же Ява с SOAPом использует аж бегом). Если критичен траффик — свой алгоритм сжатия или еще какой-нибудь и вперед. .НЕТ конечно тут не при чем.
G>Даже в случае SOAP никто не мешает настроить веб-сервер так, чтобы он гнал SOAP трафик сжатым (это поддерживается на уровне HTTP -- трафик сжимается методом deflate). В этом случае не думаю, что трафик будет сильно отличаться от изначально бинарного
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, mikа, Вы писали:
M>>Будут-будут. Тут народ говорил, что и серверные приложения на НЕТе не пишутся. Но когда им мягко объяснили, что пора просыпаться после пятилетней спячки и показали реальные примеры, как-то затихли сразу
A>Агащазблин. A>Тетрис может на Нете и напишут, а 3Д шутер (если не считать того Владовского квейка у которого нетовским было только окошко messages) фигушки. A>Игра критична и по скорости выполнения (и тут не то что 20-30, тут 5% важны) и по объёму расходуемой памяти. A>Стратегии типа Heroes of Might and Magic может ещё и напишут, а симуляторы уже врядли. A>Так что с играми вы торопитесь
Здравствуйте, Nick Notabene, Вы писали:
NN>Еще раз говорю — Я НЕ ИСПОЛЬЗОВАЛ SOAP. Смысла нету. Бинарные данные. 10-15% оверхеда, как тут кто-то красиво выразился.
Это становится уже забавно. И после этого ты утверждаешь, что скорость выполнения программ на С# медленнее, чем на С++
NN>Видите ли, я совершенно согласен с идеей о том, что язык формирует мышление.А программма, как не крути, продукт мысли, а не ручек. И если она кривая, то именно из-за способа мышления, сформированного в данном случае языком программирования. Не стоит забывать, что у реальных машин есть такая вешь, как память — чревато.
Даже отвечать не буду. Бред и демагогия, ничем не подкрепленная.
Здравствуйте, Nick Notabene, Вы писали:
NN>Хочу заметить, что тут не совсем правильно использовать GetSystemTime, поскольку эта функция срабатывает с разной скоростью. Проще и точнее имхо GetTickCount().
Результат только ухудшился. 16.672.
NN>Да, а где delete[] arr ?
Думаешь, это повлияет на результат выполнения теста С++ в лучшую сторону?
NN>И операций с плавающей точкой тут нет и в помине, а речь шла преимущественно о них.
Читать надо лучше. Речь шла о тесте, который предложил adontz.
Здравствуйте, Nick Notabene, Вы писали:
NN>На C# или МС++ — нет, не писал. Большие. И наверно уже не буду. А что такое кстати — большой проект ?
Большой проект — это большой проект. Так сойдет? (не хочу писать не по-теме)
NN>Вот вы, mika, уже сделали свой первый большой проект на .Net ? Который не крутится у вас под рукой, обеспечивая ваш девелопт энваремент, например, а поставляется реальному заказчику ?
Мой первый проект публичного пользования. Главные части храняться на сервере, так что он суппортяться. Клиентские части на С++ написаны. Но там логики было мало, так что оправдывает. Сейчас делаю продук с приватным типом использования (опытный вариант). Полностью на НЕТ. Узких мест не вижу. Скажу лишь одно, в начале нужно тесты делать, а не хватать все то, что ярко блестит.
NN>У меня есть комплекс из трех основных систем. Первая регистрирует данные, показывает их оператору,тарирует и пишет файлы истории. Вторая подситсема делает им матобработку — сглаживание, тренды, фильтрацию и прочие прелести; и готовит макеты оформления. Третья система загоняет файлы в БД, и потом с этой БД работает — карты строит, статистику кажет, выборки формирует для корпоративной БД. Каждая система имеет модульную структуру, и состоит из нескольких приложений, которые взаимодействуют через пайпы (если речь идет о оперативной передаче данных) или через файлы (если речь идет о графах обработки). Это достаточно большой для вас проект или нет ?
Честно говоря, не хочу вдаваться в анализ. С виду — довольно приличный. Так что, соглашусь.
NN>Естествено, я его делал и делаю не один. Но так уж сложилось, что веду его я; особенно нагружают вопросы взаимодействия модулей, но это решаемо.
Не имеет значения. Мы рассматриваем проект в купе, а не что ты там делал.
NN>Так вот, все сделано на С++ — большая часть на VC6, простые интерфейсные программы на Бильдере, самые старые — на BC++ 5.0. Для работы с данными используются классы STL и частично boost; в алгоритмах обработки тот же STL, boost и свои библиотеки, которых за последние 7 лет скопилось немало. Интерфейс — большая часть контролов переделана из MFC, или взяты готовые библиотеки. БД — ODBC в чистом виде, больше ничего так и не пригодилось. Библиотеки, где сложена вся арифметика, компилятся Intel C++ 5.5 ( 6-й есть, но пиратский, так что считаем, что он не используется).
Чего вы только не поиспользовали.
Когда я писал на сях я использовал обычно такую комбинацию. STL + WinAPI, ATL (COM). MFC + STL. Нравилась мне стандарт библиотека, так что я ее практически везде использовал. Удобна до жути. Это сейчас она мне кажеться корявым монстром.
NN>Есественно , когда появился дотнет, первой реакцией было отторжение. Вполне понятно. Потом — как все здорово. Те преимущества, про которые вы говорите, достаточно очевидны и бросаются в глаза; кроме того, очень просто работать с COM и БД; большое количество готовых к употреблению компонент; GDI+ — красивая штучка, тоже много нового и готового, наконец-то стейтлост модель рисования. NN>Соблазн — хотя бы часть сделать на дотнет, особенно то, где уже накопилось много нужных изменений; настолько, что имеет смысл приложение переработать капитально.
А вот и зря. Работает — пусть работает. Вам бы вообще с НЕТом не связыватся. А вы на нем дырки латать решили. Конечно, к его минусам добавились и ваши. Получилось не кузяво. Соответственно, свалили все на НЕТ. Крайний ведь должен был быть.
NN>И что ? Потери квантов, потому что система занимается чертечем три секунды. Мусор убирает. Или тряпочкой чего-то полирует. NN>Раздражение интерпретаторов, потому что приходится ждать там, где раньше ждать не приходилось.GDI+ — вообще редкостный тормоз, особенно когда дело доходит до большого количества полилайнов и отрисовки без мерцания.
Ну, тормозной сам по себе GDI. Так что уж не надо особо ругать его старшего брата. Правда, я так понял, что в вашей системе графики не особо. Где же вы умудрились GDI+ использовать?
Я как то работал с системой, у которой был свой графический интерфейс, основанный на DirectX. Так как графики там было до жути, это был самый эффективный способ ее вывода. Так что, скорее всего, вы изначально пошли не правильно, поставив все на GDI. Хотя, опять же повторюсь, если вы у вас ее много.
NN>Не справляется старый Celeron 1200 ? Не беда, купим P4 2.8 HTT. И заказчику посоветуем. NN>Купили, все равно тормозит.
Так чего у вас там много, графики или вычислений. Если первого, смотри выше, если второго — значит у вас что то не так с алгоритмами.
NN>Спрашивается, нах это надо ? Идем дальше, смотрим на это большое количество готовых унифицированных библиотек. Во-первых, как вами было справедливо отмечено,mika, они преимущественно предназначены для написания текстовых редакторов и мордочек запросов к БД. Как не старайтесь, но из набора запчастей для трактора не соберешь истребитель — только после продолжительной обработки напильником. Во-вторых,библиотеки от MS никогда не отличались качеством и скоростью, и в этом случае традиция свято соблюдается. JIT-компилятор может здорово оптимизировать вычисления, поскольку работает с конкретным процессором — но он этого не делает. Почему — хбз; те небогатые опции оптимизации, которые я нашел, я выставил.
Подожди. Так вы на НЕТ какую часть то написал. По твоим словам, вы там все портировали. Ну, дык, ясен пень, тебе же тут уже говорили, где ошибка. Делай вычисления на MC++. MC++.
NN>Многострадальный DataGrid — вообще полное убожество. Столько плясок вокруг старого избитого грида, и такой плачевный результат.
Ага, тоесть тут вы работали с GDI? Он же вроде бьыстро все отрисовывает.
NN>Скорость разработки, mika, это не все. Вы меня простите, но это дешевка. Быстро написанные программы, выброшенные на рынок, которые требуют потом постоянных патчей — это дешевка. Можно взять секретаршу и обучить ее работать на дотнете — это достаточно просто; и получать программы того же качества, которые сейчас лепят бывшие С++ программисты, с теми же трудозатратами, и гораздо дешевле, кстати.
Заметь, это ты сказал, что критерий создания ППС состоит из одного фактора, из скорости. Я же утверждал, что это один из многих.И утверждаю, что если скорость разработки увеличить (разумееться ничем не теряя), то от этого будет только лучше. Почему тебе это не нравиться?
NN>Нет конечно. Совершенно правильно замечено, что для каждой задачи — свои средства разработки. Все, что я хотел сказать — что дотнет плохо подходит, или не подходит вовсе для достаточно широкого класса задач. Не могу сказать, что работаю с дотнетом порядочное количество времени, но год уже за ним слежу достаточно пристально. Использовать его для работы даже не пытаюсь, но экспериментирую постоянно. И реального применения ему пока не вижу.
А почему бы тебе тогда не привести результаты своих тестов. А то уж совсем не понятно, зачем ты вообще начал этот топик. Ты что то хотел узнать или просто потрепаться?
NN>>>Думаю да. Фреймворк, фреймворк и опять фреймворк. И куча шуршащей блестящей шелухи сверху, которая маркетинг.
M>>Я так и думал. Винда масдай, линух рулит.
NN>А вот это уже я не понял. Про линух не говорил ни полслова. Mika, уж будьте любезны, поясните пожалуста. не оставьте прозябать в темноте невежества — что еще такое дотнет, кроме фреймворка ???
Это была аналогия. Как ты думаешь, выражение
шуршащей блестящей шелухи сверху, которая маркетинг
разительно отличаеться от высказывания "Винда масдай, линух рулит."?
Здравствуйте, oRover, Вы писали:
R>Здравствуйте, IT, Вы писали:
R>люди, что в С++ надо подключить чтобы std использовать. А то тесты сравнить хочется, а я на С++ не программлю
Здравствуйте, adontz, Вы писали:
A>Но что б поменялись местами? Запускал релизы с включённой оптимизацией. Ты студию и прочие программы выключил? А то слушая ВинАмп не тестируют
Не, ты подожди. Я вообще запускал дебаг версии с включенным инетом, винампом и прочим барахлом, так как я обычно запускаю все свои программы. В реальных жизненных условиях так сказать А так получается, что в идеальных условиях C++ быстрее, а по жизни — зависит.
В общем, все эти тесты — чушь. Где-то работает лучше один оптимизатор, где-то лучше другой, а настоящий результат зависит от используемых алгоритмов. А 10%-20% — это всё ерунда. Если бы разница была в разы, тогда да, а так — плюс минус трамвайная остановка.
A>
delete[] arr;
A>Тоже мне, привык к GC Здесь каждый за сам убирает свой мусор!!!
Да, блин, подловил Вот оно тлетворное влеяние коллекторов
Но, между прочим! Ты в курсе, что коллектор на мелких объектах работает в 3-4 раза быстрее чем C++ хип? Или это не в счёт?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Nick Notabene, Вы писали:
NN>Хочу заметить, что тут не совсем правильно использовать GetSystemTime, поскольку эта функция срабатывает с разной скоростью. Проще и точнее имхо GetTickCount().
Думаю, что на 6-8 секундах эта разница не будет заметна даже в микроскоп.
NN>Да, а где delete[] arr ?
Я уже обсыпал всю голову пеплом
NN>И операций с плавающей точкой тут нет и в помине, а речь шла преимущественно о них.
Как была поставлена задача, так я её и решил
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, oRover, Вы писали:
R>а что, играет роль версия С#? Как тут правильно сказал Андрей, версия IL не менялась. Или он более качественно компилирует в IL?
Ну да, вероятно, компиляция в МСИЛ несколько меняется. По крайней мере определенная разница между C# 1.0 и C# 1.1 есть.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Здравствуйте, oRover, Вы писали:
R>>а что, играет роль версия С#? Как тут правильно сказал Андрей, версия IL не менялась. Или он более качественно компилирует в IL?
ВВ>Ну да, вероятно, компиляция в МСИЛ несколько меняется. По крайней мере определенная разница между C# 1.0 и C# 1.1 есть.
Компиляция в МСИЛ? Этож первый процесс компиляции. Он в тестах не учавствует. А вот JIT мог измениться.
Здравствуйте, mikа, Вы писали:
M>Компиляция в МСИЛ? Этож первый процесс компиляции. Он в тестах не учавствует. А вот JIT мог измениться.
Да, но от версии к версии компиляция в МСИЛ все равно наверное меняется. И на скорость по идее должно влиять.. Что бы в противном случае значил загадочный флажок оптимизации в настройках компилятора?
Бужет заметно, когда при FPS ~40 (а для хорошей сетевой игры столько и нужно), игра привстанет даже на 0.1сек.
)
Если нам не помогут, то мы тоже никого не пощадим.
