Здравствуйте, Eugeny__, Вы писали:
E> H>Есть такая фраза: прибор должен работать в кожухе, а не в принципе. Очень уместна, когда кто нибудь потенциалом размахивает. Коли JIT так хорош, чего же весь .NET за'ngen'еный вусмерть?
E> Наверное потому, что пока JIT еще так себе. Но согласись, что возможностей у него поболе. Он знает архитектуру и особенности системы, в которой работает. Он знает статистику исполнения — что чаще всего выполняется и что желательно оптимизировать, а на что забить. Вобщем, поле для действий широкое, но пока реализация еще не доведена до нужного уровня. Посмотрим, что дальше будет.
Ну да, в теории у джита все красиво, но только в теории. Время для оптимизаций сильно ограничено. Знание о системе тоже вопрос спорный, ведь производители компиляторов не бросаются оптимизировать джит под конкретные архитектурные возможности/особенности (такие, как размер кэша, наборы доп. инструкции и прочее) процессоров, а делают просто средненький вариант. И вряд ли что-то в этом плане будет меняться
E> Кстати, джава на закомпилена вусмерть(этот подход вообще не применяется, пре-компиляторы джавы вообще штука редкая). Но там своя специфика — зоопарк поддерживаемых систем и сотни популярных фреймворков — задолбаешься все в нативы компилить. Но тем не менее, джава весьма популярна, хоть и на серваках.
Во-во, в том-то и дело, что не на десктопе. Для серверов это вообще не сильно критично ведь за задержками сети любые задержки джита будут невидны
Здравствуйте, Eugeny__, Вы писали:
E> H>У меня не игровой комп, это да, всего лишь Phenom II X4 940BE 3.3GHz, 8Gb RAM (ATI Radeon 3300HD, на момент покупки мамки это было самое производительное встроенное видео). Как на таком железе вообще можно тормозить? Однако же факты штука упрямая
E> Странно это. А комп вполне может стать игровым, если в него втаращить более производительную видяху .
Я намеренно не стал брать дискретное видео. Этой видяхи для моих любимых игрушек хватает вполне, и дополнительный нагреватель воздуха себя не оправдает
E> H>У меня давным-давно была атишная карточка All-In-Wonder какая-то-там (с тв-тюнером). Там был прекрасный нативный софт, который отлично работал на моем Celeron 300MHz.
E> У меня как-то catalyst всегда вызывал легкое недоумение. Впрочем, производители железа частенько тянут страшненькие глючненькие утилитки с собой. Телефонный софт это вообще мрак. А что до АТИ — я вполне готов мириться с ихним софтом — железки мне их как раз наоборот, очень нравятся. На более слабых компах я просто убирал каталист из автозагрузки, сейчас пофигу — памяти дочерта, пусь себе висит.
У меня предпочтений по железу нет, были и ATI и NVidia, устраивали и те и другие, но вот касаемо софта... Нет, конечно кривость каталиста не будет стоп-фичей для покупки карточки на десктоп, но вот покупать нетбук (а ведь скоро выйдет APU Ontario) с атишным видео что-то страшновато.
Здравствуйте, Antikrot, Вы писали:
A>а какая нужна интеграция плюсового компилятора в плюсовый environment? он там просто выбирался вместо vc, если был "проинтегрирован". всё остальное использовалось что было.
Это уже отдельная тема. К делу не относящаяся. В прочем наверно не секрет, что VC6 шел с компилятором только отдаленно напоминающим С++ (стандарт). Ител в этом плане был сильно более продвинутый. Ну, и интеграция у него была тоже далека от идела. Реально без Томаты пользоваться его интелесеносом было трудно.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, hattab, Вы писали:
E>> Ну, вообще-то, на современных игровых компах(а нахрена не на игровых АТИ?) оно не тормозит совсем.
H>У меня не игровой комп, это да, всего лишь Phenom II X4 940BE 3.3GHz, 8Gb RAM (ATI Radeon 3300HD, на момент покупки мамки это было самое производительное встроенное видео). Как на таком железе вообще можно тормозить? Однако же факты штука упрямая
Ммм, меняю свое мнение. Таки в Линухе реально быстрее работает и грузится(а оно нативное) — видео, учтите, что это еще и при загруженном каптурере + тормоза конвертации(видно, что мыша отнюдь не плано перемещается). Виндовая версия таки менее отзывчивая — с 200-300 мс таки думает, а тут вообще мгновенно. Хотя я вообще, загружая дома линух, фигею, насколько он более быстрый(по юзеринтерфейсу), и это при том, что он стоит в файле(!!) на виндовом диске ntfs(C:\Ubuntu\ubuntu.<чего-то там>) — то есть, фс ext4 просто эмулируется в файлике на нтфс(мне влом искать диски, чтобы на реальный раздел поставить, а с флеша у меня мать грузиться не умеет ).
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>>Я так вроде начинал со сравнения BC 5 против VC 6. A>>в другой теме — да. а вот тут, чуть выше по ветке: A>>
A>>Контрвопрос — насколько меньше памяти потреблял компилятор от VC 4.2, 5.0 ? Опять же — от силы раза в 1.5, ну пусть 2. А предположить, что от 4.2 до 6.0 он не развивался, а тут уж прямо в гору пошел — как-то сомнительно
A>>никакого BC5 уже нет PD>Нет, конечно, ну и что ? Сравнивать нельзя ?
сравнивай, мне не жалко. только давай пока ограничимся vc
PD>>>В cl.exe еще и генерация кода под IA-64 засунута, и под другие платформы. Это просто разные куски компилятора(кодогенератора). A>>надо полагать, ты его изнутри видел? насколько я понял, это уже другой cl.exe будет PD>Ну и пусть. Синтанализатор останется без изменений, а кодогенератор можно в виде отдельной DLL сделать, по одной на каждый процессор.
не всё так просто. есть hw-specific интринсики, так что такие dll тебе придётся делать к каждой части компилятора, которая их затронуть может.
PD>И на IL тоже.
на IL, это если про MC++, там и в синтаксисе добавлено
A>>выше по треду: A>>
A>>Контрвопрос — насколько меньше памяти потреблял компилятор от VC 4.2, 5.0 ?
PD>Так что ? Вопрос-то тебе был, а не мне.
так вот я про компилятор и трындю, раз вопрос был
PD>Так, как я понял, -mcmodel исключена из списка.
mcmodel была приплетена в том обсуждении ввиду того, что ты сказал что в x64 только одна модель
PD>(вопрос в скобках — а она поддерживается вообще в VC++ ? Я что-то опций не нашел) Google в основном про GNU C++ пишет.
а хз. я про х64 в общем сказал. не уверен что она у кого под виндой есть. кстати, там в разных моделях адресация разная...
PD>Про шаблоны я ответил. Естественно, надо было это написать как следует, исправить ошибки. Но основной код был написан, я думаю, еще как минимум, в VS 4.2, потом его только исправляли и совершенствовали. PD>/CLR — туда же, куда и IA-64 и прочие MIPS. Отдельный модуль, тут мы вроде бы уже согласились.
уже сказал. отдельных модулей у тебя будет до жопы — он там не только в кодгенерации появляется.
PD>x64 — смените некоторые константы 4->8, кое-что поправьте и перекомпилируйте.
ага, "кое-что поправьте" ниче, что там вдвое больше регистров general и xmm, что влияет на оптимизатор (можно гораздо больше себе позволить. а уж сколько регистров в ia-64... ууу... отдельный модуль, да), exception handling другой и т.д.?
кстати, windows abi для x64 явно требует использовать xmm, так что совсем вынести simd в отдельный модуль будет не просто
PD>Я абсолютно не вижу, почему тут хорошо написанный код должен увеличиться в размере.
как нефиг делать. не скажу за vc, но одного удвоения количества регистров может хватить чтоб повлиять на оптимизатор в сторону увеличения размеров кода (например, больше развернуть цикл)
PD>Берем любую программу на С++ и перекомпилируем на x64.
ну так скомпилируй и выложи сюда результат
PD>Остальное. Да, это серьезно. Кодогенератор с тем же SIMD весьма серьезно отличается от кодогенератора для обычного x86. Тут спорить не приходится. PD>Но! PD>Эти все опции включаемые. И включаются они далеко не всегда. И даже когда включены, далеко не всегда реализуются. Можешь поставить SSEi, но это еще не значит, что ты ее получишь.
ха, если у тебя под виндой x64 и функции получают/возвращают плавточку, то получишь.
PD>Никто не мешает опять же оформить это в виде отдельной DLL. По сути ведь мы опять имеем то же самое — иной выходной язык. Можно x86 чистый,
это какой? 386DX?
если разбивать "по-твоему", будет столько этих dll, что тебе не понравится.
PD> иожно x64 чистый,
без sse практически нельзя
PD>Кстати, а в IA-64 часом нет той же векторизации в какой-нибудь упаковке ?
смотря что считать под упаковкой, но считай что есть. да там и без этого извращений хватит.
Здравствуйте, Eugeny__, Вы писали:
E__>"Неуправляемый код" звучит как-то стремно . Полагаю, лучше будет "не упровляемый"[а нативный].
А, черт. Читать "не управляемый" — ну надо же так ошибиться. Можете называть меня безграмотным неучем...
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, Eugeny__, Вы писали:
E> Ммм, меняю свое мнение. Таки в Линухе реально быстрее работает и грузится(а оно нативное) — видео, учтите, что это еще и при загруженном каптурере + тормоза конвертации(видно, что мыша отнюдь не плано перемещается). Виндовая версия таки менее отзывчивая — с 200-300 мс таки думает, а тут вообще мгновенно. Хотя я вообще, загружая дома линух, фигею, насколько он более быстрый(по юзеринтерфейсу), и это при том, что он стоит в файле(!!) на виндовом диске ntfs(C:\Ubuntu\ubuntu.<чего-то там>) — то есть, фс ext4 просто эмулируется в файлике на нтфс(мне влом искать диски, чтобы на реальный раздел поставить, а с флеша у меня мать грузиться не умеет ).
Кстати да, линуксовый гуй отзывчивее виндового. Жаль что у меня не срослось с Убунтой...
Здравствуйте, genre, Вы писали:
G>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Если поиск в БД на 4 Мб занимает минуту — программиста уволить с волчьим билетом, и все переписать. PD>>Я нечто подобное сам писал. Поиск в своем собственном файле (хочешь — назови его БД , хоть и не телефонов. Только поиск этот занимал не минуту, а 5-10 мсек. PD>>И память при этм не транжирил. Был там mmf на базу (она была примерно так 300 Мб), маппировались страницы, а больше никакой памяти и не выделялось. Зачем ?
G>У меня ощущение, что ты над нами издеваешься. G>"Третий раз объясняю, уже сам все понял, а они не понимают" (с) анекдот
G>Ну замени в моем тексте поиск на "сделать некую очень ресурсоемкую операцию" и 4Мб на 4Гб (пусть на винте лежат).
Тогда ответ прост. Пишите эту ресурсоемкую операцию, используя увеличенное количество ресурсов. Но сначала докажите, что она ресурсоемкая.
И если мне начнут доказывать, что поиск в БД на 4 Гб таков, что без этого увеличения затрат ресурсов идет 1 минуту — программиста уволить и все переписать.
Здравствуйте, Antikrot, Вы писали:
A>в процессе распаковки типа совсем память для "временных данных" не надо?
Надо. Распаковать, установить биты, удалить. От броузера не зависит.
PD>>потом SetDIBits (она DDB создает), а BITMAPINFOHEADER и массив байтов удалить A>и как там у неё с прозрачностью?
Встречный вопрос — а <img всегда рисуются с прозрачностью ? .
Ну а если она нужна и при этом per-pixel- например, посыпать голову пеплом и вернуть обратно 54 байта
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Но сначала докажите, что она ресурсоемкая.
Так как же тебе докажешь, если ты ничего слушать не хочешь? Читать не хочешь, оппонентов не слушаешь.
ПРо полмиллиона объектов на странице гмейла тебе написали.
Ссылку на новые возможности современных иде давали.
ПРо компилятор с++ рассказывали.
про исполнение js тоже.
А ты байку про "нарисовать картинку на экране" заводишь.
Здравствуйте, genre, Вы писали:
G>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Но сначала докажите, что она ресурсоемкая.
G>Так как же тебе докажешь, если ты ничего слушать не хочешь? Читать не хочешь, оппонентов не слушаешь. G>ПРо полмиллиона объектов на странице гмейла тебе написали. G>Ссылку на новые возможности современных иде давали. G>ПРо компилятор с++ рассказывали. G>про исполнение js тоже.
G>А ты байку про "нарисовать картинку на экране" заводишь.
Я дискуссию закончил. Свои аргументы изложил. Не нравится — имеешь полное право не согласиться. Все.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Тогда ответ прост. Пишите эту ресурсоемкую операцию, используя увеличенное количество ресурсов. Но сначала докажите, что она ресурсоемкая.
А ты хотя бы изредка читаешь что тебе пишут ?
Вот суммарно основные составляющие
1 JS V8
2 полмиллиона объектов
3 сотни килобайт скрипта и даже мегабайты не редкость
4 DOM, CSS — сложный рендеринг
5 экран увеличился в 5 раз по самой щадящей оценку, реально 10 раз это нормально
6 куча всяких абревиатур которые браузеры умеют сейчас и не умели раньше
Вопрос — все 6 пунктов вместе взятые могут являться ресурсоёмкой задачей или нет ?
GIF, JPEG и Турбопаскль оставь детям, ответь внятно — браузер которйы умеет перечисленные 6 пунктов, имеели ли он право с твоей точки зрения кушать по 100 и более мб памяти ?
Здравствуйте, hattab, Вы писали:
H> Гуй выглядит как говно, тормоза просто дичайшие, потребление ресурсов безумное.
Ну, от внешнего вида CCC-гуя я тоже не в восторге, но это дело вкуса. Насчет тормозов — не знаю, не заметил. А вот насчет потребления ресурсов ты, имхо, что-то путаешь. В свернутом виде CCC у меня потребляет 1.5 метра, что в 10 раз меньше, чем к примеру гуй к интеловскому драйверу видео на соседней машине, каковой интеловский гуй написан на С++, насколько я понимаю. В открытом виде да, CCC разворачивается до 30 мег, но кто ж такие вещи держит открытыми постоянно?
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Тогда ответ прост. Пишите эту ресурсоемкую операцию, используя увеличенное количество ресурсов. Но сначала докажите, что она ресурсоемкая.
I>А ты хотя бы изредка читаешь что тебе пишут ?
I>Вот суммарно основные составляющие
I>1 JS V8 I>2 полмиллиона объектов I>3 сотни килобайт скрипта и даже мегабайты не редкость I>4 DOM, CSS — сложный рендеринг I>5 экран увеличился в 5 раз по самой щадящей оценку, реально 10 раз это нормально I>6 куча всяких абревиатур которые браузеры умеют сейчас и не умели раньше
I>Вопрос — все 6 пунктов вместе взятые могут являться ресурсоёмкой задачей или нет ?
I>GIF, JPEG и Турбопаскль оставь детям, ответь внятно — браузер которйы умеет перечисленные 6 пунктов, имеели ли он право с твоей точки зрения кушать по 100 и более мб памяти ?
Дискуссию закончил, все аргументы изложил, и не раз.
Здравствуйте, Pavel Dvorkin, Вы писали:
I>>GIF, JPEG и Турбопаскль оставь детям, ответь внятно — браузер которйы умеет перечисленные 6 пунктов, имеели ли он право с твоей точки зрения кушать по 100 и более мб памяти ?
PD>Дискуссию закончил, все аргументы изложил, и не раз.
Ты ничего не изложил, хотя написал много текста.
Ни на один заданый вопрос тебе ты вобщем так и не ответил.
Здравствуйте, lazymf, Вы писали:
l> H> Гуй выглядит как говно, тормоза просто дичайшие, потребление ресурсов безумное.
l> Ну, от внешнего вида CCC-гуя я тоже не в восторге, но это дело вкуса.
Классик-контролы под Аэро выглядят ужасно, как это может кому-то нравиться я не понимаю.
l> Насчет тормозов — не знаю, не заметил. А вот насчет потребления ресурсов ты, имхо, что-то путаешь. В свернутом виде CCC у меня потребляет 1.5 метра, что в 10 раз меньше, чем к примеру гуй к интеловскому драйверу видео на соседней машине, каковой интеловский гуй написан на С++, насколько я понимаю. В открытом виде да, CCC разворачивается до 30 мег,
Тут все просто, запускаешь ProcessExplorer и считаешь сам (PrivateBytes):
Процесс MOM.exe — 40Mb;
Процесс CCC.exe — 54Mb (когда диалог закрыт), 71Mb (когда диалог открыт).
l> но кто ж такие вещи держит открытыми постоянно?
H>Тут все просто, запускаешь ProcessExplorer и считаешь сам (PrivateBytes):
H>Процесс MOM.exe — 40Mb; H>Процесс CCC.exe — 54Mb (когда диалог закрыт), 71Mb (когда диалог открыт).
l>> но кто ж такие вещи держит открытыми постоянно?
H>Вопрос так не стоит. Вопрос стоит иначе
: какого х..я простейшая утиль жрет столько памяти?
Сейчас — как минимум потому, что может. При даже не моих 8Г, а минимальных 4Г для игрового компа(а на неигровом этим утилитам грош цена) даже эта память — крохи. Хотя мне не удалось на х64 винде добиться 54 мб — в закрытом виде 1-4 мб(первое значение — private bytes, это после открытия и закрытия, если просто после загрузки — 1.5 мб), в открытом — около 50. Хотя по сравнению с линух версией таки притормаживает интерфейс. Ради прикола сейчас грузану Убунту, померяю память там.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, Eugeny__, Вы писали:
H>>Тут все просто, запускаешь ProcessExplorer и считаешь сам (PrivateBytes):
H>>Процесс MOM.exe — 40Mb; H>>Процесс CCC.exe — 54Mb (когда диалог закрыт), 71Mb (когда диалог открыт).
l>>> но кто ж такие вещи держит открытыми постоянно?
H>>Вопрос так не стоит. Вопрос стоит иначе
: какого х..я простейшая утиль жрет столько памяти?
E__>Сейчас — как минимум потому, что может. При даже не моих 8Г, а минимальных 4Г для игрового компа(а на неигровом этим утилитам грош цена) даже эта память — крохи. Хотя мне не удалось на х64 винде добиться 54 мб — в закрытом виде 1-4 мб(первое значение — private bytes, это после открытия и закрытия, если просто после загрузки — 1.5 мб), в открытом — около 50. Хотя по сравнению с линух версией таки притормаживает интерфейс. Ради прикола сейчас грузану Убунту, померяю память там.
Отчеты о текущем положении. Скрины делать влом, напишу текстом.
Винда(7, х64, видяха 5800 series, дрова с офсайта, скачанные и установленные хоть и с геморроем, но работают теперь на отл).
ССС — каталист контрол центр. Жрет 1-4 мегабайта памяти постоянно, загружен в памяти всегда. При загрузке явной может сожрать до 40 мб памяти, но через несколько секунд возвращается к 4 мб. При загрузке опций видео появляется новый процесс cccprev.exe, который жрет порядка 75 мб памяти(отображает динамически созданную и меняющую ракурс картинку с текущими настройками(какой-то фонтан в готическом стиле), кулер на видяхе повышает обороты). После указания настроек и закрытия окна уничтожается, освобождая все — опять те же 4 мб на CCC.exe. Версия ССС — 2010.0825.2146.37182(тут мой луч поноса разработчикам винапи, из-за которых скопировать из статика ничего нельзя — 4 раза запускал окошко с версией, в линухе по умолчанию статические контролы выделяются, и из них можно копировать).
Линух(Убунту 10.10 АМД64, оборудование то же, дрова поставлены стандартным средством — нажатие кнопки "активировать пропритарный драйвер", работает не менее на отл).
ССС не существует — в памяти нет постоянно работающего контрол центра. При загрузке оного вручную занимает 13.5 метров памяти. Но — картинка статическая — тот же фонтан, с теми же графическими опциями, но просто один кадр, а не анимация. Правда, и работает быстрее — но в винде мы анимацию видели, а тут просто перерисованная та же картинка, только с выбранными опциями. Но и память 13.5 — и не меняется, причем отзыв юзеринтерфейса контролцентра порядка единиц миллисекунд.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
: какого х..я простейшая утиль жрет столько памяти?
E> Сейчас — как минимум потому, что может. При даже не моих 8Г, а минимальных 4Г для игрового компа(а на неигровом этим утилитам грош цена) даже эта память — крохи.
Ну причем тут игровой не игровой? У ATI, что, встроенной графики нет, или ее не ставят на нетбуки? На счет цены вопрос интересный. Чем прикажешь пользоваться юзеру нетбука с чипсетным radeon для настройки подключения оного к телевизору, настройки цветности (ты ведь в курсе каким говном бывают TN'матрицы?), зажимания всех настроек для запуска чуть более жручей игрушки (на нетбуках играют, да).
E> мб(первое значение — private bytes, это после открытия и закрытия, если просто после загрузки — 1.5 мб), в открытом — около 50.
Класс! Я говорю о ProcessExplorer, ты выкладываешь скриншот TaskManager'а (в котором, для семерки, нужно смотреть на CommitSize).
).
ниче, что там вдвое больше регистров general и xmm, что влияет на оптимизатор (можно гораздо больше себе позволить. а уж сколько регистров в ia-64... ууу... отдельный модуль, да), exception handling другой и т.д.?
