Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
| | | | | | | | | | | | | | | | | | | |
Не накручивай. Просто закроем и все. Можно перенести с какого-нибудь места в misc и там закрыть. 06.01.04 15:45 Число просмотров: 1580
Автор: Ktirf <Æ Rusakov> Статус: Elderman
Отредактировано 06.01.04 15:46 Количество правок: 1
|
|
Например, начиная с твоего "Оффтопа" - вполне символично :)
|
|
<site updates>
|
|
Ох... 03.12.03 01:42
Автор: jammer <alex naumov> Статус: Elderman
|
|
не внесет ли сей ученый муж в свой списочек корову? я все чаще и чаще этого побаиваюсь.
|
| |
Ну вот оно и начинается 03.12.03 03:13
Автор: jammer <alex naumov> Статус: Elderman
Отредактировано 03.12.03 03:33 Количество правок: 2
|
> не внесет ли сей ученый муж в свой списочек корову? я все
> чаще и чаще этого побаиваюсь.
"We have had several reports from users that Norton AV 2003 is
detecting the file dnetc.com from build 483 as a Trojan. We
have confirmed this as well as confirming that Norton AV
corporate edition 8 has the same behavior."
(с)
Проблема с NAV
чешем репу?
|
|
Здравствуйте,
02.12.03 02:27
Автор: Serge3leo Статус: Незарегистрированный пользователь
|
Здравствуйте,
Всё понимаю кроме следующего предложения:
"..., но не более того. И больше всего умиляют его попытки представить себя как специалиста в области безопасности)."
Оно как-то совершенно не связанно, ни с обсуждаемой проблемой, ни с остальными частями статьи.
Или есть соображения о низком уровне профессионализма сотрудников "Лаборатории Касперского" и у них следует отозвать лицензию ГосТехКоммиссии на разработку, производство, распространение и поддержку. Или быть может ПО от "Лаборатории Каспреского" не безопасно и у них следует отозвать сертификаты ГосТехКоммиссии на те или иные продукты?
Вероятно, и продукты хорошие, и специалисты хорошие, просто рабочие моменты, связанные с совместимостью разных продуктов.
P.S.
Следует заметить, что ссылки по теме на http://www.kaspersky.ru/ не хватает.
|
| |
hi 03.12.03 01:31
Автор: jammer <alex naumov> Статус: Elderman
|
> Всё понимаю кроме следующего предложения:
> "..., но не более того. И больше всего умиляют его попытки
> представить себя как специалиста в области безопасности)."
> Оно как-то совершенно не связанно, ни с обсуждаемой
> проблемой, ни с остальными частями статьи.
Женька лапы не только к защите от вирусов, а вообще к защите как таковой тянет - это не секрет.
> Или есть соображения о низком уровне профессионализма
однозначно есть. начать с таких мелочей, как нормальный приоритет сканера по умолчанию и тормознутый монитор (на Си чтоли написан, или вообще на бейсике?). ключевые файлы - так просто курам на смех. не могу сказать что я особо много юзал касперского, но в серьезных конторах я замечаю что его сносят и ставят NAV например. повод задуматься или нет?
> сотрудников "Лаборатории Касперского" и у них следует
> отозвать лицензию ГосТехКоммиссии на разработку,
> производство, распространение и поддержку. Или быть может
> ПО от "Лаборатории Каспреского" не безопасно и у них
видимо, раз он любит корежить безобидные файлы, никак не безопасно.
> следует отозвать сертификаты ГосТехКоммиссии на те или иные
> продукты?
это не нам решать. это бизнес ;) - инвестиции, клиенты, продажи, конкуренты, налоги, отстегивания. знаю я примерно как это делается. я даже в коммерческом вузе работал 2 года, там похожий расклад, все просто.
вобщем я к тому что к делу это все не относится. сертификат о качестве софта говорит весьма мало.
> Вероятно, и продукты хорошие, и специалисты хорошие, просто
> рабочие моменты, связанные с совместимостью разных продуктов.
Женьке все прямо было сказано, ан нет, Женька уперся рогом.
честно сказать, есть у меня подозрения, что он из тех, кто любит пускать пыль в глаза лапшой на уши на тему собственной супер-пупер важности, и приводить тщательно отфильтрованный список аргументов, скрывая невыгодные. мне такой подход к делу никогда не нравился.
> Следует заметить, что ссылки по теме на
> http://www.kaspersky.ru/ не хватает.
а это, видимо, либо и так понятно, либо следует написать вебмастеру security.nnov.ru
а хватает ли ссылки писать сюда
размах!
|
| | |
Оффтоп: вопрос по поводу причин тормознутости 03.12.03 11:23
Автор: amirul <Serge> Статус: The Elderman
|
> приоритет сканера по умолчанию и тормознутый монитор (на Си
> чтоли написан, или вообще на бейсике?). ключевые файлы -
На C получаются тормозные проги или я чего то неправильно понял (насчет бейсика спорить не стану)?
|
| | | |
asm forever :| 06.12.03 07:06
Автор: jammer <alex naumov> Статус: Elderman
|
|
|
| | | | |
Одна беда - непереносим. То есть вообще нинасколько. 06.12.03 14:21
Автор: Ktirf <Æ Rusakov> Статус: Elderman
|
|
|
| | | | | |
"бед"-то много 24.12.03 15:08
Автор: jammer <alex naumov> Статус: Elderman
|
время на разработку, отладку и модификацию существенно больше.
непереносимость? между чем и чем (если про монитор говорим) - уточните.
только клиенты платят как раз деньги для того чтобы кривописаки в авп работали, а не писульки на сях через клипбоард копировали. лично мне графический интерфейс для монитора и засирание места в трее не нужны - а скорость работы файл-сервера куда важнее.
|
| | | | | |
Вторая беда - рефакторинг невозможен практически 08.12.03 13:07 [Ktirf, JINN]
Автор: amirul <Serge> Статус: The Elderman
|
Уже не реюз, как я писал раньше. Для того, что я имел в виду есть другое более умное слово :-)
Собственно подгонка кода под новые условия существования - БОЛЬШАЯ проблема для асма. И на пару порядков меньшая для C
|
| | | | | | |
а давайте немного уйдем от девелоперских проблем. представим себе: я - юзер 24.12.03 15:23
Автор: jammer <alex naumov> Статус: Elderman
|
> Уже не реюз, как я писал раньше. Для того, что я имел в
> виду есть другое более умное слово :-)
>
> Собственно подгонка кода под новые условия существования -
> БОЛЬШАЯ проблема для асма. И на пару порядков меньшая для C
какие могут быть еще новые условия существования - обновление вирусной базы или смена сервиспака в W2k/XP ? не смеши.
если хороший хирург поможет плохому танцору - разница в размере проблемы окажется куда меньшей.
а вообще-то сабж. :) как честно заплативший. убытки от лишних тормозов можно посчитать хоть в блоках rc5, хоть в нервах юзеров в моменты сильной нагрузки. на выбор.
|
| | | | | | | |
Третья беда - полное отсутствие статической типизации 24.12.03 15:53
Автор: amirul <Serge> Статус: The Elderman
|
> какие могут быть еще новые условия существования - обновление вирусной
> базы или смена сервиспака в W2k/XP ? не смеши.
Или смена ОС или платформы. Скажи, ты дествительно не видел AVP под линух? Только не надо мне говорить про врапперы и абстрагирующий layer. Это попытка создать из асма высокоуровневую среду программирования. Это гораздо лучше сделано в том же C (хотя и тоже не без косяков).
> а вообще-то сабж. :) как честно заплативший. убытки от
> лишних тормозов можно посчитать хоть в блоках rc5, хоть в
> нервах юзеров в моменты сильной нагрузки. на выбор.
У меня уже сейчас есть несколько проектов по ~10000 строк (которые я тяну в одиночку). При этом статическая типизация ой как помогает избавиться от лишних ошибок.
Четвертая беда - чрезмерная избыточность кода, не приводящая однако к его ошибкоустойчивости. Для реализации цикла надо вводить с десяток инструкций, причем цикл так и останется неявным (инкремент-проверка-условный переход ни одно из этих явлений не говорит о непосредственно цикле). Для вызова функции - еще пара десятков. Код растет - его понимаемость снижается -> количество ошибок растет (особенно если учесть предыдущую проблему) - простой юзер недоволен (если до него вообще когда нибудь дойдет проект из хотя бы десятков-сотен тысяч строк, который принципиально пишут на асме).
У асма еще очень много бед.
Повторю для непонятливых: в ПОДАВЛЯЮЩЕМ БОЛЬШИНСТВЕ случаев оптимизирующий компилятор генерирует код не хуже (а зачастую и лучше) человека. В самых крайних случаях есть inline-ассемблер. На спринте (коротких и нетривиальных кусках кода) человек еще может посоревноваться с компилятором, но на марафонных дистанциях (>1000 строк) компилятор всегда побеждает.
|
| | | | | | | | |
back to the user! 26.12.03 11:04
Автор: jammer <alex naumov> Статус: Elderman
Отредактировано 26.12.03 11:04 Количество правок: 1
|
> > какие могут быть еще новые условия существования -
> обновление вирусной
> > базы или смена сервиспака в W2k/XP ? не смеши.
> Или смена ОС или платформы.
а зачем все время сменять? есть монитор под OS1 и... скажем, OS2 ;) и под платформы. надо что-то дописать - дописывается. переносить смысла не вижу.
> Скажи, ты дествительно не видел AVP под линух?
именно. да я вообще с линуксом дел не имею и стараюсь не иметь... мне компромиссы не по душе. ;) (личная точка зрения)
> Только не надо мне говорить про врапперы и
> абстрагирующий layer. Это попытка создать из асма
> высокоуровневую среду программирования. Это гораздо лучше
> сделано в том же C (хотя и тоже не без косяков).
я и не собирался об этом говорить, я не настолько повернут на девелоперстве. слова твои понятны поодиночке, а в сочетаниях я просто даже не знаю о чем конкретно ты говоришь (только догадываюсь, вспоминая высшую школу и теорию).
> > а вообще-то сабж. :) как честно заплативший. убытки от
> > лишних тормозов можно посчитать хоть в блоках rc5, хоть в
> > нервах юзеров в моменты сильной нагрузки. на выбор.
> У меня уже сейчас есть несколько проектов по ~10000 строк
> (которые я тяну в одиночку). При этом статическая типизация
> ой как помогает избавиться от лишних ошибок.
когда во время компиляции и даже выполнения контролируются допустимые значения для переменных? да кто ж с этим поспорит, только до стандартного стародоброобучающего паскаля си все равно не дотягивает в этом контроле - во всяком случае ощущение правильности исходника у меня отсутствует. си, т.о. не изящен и нечитабелен. объявить int x и присвоить ему 'a' - ну где еще такое проканает, кроме сей. также радует и логический тип задавать целочисленным, опупенный расклад, особенно если вспомнить о разнице выполнения операций NOT, AND, OR, XOR etc над логическими и цифровыми величинами.
> Четвертая беда - чрезмерная избыточность кода, не
я думаю именно на выходе твоего компилятора получается чрезмерная избыточность кода, когда 100 байт инструкций обрамляются 100 килобайтами MFC и прочей срани.
> приводящая однако к его ошибкоустойчивости. Для реализации
> цикла надо вводить с десяток инструкций, причем цикл так и
> останется неявным (инкремент-проверка-условный переход ни
> одно из этих явлений не говорит о непосредственно цикле).
и комментариям ты тоже не обучен? ;)
> Для вызова функции - еще пара десятков. Код растет - его
а, мышление функциями, одна из убогостей сишного взгляда на программирование, в ассемблере нет функций вообще. хотя скорее тут расхождение во мнениях терминологическое, если не думать о том что скорее всего ты забываешь, что результат функции - одна величина некоторого типа, результатом процедуры может быть от нуля до множества величин.
> понимаемость снижается -> количество ошибок растет
> (особенно если учесть предыдущую проблему) - простой юзер
> недоволен (если до него вообще когда нибудь дойдет проект
> из хотя бы десятков-сотен тысяч строк, который
> принципиально пишут на асме).
кстати, про принципиальность написания я ничего не говорил. такие вещи как открытие файла или сообщение об ошибке я не вижу смысла писать на языке низкого уровня. pure asm скорее фетиш и на деле действительно - на мой взгляд - оправдывается только если приносит удовольствие автору.
> Повторю для непонятливых: в ПОДАВЛЯЮЩЕМ БОЛЬШИНСТВЕ случаев
> оптимизирующий компилятор генерирует код не хуже (а
всегда хуже - как минимум из-за обрамления ненужными кусками двоичного кода в объектных и исполняемых файлах, ненужной масштабируемостью, и прочей фигней, которую даже днем с огнем всю не выключишь. я сейчас говорю на примере борландовского и мелкософтовского компилятора, про другие тонкостей не помню.
> зачастую и лучше) человека. В самых крайних случаях есть
ну если настолько неграмотен человек - место ему в вебмастерах, а не в программерах.
> inline-ассемблер.
об этом и речь. про тот же монитор можно уверенно сказать что наиболее популярные проверяющие циклы он крутит не эффективно из-за пренебрежения такой возможностью, лени, а возможно и простой неграмотности разработчиков.
> на марафонных дистанциях (>1000 строк) компилятор всегда побеждает.
в скорости и комфорте разработки, но не в результате.
типичная беда нашего времени - сделать все впопыхах. сграбить фильм с DVD, неэффективно пожать его в divx, криво перевести название на русский язык и записать его траснлитом в имя файла - утверждая что компилятор всегда побеждает. смешно.
настолько же нелепо делать гуй из монитора, которому сервисом положено было бы работать, а темы XP лепить в виде сервиса.
имхо.
PS. ну и опять же повторюсь - мы только о проблемах девелоперов рассуждаем, а проблема юзера в том что он зазря гоняет байтики в памяти по причине ленивой криворукости девелопера. я в своих попытках что-то сдевелопить поражаюсь быстродействию таких машин на которых AVP Monitor будет прорисывывать свои FUCKING иконки минут несколько при разворачивании гуевого окна. мне иконки не нужны, и регедит тоже, я бы с большим удовольвием отредактировал конфиг фаром - по образу и подобию того как я редактирую фаром конфиги freebsd.
|
| | | | | | | | | |
Есть закон неограниченности потребностей. В том плане, что... 26.12.03 14:53
Автор: amirul <Serge> Статус: The Elderman
|
> а зачем все время сменять? есть монитор под OS1 и...
> скажем, OS2 ;) и под платформы. надо что-то дописать -
> дописывается. переносить смысла не вижу.
Есть закон неограниченности потребностей. В том плане, что потребности постоянно меняются. И именно потому, что можно убить два года на проект средней крупности, а он уже будет не нужен появилось eXtreme Programming. Это не только в программировании есть. Любая система, которая пытается останвится в развитии очень быстро начинает деградировать.
> именно. да я вообще с линуксом дел не имею и стараюсь не
> иметь... мне компромиссы не по душе. ;) (личная точка
> зрения)
Ой ли. Компромиссы не по душе. А по моему обычный снобизм фрибсд-шников. :-) Я тут недавно ссылку кидал с реальными бенчмарками фри и линуха. Не в пользу BSD-систем вообще кстати (хотя фря из BSD систем действительно оказалась лучше всех)
> я и не собирался об этом говорить, я не настолько повернут
> на девелоперстве. слова твои понятны поодиночке, а в
Я тоже не повернут, между прочим. Не такие уж это и сложные понятия. Ну да ладно. :-)
> когда во время компиляции и даже выполнения контролируются
> допустимые значения для переменных? да кто ж с этим
> поспорит, только до стандартного стародоброобучающего
> паскаля си все равно не дотягивает в этом контроле - во
> всяком случае ощущение правильности исходника у меня
> отсутствует. си, т.о. не изящен и нечитабелен. объявить int
> x и присвоить ему 'a' - ну где еще такое проканает, кроме
> сей. также радует и логический тип задавать целочисленным,
> опупенный расклад, особенно если вспомнить о разнице
> выполнения операций NOT, AND, OR, XOR etc над логическими и
> цифровыми величинами.
Написал же. Что и там не без косяков, большинство из которых запросто обходятся в самом C, а в C++ уже внесены в язык.
> я думаю именно на выходе твоего компилятора получается
> чрезмерная избыточность кода, когда 100 байт инструкций
> обрамляются 100 килобайтами MFC и прочей срани.
Не обязательно линковаться с MFC, необязательно линковаться даже с рантаймом.
> и комментариям ты тоже не обучен? ;)
Ага. Комментировать каждый цикл, если это можно выразить средствами самого языка. Кстати, все более-менее сведущие программисты говорят, что этот вид комментариев - один из самых плохих. Не стоит комментировать то, что выражено в самом языке:
a = b + c; // Заносим в a сумму b и c
---
> а, мышление функциями, одна из убогостей сишного взгляда на
> программирование, в ассемблере нет функций вообще. хотя
> скорее тут расхождение во мнениях терминологическое, если
> не думать о том что скорее всего ты забываешь, что
> результат функции - одна величина некоторого типа,
> результатом процедуры может быть от нуля до множества
> величин.
Точно так же деление вызвов на процедуры и функции - одна из убогостей паскалевского взгляда на вещи. А функциональная декомпозиция - всего лишь один из шагов в ЭВОЛЮЦИИ методологии программирования. Скажу лишь, что вся эта эволюция сводится к уменьшению зависимостей между частями программы. В объектной декомпозиции связей еще меньше.
> фетиш и на деле действительно - на мой взгляд -
> оправдывается только если приносит удовольствие автору.
Вот с этим, пожалуй, соглашусь.
> всегда хуже - как минимум из-за обрамления ненужными
> кусками двоичного кода в объектных и исполняемых файлах,
Либы можно не подключать, стековые фреймы не генерировать. Тогда C просто превратится в асм. А вот асм в C не превратится никогда.
> ненужной масштабируемостью, и прочей фигней, которую даже
> днем с огнем всю не выключишь. я сейчас говорю на примере
> борландовского и мелкософтовского компилятора, про другие
> тонкостей не помню.
Не уверен, что Вы знаете тонкости борландовского и мелкософтовского компилятора, раз говорите такое.
> > зачастую и лучше) человека. В самых крайних случаях
> есть
>
> ну если настолько неграмотен человек - место ему в
> вебмастерах, а не в программерах.
Ой ли. Паровать инструкции и выравнивать по границе кеш-строки в 100000 строках ИМХО лучше это удовольствие оставить компилятору. А ведь это МИНИМУМ, который делает оптимизирующий компилятор. Мне когда то пытались привести в пример VTune, который ищет возможности для оптимизации и говорит человеку, что подправить. Вот только до сих пор не понимаю зачем в этой цепочке человек.
> > inline-ассемблер.
> об этом и речь. про тот же монитор можно уверенно сказать
> что наиболее популярные проверяющие циклы он крутит не
> эффективно из-за пренебрежения такой возможностью, лени, а
> возможно и простой неграмотности разработчиков.
А вот тут не согласен. Преждевременная оптимизация - корень всех бед. НАЧИНАТЬ ручную оптимизацию следует только после того, как программа основательно погонялась под профайлером и выявлены РЕАЛЬНЫЕ бутылочные горлышки.
> > на марафонных дистанциях (>1000 строк) компилятор
> всегда побеждает.
>
> в скорости и комфорте разработки, но не в результате.
Именно в результате.
> типичная беда нашего времени - сделать все впопыхах.
> сграбить фильм с DVD, неэффективно пожать его в divx, криво
> перевести название на русский язык и записать его
> траснлитом в имя файла - утверждая что компилятор всегда
> побеждает. смешно.
Эх. Чем-то мне эта дискуссия напоминает Urix-а. Тот тоже любил заявлять что со времен PDP ничего хорошего не придумали. И все только деградирует. Смею предположить что Вы уже весьма немолоды и как следствие боитесь новизны.
> настолько же нелепо делать гуй из монитора, которому
> сервисом положено было бы работать, а темы XP лепить в виде
> сервиса.
Не будет спорить о необходимости гуя вообще. Скажу лишь, что XP, где графическая подсистема вынесена в ядро, работает все таки быстрее чем X.
> PS. ну и опять же повторюсь - мы только о проблемах
> девелоперов рассуждаем, а проблема юзера в том что он зазря
> гоняет байтики в памяти по причине ленивой криворукости
> девелопера. я в своих попытках что-то сдевелопить поражаюсь
Ленивость и криворукость девелопера между прочим никак не относится к удобству среды разработки. Можно даже сказать наоборот: чем удобнее работается девелоперу, тем лучше будет юзеру в конце концов.
> тоже, я бы с большим удовольвием отредактировал конфиг
> фаром - по образу и подобию того как я редактирую фаром
> конфиги freebsd.
Поздравляю. Во первых не забывайте о позиционировании. Во вторых вспомните, сколько всего вынесено в реестр (опять таки не станем спорить зачем столько настроек) и подумайте с какой скоростью выполнялся бы поиск по текстовой базе. Реестр - это база данных. А БД для эффективной работы просто обязана быть бинарной.
|
| | | | | | | | | |
проблемы девелоперов быстро превращаются в проблемы юзеров 26.12.03 13:23
Автор: dl <Dmitry Leonov>
|
|
Раз и навсегда написанные программы - это идеальный случай. Меняются условия, меняются требования, программу нужно обновлять, причесывать, поддерживать. Самый идеальный код на ассемблере начиная с какого-то уровня сложности проекта развалится точно так же, как кривая поделка на васике или дельфи, и исправить в нем что-то станет просто нереально.
|
| | | | | | | | | | |
или начиная с NT4 ничего не меняется - или я что-то пропустил? 26.12.03 13:45
Автор: jammer <alex naumov> Статус: Elderman
|
|
это на тему монитора.
|
| | | | | | | | | | | |
NT, Linux и многое прочее на С написано 26.12.03 13:59
Автор: Killer{R} <Dmitry> Статус: Elderman
Отредактировано 26.12.03 14:06 Количество правок: 1
|
|
Есть конечно фрагменты на асме, но в основном - С. Единственная ОС писанная на чистом асме которую я знаю - Menuet OS. Причем я бы не сказал что она очень шустрая (для своих размеров) да и существует она тока для х86. Что касается скорости асма - во первых никто тебя не вынуждает использовать тот же MFC или даже вообще пользоваться стандартными функциями С. Во вторых трудновато тебе будет держать в памяти тайминги всех инструкций, расставлять их так чтобы они работали максимально быстро на современных процессорах с ихним кэшированием и предсказанием переходов. Этим как раз прекрасно занимается компилятор тогоже С.
|
| | | | | | | | | | | | |
наверное даже компилятор С написан на С? ваау. это прямо таки pkunzip.zip! ;) 26.12.03 15:10
Автор: jammer <alex naumov> Статус: Elderman
|
> Есть конечно фрагменты на асме, но в основном - С.
я блин про "фрагменты" и говорил. полсекунды или секунду будет выполняться подпрограмма, которая выполняется раз в сутки, меня абсолютно not a bird. просьба: читать если меня, то ВНИМАТЕЛЬНО и ничего НЕ ДОДУМЫВАТЬ и не фантазировать, не подставлять свой субъективный контекст - вы заведомо ошибетесь и сознательно меня не поймете.
> касается скорости асма - во первых никто тебя не вынуждает
> использовать тот же MFC или даже вообще пользоваться
> стандартными функциями С.
да вообще этим нечитабельным языком, только в котором и возможны ляпсусы типа (см. ссылку ниже).
> Во вторых трудновато тебе будет
> держать в памяти тайминги всех инструкций, расставлять их
> так чтобы они работали максимально быстро на современных
> процессорах с ихним кэшированием и предсказанием переходов.
> Этим как раз прекрасно занимается компилятор тогоже С.
в памяти нет смысла держать. занимается не настолько прекрасно как тебе кажется, и простое дизассемблирование тебя в этом легко убедит. напиши int x = 10 и собери екзешник, вместо 10 байт у тебя получится 100К.
указанный Ktirf-ом глюк
|
| | | | | | | | | | | | | |
Ты прав, GCC написан на С :) 26.12.03 15:37
Автор: Killer{R} <Dmitry> Статус: Elderman
|
> > Есть конечно фрагменты на асме, но в основном - С.
> я блин про "фрагменты" и говорил. полсекунды или секунду
> будет выполняться подпрограмма, которая выполняется раз в
> сутки, меня абсолютно not a bird. просьба: читать если
> меня, то ВНИМАТЕЛЬНО и ничего НЕ ДОДУМЫВАТЬ и не
> фантазировать, не подставлять свой субъективный контекст -
> вы заведомо ошибетесь и сознательно меня не поймете.
На асме в основном делаются фрагменты работающие с железом напрямую. Ввод вывод в порты имхо на асме делать просто легче. А насчет скорости - расскажу легенду которую мне самому как то рассказывали. Был один чел у нас который весьме нехило шарил в асме. И решил он написать небольшую программку (с циклом, считала чтото) с целью обойти в скорости аналогичный код на С скомпиленный в Watcom C. Чел обломался.
> > касается скорости асма - во первых никто тебя не
> вынуждает
> > использовать тот же MFC или даже вообще пользоваться
> > стандартными функциями С.
>
> > Во вторых трудновато тебе будет
> > держать в памяти тайминги всех инструкций, расставлять
> их
> > так чтобы они работали максимально быстро на
> современных
> > процессорах с ихним кэшированием и предсказанием
> переходов.
> > Этим как раз прекрасно занимается компилятор тогоже С.
>
> в памяти нет смысла держать. занимается не настолько
> прекрасно как тебе кажется, и простое дизассемблирование
> тебя в этом легко убедит. напиши int x = 10 и собери
> екзешник, вместо 10 байт у тебя получится 100К.
Получится порядка 1 кб. Тут недавно пролетала мессага о том как отключить стандартные Сшные либы в которых содержатся такие стандартные функции как printf, malloc, и прочее. А 1кб - это изза PE заголовка. 10байтный PE ехешник ты никак не сможешь сделать. Кстати ничего страшного даже в том что в ехешнике лежит код который и выполняться то никогда не будет. Механизм запуска приложений в виндах таков, что если участок кода не юзается то он не будет никогда загружен в память.
> да вообще этим нечитабельным языком, только в котором и
> возможны ляпсусы типа (см. ссылку ниже).
В асме таких ляпусов может быть намноого больше. xor eax,eax вместо mov eax,edx в коде состоящем и гораздо большего количества строк мог бы привести к примерно такому же эффекту.
|
| | | | | | | | | | | | | |
Ага. И это называется раскрутка компилятора. 26.12.03 15:31
Автор: amirul <Serge> Статус: The Elderman
|
Первая версия пишется на чем угодно (хоть на бейсике). Собирается компилятор. Все следующие версии компилятора пишутся на нем самом. И VC, и gcc.
> я блин про "фрагменты" и говорил. полсекунды или секунду
> будет выполняться подпрограмма, которая выполняется раз в
> сутки, меня абсолютно not a bird. просьба: читать если
> меня, то ВНИМАТЕЛЬНО и ничего НЕ ДОДУМЫВАТЬ и не
> фантазировать, не подставлять свой субъективный контекст -
> вы заведомо ошибетесь и сознательно меня не поймете.
Гы. Ну знамо дело. Все в го*не один ты д'Артаньян. "вы заведомо ошибаетесь" вот это вот как раз и есть подстановка к нам своего субъективного контекста.
> > касается скорости асма - во первых никто тебя не
> вынуждает
> > использовать тот же MFC или даже вообще пользоваться
> > стандартными функциями С.
>
> да вообще этим нечитабельным языком, только в котором и
> возможны ляпсусы типа (см. ссылку ниже).
Да уж. В асме таких ляпсусов не бывает. Там просто можно побочноый эффект изменения какого нибудь флага использовать. Или я видел прикол (еще под досом): в кеш загружалась строка, в которой есть одно обращение к памяти и один безусловный переход. Причем обращение к памяти - это запись адреса перехода следующей инструкции. Но так как инструкция уже в кеше (или даже прошла пол-конвейера), переход осуществлялся по старому адресу. А отладчики всегда уходили по новому.
Не надо говорить, что инструмент плохой, только потому, что вы не умеете им пользоваться. После некоторого опыта работы (не сильно большого к слову), программист уже никогда случайно не напишет вместо сравнения присвоение.
Чтобы не переливать из пустого в порожнее, давайте я вам попросим кого нибудь написать реализацию какого-нибудь нетривиального алгоритма на C и на асме (можно даже откомпилировать исходную программу в асм). И дать без комментариев разным людям. Вы действительно уверены, что человек, которому попадется асм без комментариев столкнется с меньшими проблемами при чтении, чем С-шник. Если да, то мне просто не о чем с Вами больше говорить. Таких людей не прошибешь НИКАКИМИ аргументами. Тут уже был такой, который обвинял меня в ошибках (по его мнению) в СТАНДАРТЕ C++.
> > Во вторых трудновато тебе будет
> > держать в памяти тайминги всех инструкций, расставлять
> их
> > так чтобы они работали максимально быстро на
> современных
> > процессорах с ихним кэшированием и предсказанием
> переходов.
> > Этим как раз прекрасно занимается компилятор тогоже С.
>
> в памяти нет смысла держать. занимается не настолько
> прекрасно как тебе кажется, и простое дизассемблирование
> тебя в этом легко убедит. напиши int x = 10 и собери
> екзешник, вместо 10 байт у тебя получится 100К.
Да? А может поспорим, что я могу написать на C программу, которая будет занимать минимальный для данного формата объем? А может заглянете в раздел FAQ? Вещи-то довольно простые и я удивлен, что Вы их не знаете.
ЗЫ: Кстати, программа из int x = 10 не будет занимать вообще ничего, т.к. компилятор соптимизирует неиспользуемую переменную. Если же написать volatile int x = 10, то программа не будет содержать ни одной ИСПОЛНЯЕМОЙ инструкции - только сегмент данных, в котором будет содержаться переменная x, проинициализированная значением 10.
|
|
|
подробно о проекте
Анализ криптографических сетевых...
