Здравствуйте, gandjustas, Вы писали:
G>>>А по поводу GC — вам стоит почитать как он работает, просто так он шерстить 100 метров не будет. C>>При полном цикле GC — будет. Поэтому GC абсолютно не совместим со swap'ом. G>Что такое полный цикл GC?
Полный сбор всего мусора, включая обычно и упаковку за-tenure-еных объектов.
Да и периодический mark&sweep в tenured куче тоже удовольствия не доставит.
G>Как вызвать полный цикл?
Обычно он сам вызывается через некоторое время.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
G>>>>А по поводу GC — вам стоит почитать как он работает, просто так он шерстить 100 метров не будет. C>>>При полном цикле GC — будет. Поэтому GC абсолютно не совместим со swap'ом. G>>Что такое полный цикл GC? C>Полный сбор всего мусора, включая обычно и упаковку за-tenure-еных объектов.
C>Да и периодический mark&sweep в tenured куче тоже удовольствия не доставит.
G>>Как вызвать полный цикл? C>Обычно он сам вызывается через некоторое время.
Есть же поколения. Сборщик мусора не постоянно всю память шерстит. Плюс есть дифференциация по размеру объектов.
Схема в меру эффективна. Всё неплохо оптимизировано.
У Вас такие специфичные задачи, что сборка мусора доставляет проблемы?
Здравствуйте, WizardBox, Вы писали:
C>>Обычно он сам вызывается через некоторое время. WB>Есть же поколения.
Есть. И что, в них собирать мусор не надо?
WB>Сборщик мусора не постоянно всю память шерстит.
Старшие (tenured) поколения обычно как раз постоянно в фоне проверяет конкурентный mark&sweep.
WB>Плюс есть дифференциация по размеру объектов. Схема в меру эффективна. Всё неплохо оптимизировано.
Оно ничем не поможет.
По факту — никакие эффективные GC не живут со swapping'ом. А GC, совместимые со swap'ом, не живут на обычных задачах.
WB>У Вас такие специфичные задачи, что сборка мусора доставляет проблемы?
Скажем так. Как работает мусоросборщик в Java я знаю на уровне ассемблерного кода, использующегося для установки барьеров.
Здравствуйте, gandjustas, Вы писали:
G>ИМХО одинаковые, из заметных на глаз отличий — пара дополнительных инструментальных окошет в фотошопе, другое раположение кнопок инструментов и другой выбор цвета.
Да что же вы такое все курите-то, а?! Paint.Net сравнивать с Photoshop-ом — это примерно как ВАЗ 7-й с БМВ 7-м — типа четыре колеса и руль и ехать может...
Здравствуйте, Сергей, Вы писали:
С>Здравствуйте, gandjustas, Вы писали:
G>>Улыбнуло. WPF умеет работать с шейдерами и рисовать с помощью аппаратного ускорения, что Qt может предложить по этому поводу?
С>Qt может предложить использование аппаратного ускорения посредством OpenGL на Windows, Linux, MacOS и портативных/встраиваемых устройствах.
ой не надо! разрабатывал я на этом qt терминал видеотелефонной связи... там даже видео прилично под линуксом не выведешь — надо оторвать себе все что болтается.... И то ушли на чисто X-овые функции.
Здравствуйте, March_rabbit, Вы писали:
M_>Здравствуйте, Сергей, Вы писали:
С>>Здравствуйте, gandjustas, Вы писали:
G>>>Улыбнуло. WPF умеет работать с шейдерами и рисовать с помощью аппаратного ускорения, что Qt может предложить по этому поводу?
С>>Qt может предложить использование аппаратного ускорения посредством OpenGL на Windows, Linux, MacOS и портативных/встраиваемых устройствах. M_>ой не надо! разрабатывал я на этом qt терминал видеотелефонной связи... там даже видео прилично под линуксом не выведешь — надо оторвать себе все что болтается.... И то ушли на чисто X-овые функции.
Ну это больше проблемы линукса. Почему-то мне кажется что с остальными гуишными фреймворками ситуация не чуть не лучше.
Здравствуйте, March_rabbit, Вы писали:
С>>Qt может предложить использование аппаратного ускорения посредством OpenGL на Windows, Linux, MacOS и портативных/встраиваемых устройствах. M_>ой не надо! разрабатывал я на этом qt терминал видеотелефонной связи... там даже видео прилично под линуксом не выведешь — надо оторвать себе все что болтается.... И то ушли на чисто X-овые функции.
Во-первых, про видео я ровно ничего не говорил. Во вторых, вряд ли ты на этом qt разрабатывал.
Здравствуйте, Сергей, Вы писали:
С>Здравствуйте, March_rabbit, Вы писали:
С>>>Qt может предложить использование аппаратного ускорения посредством OpenGL на Windows, Linux, MacOS и портативных/встраиваемых устройствах. M_>>ой не надо! разрабатывал я на этом qt терминал видеотелефонной связи... там даже видео прилично под линуксом не выведешь — надо оторвать себе все что болтается.... И то ушли на чисто X-овые функции.
С>Во-первых, про видео я ровно ничего не говорил. Во вторых, вряд ли ты на этом qt разрабатывал.
гыгы. это-то я понимаю, что БУДУЩАЯ версия всегда лучше текущей
но вот когда они ее выпустят — станет ли она лучше текущих?
S>"gandjustas" <67312@users.rsdn.ru> wrote in message news:3250476@news.rsdn.ru...
>> DV>Если вернуться к памяти, то вы опять же не правы. У меня к примеру есть приложение в котором свободная память — это очень важный ресурс — чем больше доступной памяти — тем большую сцену можно загрузить. Тем быстрее можно делать вычисления. С большим количеством данных можно работать. И терять этот показатель только из за недостатков выбранной платформы — это смешно. >> Совсем не смешно. Месяц работы программиста, который будет сэкономлен при использовании при использовании современных средств, стоит гораздо дороже, чем пара гигов памяти.
S>Или чем 20 гигов памяти, да? А ниче, что железо, которое 20 гигов умеет, уже стоит на порядок дороже обычного?
А давайте прикинем, что надо места на винте 100Тб? Это ж сколько бабла потребуется на такую железяку?
И сделаем вывод — прекращаем выпуск HD видео.
>> Об аппетитах программы по памяти стоит беспокоиться только если вы хотите своим продуктом охватить очень широкий рынок, например от нетбуков до серверов.
S>да-да, пара гигов * 10000 персоналок — скока стоит? Все еще дешевле месяца работы?
гм. что за арифметика?
А ничего, что в каждой персоналке стоит процессор ценой от 2 тыщ и винчестер с такой же ценой? По сравнению с 1200 за 2Г средненькой ДДр2 совсем другие деньги получаются, не так ли? А если вспомнить, что мониторы начинаются с 5 тыщ....
Ну и к чему эти подсчеты были?
S>"gandjustas" <67312@users.rsdn.ru> wrote in message news:3250615@news.rsdn.ru...
>> S>Тут на самом деле можно поспорить. Я вот например не вижу, с чего бы это в масштабном проекте на дотнете писалось быстрее чем на плюсах. >> Плотность ошибок в коде мало зависит от языка. С# более высокоуровневый, чем C++, поэтому для реализации той же функциональности требуется написать меньше, а следственно ошибок в программе будет меньше.
S>Да-да, даже наследования реализации нету — а кода меньше писать, ага.
на самом деле, в плюс .Net говорит хотя бы то, что там нет НЕСКОЛЬКИХ КЛАССОВ СТРОК. В плюсах каждый более-менее крупный проект заводит свои классы. И развлекаешься каждый раз, конвертя из одного в другой формат.... А когда начинается юникод, тогда все становится еще веселее.
Чтобы не быть голословным укажу на мозиллу: там 5 классов строк или около того! Добавим сюда std::string, std::wstring, char *, QString. Уже 8 форматов. Бред.
>> А .NET вам в случае ошибки четко покажет где она произошла, и выдаст адекватный stack trace. S>Адекватный стек трейс у меня на плюсах выдается уже лет десять.
особенно здорово копаться в стеке после того, как кто-нибудь пройдется по памяти и свалит какой-нибудь внутренний указатель std::string...
вот тут начинаешь понимать, что доступ к памяти — это лишнее
или, когда система свалится в каком-нибудь траверзе boost-а. Вот тогда стек оказывается очень полезен: трасса начинается с цикла обработки событий или какого-нибудь левого процесса. И ищи по всей программе: кто же сгенерил-то это событие или вызвал траверс?
>> Кроме того управляемая среда позволяет вам не париться по поводу выделяемой памяти,
S>Не парится по поводу выделяемой памяти в моем случае возможно только при переходе на x64 — чего в силу некоторых особенностей лицензионной политики MS пока не случилось. Трех гигов в вин32 хватает с трудом.
Не знаю, у нас все разработчики на винде сидят на 32х битных платформах. Я под линуксом себе 8Г вставил, чтобы работать с несколькими виртуалками одновременно.
>> Кстати, вы на .NET работали? S>Не особо много — не понравилось.
эту поговорку мы уже знаем (про устриц)
>> S>Наоборот, если быстродействие важно — с ним убъешся просто, с дотнетом этим. Так что утверждение "Месяц это минимум" неплохо бы сначала обосновать. >> А вы поищите сравнения производительности на форуме. Нету супер-тормозов, кроме того программы на .NET параллелятся в разы проще.
S>Я не говорю про супер-тормоза, оно просто все равномерно работает раза в два медленнее. И иногда — большие провалы из-за каких-то специфических особенностей контейнеров. Не, может их и можно забороть, но на это время надо.
ээээ. напомню: быстродействие ПО зависит на 95% от алгоритмов.
У нас линуксовый проект написан процентов на 90 на С++, но благодаря мозилле и тому, что много логики написано на JS, тормозит основательно. Беру виндозный вариант этого же софта — не заметил замедления по сравнению с линуксовым, хотя виндозный на половину почти на .Net писан.
Здравствуйте, Cyberax, Вы писали:
E>>А почему это недостаток? Для переносимого GUI, возможно, это вообще самый разумный путь... C>На Mac'е, например, QT-шные приложения выглядят не совсем нативно. На Windows это тоже очень чувствуется.
Это не проблема собственной отрисовки. Вон, WPF вполне неплохо под винду мимикрирует при необходимости.
Здравствуйте, March_rabbit, Вы писали:
M_>У нас линуксовый проект написан процентов на 90 на С++, но благодаря мозилле и тому, что много логики написано на JS, тормозит основательно. Беру виндозный вариант этого же софта — не заметил замедления по сравнению с линуксовым, хотя виндозный на половину почти на .Net писан.
Это мне показалось, или ты сейчас сказал, что .Net по сравнению с JS не тормозит?
Здравствуйте, hattab, Вы писали:
M_>>У нас линуксовый проект написан процентов на 90 на С++, но благодаря мозилле и тому, что много логики написано на JS, тормозит основательно. Беру виндозный вариант этого же софта — не заметил замедления по сравнению с линуксовым, хотя виндозный на половину почти на .Net писан.
H>Это мне показалось, или ты сейчас сказал, что .Net по сравнению с JS не тормозит?
Здравствуйте, criosray, Вы писали:
M_>>>У нас линуксовый проект написан процентов на 90 на С++, но благодаря мозилле и тому, что много логики написано на JS, тормозит основательно. Беру виндозный вариант этого же софта — не заметил замедления по сравнению с линуксовым, хотя виндозный на половину почти на .Net писан.
H>>Это мне показалось, или ты сейчас сказал, что .Net по сравнению с JS не тормозит?
C>Показалось. Он сказал совсем другое.
Здравствуйте, criosray, Вы писали:
H>>Это мне показалось, или ты сейчас сказал, что .Net по сравнению с JS не тормозит?
C>Показалось. Он сказал совсем другое.
(про устриц)
