133 ответов в теме

[Kratrock]

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

Тут кстати интересный момент.
Раньше, очень давно =) , код писали с учетом тактов процессора, с учетом архитектуры.
Писался жестко и четко, на асме.
И иногда я вот задумываюсь - сколько пустых операций делает компьютер. Даже не совсем так.. Я не задумываюсь, я знаю, как любой кто дизасемблил когда-либо порграмму.
В итоге - копмьютеры делают много "пустой" работы.
А ведь хочется производительности, как операционной системы (что особенно хочется), так и хотя бы движков игр.

[Batyr Khan]

Тут кстати интересный момент.
Раньше, очень давно =) , код писали с учетом тактов процессора, с учетом архитектуры.
Писался жестко и четко, на асме.
И иногда я вот задумываюсь - сколько пустых операций делает компьютер. Даже не совсем так.. Я не задумываюсь, я знаю, как любой кто дизасемблил когда-либо порграмму.
В итоге - копмьютеры делают много "пустой" работы.
А ведь хочется производительности, как операционной системы (что особенно хочется), так и хотя бы движков игр.

К сожалению, есть жёсткий выбор:
* много, удобно, дёшево но неэффективно;
* мало, геморно, дорого но с максимальной эффективностью.

Причём работает это в любых областях, сравним армейский Хамви и Хаммер гражданского образца, или профессиональные фотоаппараты без сюжетных программ и встроенной вспышки и любительские с функцией "Хэппи фейс", или что угодно ещё. В итоге, на потребительском рынке подход номер один выигрывает всегда и без вариантов. На профессиональном баланс смещается в пользу второго.

[Finder]

В стародавние времена аппаратура не отличаласъ современным разнообразием, и можно было себе позволить, скажем, реализовать задержку пустым циклом с расчетом длины такта, чтобы она гарантированно работала на всех мыслимых клонах Z80. Но уже с появлением 286 или даже ранее грамотные люди понимают, что надо делать это куда большим количеством кода, через обращение к прерыванию таймера.
Опять-таки, в стародавние времена графические данные просто выводили в видеобуфер, и для всяких там обратно совместимых CGA-EGA-VGА это работало, но потом, с переходом на более продвинутые ОС и видеоадаптеры, перестало. Теперь для вывода картинки надо использовать системные вызовы, да еще и через всякие дополнительные прослойки типа OpenGL.

А если замучала ностальгия по DOS 3.30, могу напомнить и про тогдашние стелс-вирусы, к примеру - тоже по-своему шедевр программистской мысли. Только я с трудом представляю, что кому-то понравится садить свой бизнес на такую пороховую бочку.

[Tir]

А ведь хочется производительности, как операционной системы (что особенно хочется), так и хотя бы движков игр.

А дешёвых продуктов хочется? Филигранная работа стоит дороже, чем промышленная штамповка. Всегда и везде. В разы дороже. А хочется, чтобы новые игры выходили хотя бы раз в год, а не раз в 5-10 лет? Филигранная работа занимает больше времени, чем промышленная штамповка. Всегда и везде. В разы больше. А хочется, получать более-менее надёжный продукт? Раньше на один CD-диск умещалось по нескольку десятков, если не полторы сотни игр. Программы были небольшими. И отлаживать их соответственно было куда проще. На отладку игр современного масштаба, буде они написаны под такты процессора, уйдут годы, если не десятилетия.

P.S.: ну вот, пока писал, Батыр Хан примерно то же самое уже изложил

Сообщение отредактировал Tir: 16 January 2009 - 15:56

[deadok]

Раньше, очень давно =) , код писали с учетом тактов процессора, с учетом архитектуры.
Писался жестко и четко, на асме.

а кто сказал, что сейчас энто не делается?
какбе все стандартные оптимизации под проц, типа развертки циклов, встраивание функций, удаление повторяющихся вычислений выполняются компилятором.
вона в сях даже есть расширения, которые заставляют компилятор не делать оптимизаций куска кода.

на программиста ложится только выбор хорошего алгоритма/реализации и расчистка ботлнеков(что, в сущности тоже относится к выбору правильного алгоритма)

и ни разу нельзя сравнивать старые и новые игры - в старых играх количество фичь было гораздо меньшим, соотв-но было гораздо меньше мест, которые надо было бы оптимизировать.

ps/
1. хороший компилятор генерит код столь-же эффективный или немного менее эффективный, чем первоклассный кодер.
2. первоклассный кодер знает, с какими кусками кода компилятор справится не хуже него самого, и не тратит своего времени.
3. заурядный-хороший кодер не в состоянии достаточно верно оценить способности компилера, поэтому отказ от компилятора оправдан только в случае явно не расчищаемого другими средствами ботлнека.

Сообщение отредактировал deadok: 16 January 2009 - 16:41

[Finder]

Ты забываешь, что кодер еще должен уметь как-то распознать причину упомянутого боттлнека прежде чем лезть грязными ручонками в ассемблер. А для этого опять-таки, нужны четкие знания особенностей компилятора. И да, всякие там возможные побочные эффекты при расчистке боттлнека тоже надо учитывать - к примеру, в игрушке может быть и пофиг, что в пяти случаях из тысячи какое-то рутинное действие полъзователя приводит к фризу - никто ж не умер, но при 40к пользователей онлайн, служба поддержки задолбается петиции на reimbursement обрабатывать.

[deadok]

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

не понял.
"отказ от компилятора оправдан только в случае явно не расчищаемого другими средствами ботлнека."

[Finder]

Я это к тому, что у тебя в 3м пункте парадокс, либо речь идет о разных кодерах Если кодер не в состоянии правильно оценить возможности компилятора, то ему тем более не стоит лезть в лоулевел.

[deadok]

Я это к тому, что у тебя в 3м пункте парадокс, либо речь идет о разных кодерах Если кодер не в состоянии правильно оценить возможности компилятора, то ему тем более не стоит лезть в лоулевел.

нет никакого парадокса - если никакие другие методы не помогают, то почему бы не лезть в лоулевел? хуже от этого явно не будет.
и речь ессесно идет о разных кодерах.

[Kratrock]

К сожалению, есть жёсткий выбор:
* много, удобно, дёшево но неэффективно;
* мало, геморно, дорого но с максимальной эффективностью.

Причём работает это в любых областях, сравним армейский Хамви и Хаммер гражданского образца, или профессиональные фотоаппараты без сюжетных программ и встроенной вспышки и любительские с функцией "Хэппи фейс", или что угодно ещё. В итоге, на потребительском рынке подход номер один выигрывает всегда и без вариантов. На профессиональном баланс смещается в пользу второго.

Безусловно.
Но ты упомянул когда выбор есть.
В сфере программных продуктов его на данный момент нету. Была попытка оси на асме (основных компонентов) QNX, но она была сделана под строго определенные задачи, в которых и применяется.

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

Ну уже и помечтать низзя? =(
Ведь видя размер какого-нить кригера и производительность, очень быстро понимаешь, как могло бы быть.

Add: ...а еще мне вспомнилась элит и ее генерация галактики =)

Сообщение отредактировал Kratrock: 16 January 2009 - 17:43

[Skardo]

И иногда я вот задумываюсь - сколько пустых операций делает компьютер. Даже не совсем так.. Я не задумываюсь, я знаю, как любой кто дизасемблил когда-либо порграмму.
В итоге - копмьютеры делают много "пустой" работы.
А ведь хочется производительности, как операционной системы (что особенно хочется), так и хотя бы движков игр.

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

А вот если по каким-то причинам наращивать мощность железа больше будет нельзя или это будет очень-очень дорого (например, из-за каких-то физических ограничений или если законодательно запретят блоки питания мощнее киловатта ), тогда можно и на софт посмотреть. Если в него вложить столько же научных разработок, как и в железо, то и операционки, и движки будут гораздо эффективнее.

Я в институте работал над алгоритмами обработки данных, которые давали выигрыш по скорости в 10-30 раз по сравнению с существующими. Ну и что? Через 3 года железо развилось настолько, что стало справляться с задачей без новых алгоритмов, и все эти новые разработки отправились на полку. Возможно, когда-то они будут востребованы, но сейчас проще и дешевле купить новый комп.

Сообщение отредактировал Skardo: 16 January 2009 - 17:45

[Batyr Khan]

Но ты упомянул когда выбор есть.
В сфере программных продуктов его на данный момент нету. Была попытка оси на асме (основных компонентов) QNX, но она была сделана под строго определенные задачи, в которых и применяется.

Так я же писал: потребительский рынок и профессиональный рынок. На профессиональном есть высокоэффективные решения, оптимизированные и работающие в реалтайме, но абсолютно не подходящие для широкого использования. А на рынке потребительском живут достаточно эффективные для этого рынка Виндоус и *никсы (включая МакОС X). И никто не будет морочить себе голову их излишней оптимизацией -- не окупится.

[deadok]

В сфере программных продуктов его на данный момент нету. Была попытка оси на асме (основных компонентов) QNX, но она была сделана под строго определенные задачи, в которых и применяется.

MinuetOS.
x86 опенсорс, x64 - закрытый
проект активен

[Kratrock]

MinuetOS.
x86 опенсорс, x64 - закрытый
проект активен

Смотрел несколько лет назад, тогда был в стадии далекой от альфы. Сейчас не знаю как оно (оффтоп: всегда убивало название этой оси)

Еще из интересных осевых проектов помнится была reactos, когад последний раз смотрел - чего-то уже умела, но опять же - пре-альфа.