inline asm function - а дальше компилятор заоптимазит тебе так, что ты никогда не додумаешься до этого

Когда нет необходимости - зачем менять все это...

А стоимость?

Хм, интересно что же это за компы такие.. Windows 95 или 98 вполне сносно работает на Pentium MMX 133/166, помню даже сидел как то за 486-м с 16(или 32) метрами памяти, все офисные приложения запускались и работали. Если компы ещё древнее, то тут уж ничего не поделаешь, приходится под досом сидеть и ругать тут уже надо финансирование

Насчёт доступа к памяти, ограничение сегмента 64к это очень неудобно и снижает производительность, то же самое и про расширенную память сказать можно. А если используется защищённый режим, то это досом назвать нельзя уже(не может работать дос в защищёнке).. скорее это нереальный режим, который расширители доса используют(DOS4GW). В таком случае работать с памятью конечно же удобнее, но до винды всё равно далеко.

В общем можно понять использование доса на старых компах(386, 486), но когда есть железо класса PIII и мощнее, и на котором работают в досе, недоумение возникает однако


А вот это уже зависит от того как напишешь. Хорошо написанная прога для работы с базой под винду на C++ будет однозначно быстрее чем на фоксе, потому что он вообще не выполняется а интерпретируется


Ну вот кажется мне что в винде работать удобнее, и не только мне думаю так кажеться. Кроме того если софт качественный то производительность по сравнению с досом повыше будет, да и возможностей побольше.


Многозадачность возможна только в защищёнке. Да можно процессы переключать, но за памятью следить невозможно всё равно.

virus
Согласен. Зачем вообще изучать асм, C++, отлаживать учиться, когда можно накидать пару строк в дельфи и продавать.
Качество от среды всё-таки немного зависит, когда пишешь на WinAPI или хотя бы на MFC, то почти весь код находится под твоим контролем, есть полная гарантия безошибочности. А в борландовских поделках библиотечного кода на порядок больше полезного(для сравнения на VC++ простое окно занимает 2.5Кб, на дельфи 500кб).
Правда можно и на VC прогу до предела раздуть, что например в Nero 6'ом такого, что экзешник весит 15 метров? Думаю если написать заново такую же по функциональности прогу с нуля, то максимум 1.5 - 2 метра, и работать будет пошустрее. Так что деградация программистов налицо.


Причём тут компилятор, когда на асме пишешь сам оптимизируешь всё. А насчёт оптимизации, пока что компиляторам далеко до человека, даже Intel C++ генерирует недостаточно качественный код, а если требуется использовать MMX, SSEx то тут уж только вручную.


Вот только единственный недостаток, но хорошее почти всегда стоит дороже.

dragon Я тебе уже сказал, что у нас парк машин начинается с 486-х.
Про Пентиумы под Виндовс. На P-200 можно поставить и вин2к. А потом поставь антивирус типа Касперского и посмотри что будет с компом. И ещё будут проблемы с настройкой сетевых доменов. Вин9х не всё поддерживает из современных технологий.
Про финансирование я тебе уже сказал - нет денег. Я могу только пытаться заткнуть самые большие дырки и следить, чтобы не расползались маленькие.
Чем оно неудобно и как снижает производительность? Кстати, 16-битные программы работают быстрее за счёт адресации и переходов внутри сегмента. На работе с расширенной памятью строится вся работа Виндовс. Чем же там неудобно и медленно?
Это именно ДОС - Novell DOS, например. Его emm386 поддерживает защищённый режим. Там же есть специальный драйвер DPMI.
Там же и менеджер многозадачного режима. У меня знакомый этим пользовался для копирования данных между приложениями.
Кстати, DOS Shell из комплекта MS-DOS 5.0 позволял запускать несколько задач. Понятно, что интерфейс Виндовс для этого удобнее, но тем не менее.
Ситуация проста - программистам надо написать программу, которая будет работать на достаточно слабых компах. Потому что у клиентов их ещё полно. Они и пишут. Но писать две программы никто не будет. Поэтому эту досовскую программу рассылают всем и приходится её использовать и на А64.

Ты не понял, о чём я говорил. Речь не о производительности самой программы, а о производительности труда программиста.
Про интерпретируемость Фокса знаю. Это его минус. Clarion и Clipper - компилируемые языки.
Когда кажется - крестись. Надо смотреть - в каких случаях удобнее ДОС, а в каких - Виндовс. Аргументы в пользу ДОСа я тебе приводил. Чем удобнее Виндовс? Только это уже будет крутой оффтоп.
Производительность Виндовс приложений ниже из-за накладных расходов. Но ДОС-приложения могут работать под Виндовс быстрее за счёт более эффективного кеша, например.
Когда размер приложения достигает определённых границ, то контроль теряется. Поэтому для небольших приложений лучше простой С, для более крупных проектов нужен Visual С или что-то аналогичное. Я на Кларионе или Фоксе быстрее напишу законченное приложение и быстрее его модифицирую, чем на простом С с API. И затраты на разработку приложения будут ниже.

А асм остаётся либо для критичных кусков кода, либо для драйверов.

Как бы далеко не шагнули компы, "асм" остаётся и на этом можно поставить жирную точку !!!
(по крайней мере до тех пор пока для процев не придумают ещё какой нибудь язык который имело бы смысл реализовать на "железячном" уровне)

Есть и нормальные антивирусы(например nod32), а ещё лучше вообще без него, откуда на рабочем компе вирусам взяться? Только если кто-нибудь прокрадётся и запустит


DPMI переходит в защищёнку и обратно при каждом обращении к памяти, отличное просто решение

Не знаю как на атлонах, а на P3/P4 производительность в 16-битном режиме просто ужасная, они не для него проектировались.

В общем можно долго очень спорить, но я всё равно считаю что дос умер двадцать лет назад когда 386-й проц появился, и использовали его ещё 15 лет из-за отсутствия нормальной ОС. Для компом класса PII 233 и 64/128 метром оперативки и выше можно ставить Win2k. Для компов послабее идеальным решением был бы консольный линукс, но вот беда, программисты не умели да и до сих пор не умеют ничего писать.


На средствах быстрой разработки есть смысл писать только если есть ограничение по времени, во всех остальных случаях лучше использовать такой язык, где можно контроллировать весь свой код, и C/C++ с асмом подходят как нельзя лучше.


Именно так. Сколько M$ со своим дотнетом не вымудряется, ни асм ни обычный C++ вытеснить не получиться. А реализовать на уровне процессора какой-то более высокоуровневый язык невозможно, всё равно процессор может выполнять только элементарные операции.

Кстати, объясните мне, какой вообще смысл в .net? По-моему весь смысл в снижении производительности из-за интерпретации кода и выкачивание лишнего бабла с пользователей Не думаю что приложение будет легче разработать на C# чем на C++. Переносимость? Так куда эти приложения microsoft переносить собралась, не на линукс же А народ активно кинулся изучать всю эту хрень, не думая вообще зачем это надо.

dragon
Не совсем верно. Средства быстрой разработки прежде всего позволяют избежать нудной и долгой возни с интерфейсом. Это, несомненно, довольно весомый плюс. Т.к. есть возможность большинство сил бросить на разработку логики программы и оптимизации алгоритмов, а не на рисование интерфейса.

Зря не думаете. Действительно легче. И намного.
По-моему, действительно, ассемблер нужен только для критических точек программы, где производительность выше всего. А так же не стоит забывать про микроконтроллеры, программирование которых осуществляется и будет осуществяться на ассемблере. В этих ипостасиях он незаменим. В других же областях вряд ли его применение экономически целесообразно

dragon Ты опять судишь по себе и не хочешь учесть реалии жизни. С рабочих станций идёт выход в инет. Промежуточного компа с файрволом нет - требование провайдера. С провайдером у нас VPN, мы в его адресном пространстве. Результат: куча вирусов из инета прёт прямо на все компы сети.

Не берусь сказать про каждый раз - он резидентом сидит, позволяет загружать резиденты в extended memory, работать программам с этой памятью. Не уверен, что ты прав. Речь ведь идёт не о модуле в пользовательской программе, а о менеджере паяти операционки. Никакого падения производительности при его использовании не наблюдалось.
Трудно оценить, так как запас производительности приличный. Обычно ДОС-задачи запускаются из-под Виндовс и идут достаточно быстро.
Считать ты можешь что угодно. На реальную жизнь это мало влияет. Про Вин2к - согласен. Но если нет задач, сильно нагружающих систему. Например, антивируса.
Линукс не годится. Что я на нём буду запускать? Ты уверен, что все мои задачи пойдут на нём?
Ты не прав. Что там контроллировать в большинстве случаев? Разные визуальные среды и генераторы кода помогают программисту. Ведь никто не мешает тебе написать свой вариант генерации кода, который ты предварительно отладишь. Это просто очередной шаг использования раз разработанного кода для облегчения труда программиста. Ты же используешь готовые наработки при разработке новых задач.
Много времени экономится при разработке интерфейса и отчётов.
Те куски, которые мне надо вылизать я тоже пишу руками. Могу предварительно сгенерировать код по шаблону, а потом его поправить. Удобно.
Мне было бы интересно, сколько времени тебе понадобилось бы на разработку работы с парой связанных между собой таблиц, с их просмотром, корректировкой и печатью. И сколько времени потребуется на изменение структуры этих таблиц и алгоритма их обработки при необходимости. Особенно на асме.
Микрософт продвигает C# как альтернативу Java. А Java используется не только на PC. Этот язык как раз и разрабатывали как переносимый с платформы на платформу. И это его качество используется. Погляди на мобильники, бытовую технику, Линукс. Снижение производительности при интерпретации кода - расплата за возможность перенести программу с платформы на платформу не переписывая её код. Достаточно один раз разработать интерпретатор для очередной платформы и можно использовать сразу все наработки в прикладной области с других платформ. Представь, что появляется новый процессор с другой системой комманд. Главная проблема его продвижения - отсутствие прикладного ПО. Пиши для него интерпретатор и всё прикладное ПО можно использовать и на нём. Проблема снимается.
Это очень соблазнительная возможность.

господи. Ума не хватит. А вам бы пришло в голову вместо делени выполнить смещение, умножение, сложение и смещение, если это будет быстрее... А ведь для этого надо догадаться (правда это было на РИСКах)

И вообще хватит офтоп

Могу предложить тест... Берем задачу, бредовую, и кто хочет - пишет асм, а я потом привожу асм, сгенерированный gcc 4.0.x
А потом это все тестим. ОК?

Есть другой вывод - Windows Update, как ни странно работает А можно поставить и настроить файрвол на каждый терминальный комп, он не так ресурсы жрёт как касперский(вот явный пример кривой работы программеров )


Насколько я помню, DPMI работает именно так. А DOS4GW использует нереальный режим. Ведь в любом случае нельзя вызывать прерывания дос и биос из защищённого режима.


Пойдут то все, если софт найти Правда это большая проблема, под линукс очень мало софта написано если сравнить с досом, не смотря на качество операционок.. ведь линукс во всём превосходит дос, а главное требует на на много больше ресурсов для своей работы.

Эх, не мало, но в осномном из-за отсутствия опыта в таких делах.. Всё равно основная сложность это интерфейс, а всё алгоритмы можно писать на C++ почти с такой же скоростью как специализированных языках, при условии наличия нормальных библиотек.


Насчёт .net, не разу не слышал чтобы m$ предлагала интерпретатор для чего-нибудь отличного от x86 и винды, а для VM код явы уже частично поддерживается ARM процессорами, так что опоздали они с этим


Это на временное решение похоже, много задач есть, требующих производительности. Интересно представить кодек типа DivX написанный на яве или .net Но там где производительность не нужна(мобильники, большинство приложений кпк), идея смотриться очень неплохо.


Во-первых деление не такая уж часто используемая операция. Во-вторых инстукцию div надо раскрывать таким образом только в циклах, т.к. однократное деление некритично для производительности. А для такого раскрытия есть даже программка маленькая которая magic number ищет - число, на которое надо умножить для эмуляции деления.


Времени мало свободного.. Но вообще можно придумать что-нибудь такое не особо сложное, написать на асме и сравнить производительность. Например хардкорное(без внешних библиотек) преобразование кучи рисунков bmp в gif или jpeg, только писать долго и потом не пригодиться

dragon WindowsUpdate работает, но не всегда это полезно. У меня после установки патчей перестала работать программа 2-НДФЛ, по которой сдаются данные о налогах физических лиц в налоговую. Да и все твои методы требуют постоянной беготни по рабочим станциям: сами обновления, настройки, вызовы пользователей. При их количестве более 40 мне некогда работать будет. Кстати, поставил на свой комп OutPost - он через минуту блокирует доступ в инет. Ещё прикинь стоимость подобного решения при легализации этого софта. Файрвол не заменяет антивирус. Он не спасёт от вируса в почте или документа с вирусом с сервера. Так что антивирус всё равно ставить надо. Вся нагрузка, которую создаёт Касперский, вызвана проверкой файлов. Приведи мне пример антивируса, который может волшебным образом проверить архив размером 20-30 МБ с кучей файлов внутри за пару секунд.
Тем не менее программы работают и прерывания вызывают. И как ты можешь знать про реализацию DPMI в Novell DOS, если пару дней назад ты о нём не знал и говорил, что ДОС вообще не умеет работать в защищённом режиме?
Ты опять игнорируешь сказанное тебе. У меня есть софт, мне надо чтобы он пошёл. Что я тебе ещё буду искать? И где?
А основная масса программирования в таких программах - как раз интерфейс и работа с базой. А сложность С++ как языка намного выше, чем того же Клариона или Фокса. Правда Фокс мало годится для расчётов, но это искупают возможности работы с базой. Про библиотеки ты правильно вспомнил, потому как без них от самого языка толка нет.
Мне на Кларионе написать процедуру просмотра таблицы из пары полей (код и наименование - стандартный справочник) с процедурой редактирования её содержимого - 5-10- минут. Сколько надо на асме или С без визуальных средств?
Вспомни после чего появился C# - скандал с нарушением стандартов Java и судебные разборки с Sun. Сама платформа .net позиционируется, как средство разработки с уклоном в инет. А это прямая конкуренция с Java. С другими платформами они опоздали, но ведь и с инет-браузером Микрософт вышла позже на рынок. И версии Виндовс уступали в своё время OS2, Novell NetWare, Unix, а теперь конкурируют с ними весьма успешно и кое-кого вытеснили с рынка.
Ты опять плохо слушаешь. Я сказал "прикладное ПО". Кодек - системное ПО. Для него как раз нужна производительность.
Да ну? Не такая частая? В любой бухгалтерской или подобной программе их до фига и больше. И я не хочу при расчёте искать магические числа - слишком много времени тратится не на то и слишком трудная для понимания становится программа. Как думаешь - её поймёт кто-нибудь, кроме её написавшего? А это одно из основных правил при программировании.
Давай всё таки пару табличек с базами?

Ну письмо с вирусом элементарно отличить от нормального, а про документы не особо понятно, это .doc и .mdb с макросами чтоли? Если так, откуда таким инфицированным файлам на серваке браться то..


Я имел в виду родной софт под линукс, но бухгалтерии под него увы не написали.. а если бы она была это смахивает на идеальный вариант для слабого компа, но нет так нет.


Есть много прикладного софта где производительность нужна, фотошоп системным не назовёшь, но и на интерпретируемом языке тоже писать не стоит.


В бухгалтерских программах скорее испрользуется деление с плавающей точкой(FDIV, FIDIV), а не целочисленное. Оно выполняется на несколько тактов быстрее, но оптимизировать его в отличии от DIV нельзя, да и не надо.
Хороший пример кстати - перевод десятичного числа в строку, там используется деление на 10 в цикле и замена его умножением и сдвигом сильно ускоряет процесс. А при работа с документами такие процедуры очень часто вызываются.
Понимание программы зависит от структуры и комментариев больше. Например если опять же использовать оптимизированное деление в обособленной функции преобразования числа в строку, то синтаксис вызова не изменится, а вовнутрь смотреть никто и не будет, по названию понятно что такая функция делает.


Это надо изучать формат файлов допустим mdb или dbf, писать на асме библиотеку(это ведь есть главная часть, отвечающая за производительность, интерфейс можно хоть на VB делать, особо медленнее от этого не станет), это очень долго надо трудиться, конечно быстрее ODBC заюзать или фокс там какой-нибудь поставить, но с другой стороны эту библиотеку можно будет во всех будущих проектах использовать и всё же думаю побыстрее получится

dragon Как отличить?
Ты опять судишь по своей ситуации и игнорируешь мою. У меня на предыдущем месте работы тоже подобных проблем не было. Но здесь то они есть.
А я говорю про имеющийся софт. Даже если бы была под него бухгалтерия, то вряд ли бы я её взял. Меня интересует распространённость софта, наличие готовых решений под него и квалифицированных кадров, умеющих с ним работать. С Линкусом проблема по всем пунктам, как с ним самим, так и с прикладным ПО. А ведь мне не только бухгалтерию надо. Да и средства разработки мне нужны под него соответствующие. С++ без визуальной среды не предлагать.
С Фотошопом соглашусь. Но многие бухгалтерские программы - интерпретируемые. Хотя и там производительность нужна. Но она приносится в жертву простоте обновления ПО. Куча прикладного ПО на Фоксе - интерпретируема. Таблицы в Excel, базы в Access - интерпретируемы. Текстовый редактор MultiEditor - интерпретируемый. Список можно продолжать. В него даже игрушки попадут. И в большинстве этих задач производительность тоже важна.
Нормальные программисты никогда не будут использовать числа с плавающей точкой для таких расчётов, если есть альтернатива. Чревато большими погрешностями при вычислениях. Для этого есть специальный тип с фиксированной точкой.
Не только с документами. При выводе любого числа на экран будет использоваться подобная процедура. Но для ввода используются готовые функции языка программирования. Заменить их другими, своими, процедурами не получится.
Отнюдь. У некоторых программистов настолько экзотический стиль программирования, что комментировать придётся слишком много. Проще написать сам код иначе.
Ты забываешь, что если при написании программы придерживаться определённых правил при именовании процедур, переменных и констант, не забывать делать отступы и т.д., то читаемость программы возрастает в несколько раз даже без помощи комментариев.

На написание этой библиотеки у тебя уйдёт так много времени, что программа уже будет не нужна. Вот потому асм и остался для достаточно узкого круга задач. Но и не исчезнет никогда. Т.к. ассемблером называют язык команд процессора. А любому процессору нужен свой язык. И всегда будет нужно некоторые куски кода написать эффективно с точки зрения производительности.

МОжно что нить вычеслительное
Например найти интеграл с определеной точностью
Или найти с числами фибоначи что нить

nickyoz Имхо, здесь асм выиграет однозначно.
Кстати, в своё время разработчики последней версии Clarion под ДОС утверждали, что скорость арифметических вычислений не уступает языкам С и Паскаль. Они объедились с фирмой TopSpeed, которая выпускала компиляторы С, С++ и Модула, и взяли их компилятор и линкер. Можем попробовать, если дадите алгоритм.

IgLowy кажется встречался то ли с Адой, то ли с Модулой от ТопСпил - впечатления ужасные.
Fortran

Daemon Наверно с Модулой-2. Для Ады я не встречал компиляторов на PC вообще, а у ТопСпид в частности. А что там ужасного? Обычная среда разработки под ДОС. Достаточно хороший компилятор по скорости компиляции и по эффективности кода. Фирменная фишка: единые компилятор и линкер для всех языков семейства. Разница в прекомпиляторе в некий промежуточный код, из которого и выполняется компиляция.
Нет. Самый близкий к ассемблеру язык - Си. При нормальной реализации компилятора он должен быть наиболее близок к нему по скорости кода. Хотя для арифметических выражений, наверно, все компилируемые языки близки.

IgLowy Точно, под PC - Object Ada от Aonix, вот с ней имел дело.
Ужасная среда, в плане того, что хуже, чем продукты от Бормана, компилить дико не удобно, набивал текст в блокноте и собирал руками. А еще паралельное исполнение реализовано ужасно
Вот не понимаю, почему все говорят, что он близок к асму. И почему он должен быть быстрее С++ (не использовать чисто сиппшные примочки, и скорость будет по идее на уровне). Насчет фортрана - тестов увы ненашел, но много раз слышал, что он наиболее быстрый в арифметических выражениях, подкрепить линком немогу.

Это имхо потому что глядя на Си создаётся впечатление что он создан не только для программеров, но и для писателей компиляторов

(обосновывать конкретнее не буду, уж слишком это субъективно)

Daemon Тогда согласен. Но это не ТопСпид. У них традиционная среда в стиле упрощённого Турбо. Среда одинакова для всех языков семейства. Если ставишь сразу нескольо языков, то можешь писать смешанные проекты.
А тебе надо было что-то типа Multi-Editor-а найти. Там и выделение синтаксиса было для языков программирования и подключение компилятора.
Ну его так делали, что он очень многие вещи использует чисто асмовские. Например, объявления строк, как указателя на массив символов. Или такие операторы, как инкрементальное сложение и вычитание. i++ - это же точная копия команды inc. Ни в одном другом языке нет такого количества наворотов для доступа к ресурсам процессора и ОС. Самый гибкий язык при написании системных вещей. В некоторых источниках Си называли языком среднего уровня. А не высокого, как Паскаль или Фортран.
Си быстрее чем С++, если С++ использует классы. При работе с чистым Си производительность С++ практически такая же. Сужу по тестам, которые в своё время читал.
Тоже слышал аналогичное. Но не помню, как он смотрелся по сравнению с Си.

virus Это не только кажется. Так и было. Насколько помню историю создания Си, его разработали для написания системы Unix. Разработчики языка были недовольны малой наглядностью ассемблера и низкой эффективностью кода на других языках.