А нужды не будет.
На "нет" и суда нет :) Ровно как и победы ARMа над всеми остальными...
LinuxForum.Fans
NVIDIA: ARM победит x86 [ferra.ru]
Автор: renegat
41 сообщений
7410 просмотров
Код жёстко завязан на MS-диалекты C/C++.
Откуда ж тогда порты игр под другие ОСи берутся-то, хотелось бы знать? Опять же, проблема диалектов принципиально решаема набором подходящих define'ов.
Откуда ж тогда порты игр под другие ОСи берутся-то, хотелось бы знать?
OK!
Квака, US Army, ... Эээ!?
В смысле - ещё вменяемые порты с графикой не-двадцатилетней давности?
Не, я уже несколько лет тупо не играю ни во что (на компе) - могу чего-то и не знать,
так что, если вас не затруднит - назовите, пожалуйста, кого можно считать ныне равноценно с wintel портированным?
Не, я уже несколько лет тупо не играю ни во что (на компе) - могу чего-то и не знать,
так что, если вас не затруднит - назовите, пожалуйста, кого можно считать ныне равноценно с wintel портированным?
Я, прямо скажем, тоже в геймерах не числюсь, так что не особо в курсе. Из свежака могу припомнить второй Starcraft - есть под Mac, Left4Dead маковый тоже намечается в ближайшее время. Ранее упомянутый MaxPayne, опять же, вышел, как я понимаю, примерно в одно время с виндовой версией.
Одним словом, как я уже отмечал, портирование вполне себе возможно, главное, чтобы оно было признано целесообразным.
портирование вполне себе возможно
Но не зря же вы помянули "целесообразность" -
речь идёт о вполне конкретных немаленьких ресурсах (тугрики - рулят),
без которых о портировании - стоит ли вообще заводить разговор?
На коленке этот подвиг - не совершить!
Если не верите - заезжайте в гости, порубимся
Ок, куда приземлятся? С собой могу захватить SC & SC:BW. В назидание о том, что исключения бывают в любом правиле.
Да к чему все эфти условности?
Десантируйся к нам, на Питер. Мы тебя небольно препарируем, чес слово!
Мы тебя небольно препарируем, чес слово!
Зная Питерцев, чтобы было не больно, надо без московских госномеров приземлятся...
Но не зря же вы помянули "целесообразность" -
речь идёт о вполне конкретных немаленьких ресурсах (тугрики - рулят),
без которых о портировании - стоит ли вообще заводить разговор?
На коленке этот подвиг - не совершить!
А кто говорит про "на коленке"? У нас была предпосылка, что православный ARM побеждает богомерзкий х86, так что производителям ПО, в сущности, особо некуда деваться, кроме как вкладывать те самые немалые ресурсы в портирование. Конкретно в данный момент позиции х86 сильны весьма и весьма, так что заморачиваться переездом на другие архитектуры, понятно, никто не станет.
У того, кто их пишет, исходники, я полагаю, есть.
да откуда?! там половина ПО из 90х, а вторая - вообще непонятно откуда. да и код полон грязными хаками и ассемблерными вставками - о портировании никто не думал никогда.
Вставки - они на то и вставки, что небольшие по размеру (как правило), так что переписать их на другой ассемблер не так уж и трудно.
да проще (В РАЗЫ!) 1000 строк переписать, чем 10 строчек в 100 местах. Эти 10 строк жёстко встроены в код, причём их нельзя переписывать буквально - они в самых критических местах. А разные хаки ещё и искать надо.
в не-win пишут для копирования строки while(*d++ = *s++); оно везде не совсем оптимально, и не всегда самое быстрое. В win оптимизируют, ибо - быстрее... Но - тоже на C (в x86 изначально есть команда копирования строк в самом процессоре, причём её логика работы не меняется с i8086, потому быстрее будет найти длину строки (тоже 1 команда, и быстрая причём), а потом перебросить, т.е. strlen(), memcpy(), в других программах логика другая, и это очень критичная функция может работать на порядок медленнее, и таких мест - через каждые 5 строк) И это не асмовые вставки, и не портабельный код, гда пишут:
#ifdef x86
код для х86
#else
while(*d++ = *s++);
#endif
такое и без патча будет работать неплохо, и найти просто, а там - просто тупо код - как его найти? в маленькой программке на 10000 строк?!
Откуда ж тогда порты игр под другие ОСи берутся-то, хотелось бы знать? Опять же, проблема диалектов принципиально решаема набором подходящих define'ов.
игры уже давно пишут по человечески, да и цикл там короткий - Quake2 сегодня летать будет в виртуальной машине и на отстойном железе, и на другой платформе, да и не нужен он никому.
да откуда?! там половина ПО из 90х, а вторая - вообще непонятно откуда. да и код полон грязными хаками и ассемблерными вставками - о портировании никто не думал никогда.
"Не там" половина ПО вообще из 70х, и ничего, портируется куда-то. Это я к тому, что если проект "живой", то значит сорцы его никто никуда не терял, над ними продолжают работать. Если проект давно заброшен, исходники затерты, авторы уехали на Луну, то и хрен бы с ним, в сущности.
да проще (В РАЗЫ!) 1000 строк переписать, чем 10 строчек в 100 местах. Эти 10 строк жёстко встроены в код, причём их нельзя переписывать буквально - они в самых критических местах. А разные хаки ещё и искать надо.
Насчет "проще" - не спорю.
Насчет самих вставок: тут смотря какие вставки. Практика затыкания критических мест ассемблером, насколько я могу судить, уже давно вышла из моды: процы стали шустрее, компиляторы - умнее и т.п. В итоге многие эти вставки можно вообще к чертям выкинуть и заменить нормальным кодом на С.
А так да, не утверждаю, что будет легко, но в целом все вполне реализуемо. Если действительно нужно.
игры уже давно пишут по человечески, да и цикл там короткий - Quake2 сегодня летать будет в виртуальной машине и на отстойном железе, и на другой платформе, да и не нужен он никому.
Насчет "по-человечески" еще можно поспорить, ну да ладно, а вот про короткий цикл вы зря: игровые движки не так часто с нуля создаются, у многих из них ноги еще из бородатых годов растут.
"Не там" половина ПО вообще из 70х, и ничего, портируется куда-то.
"здесь" - из 60х ;)
я имел ввиду, чем "они" сейчас пользуются...
Это я к тому, что если проект "живой", то значит сорцы его никто никуда не терял, над ними продолжают работать. Если проект давно заброшен, исходники затерты, авторы уехали на Луну, то и хрен бы с ним, в сущности.
а если проект стОит того? но требует ядра 2.4? почему не переделать? даже если автор на луне... "У них" это сплошь и рядом, а решения нет, и не будет. Потому они уже лет 15 юзают одну и туже ОС (а что, разве ПО для Win2k не идёт в ХП, коей сейчас большинство? А под ARM не пойдёт. Ни ПО ни сама ХП)
Насчет самих вставок: тут смотря какие вставки. Практика затыкания критических мест ассемблером, насколько я могу судить, уже давно вышла из моды: процы стали шустрее, компиляторы - умнее и т.п.
а вот и нет - процы шустрее, но и объём данных в разы больше - ресурсов ВСЕГДА мало.
В итоге многие эти вставки можно вообще к чертям выкинуть и заменить нормальным кодом на С.
в новом коде C вставки, а сама программа на каком-нить python'е ;) пример: mercurial.
А так да, не утверждаю, что будет легко, но в целом все вполне реализуемо. Если действительно нужно.
угу. я к тому, что быстрее с нуля. используя новые ЯП, новые ОС, и новые CPU. Вот только это ОЧЕНЬ дорого, если нет исходников. вот и будут они сидеть на XP и x86.
Насчет "по-человечески" еще можно поспорить, ну да ладно, а вот про короткий цикл вы зря: игровые движки не так часто с нуля создаются, у многих из них ноги еще из бородатых годов растут.
ИМХО это как тот случай, когда есть смысл начать с нуля (в смысле кода. а бренд можно и старый конечно, ну и сюжет... а мы о технической стороне, про сюжеты и бренды я не в курсе).
а если проект стОит того? но требует ядра 2.4? почему не переделать? даже если автор на луне... "У них" это сплошь и рядом, а решения нет, и не будет. Потому они уже лет 15 юзают одну и туже ОС (а что, разве ПО для Win2k не идёт в ХП, коей сейчас большинство? А под ARM не пойдёт. Ни ПО ни сама ХП)
Насчет "сплошь и рядом" - это уже ваши домыслы. Большинство пользуется достаточно свежим софтом, новые версии которого регулярно выходят, т.е. исходники еще никем не потеряны. Если оно того будет стоить, переедут и на ARMы, деваться некуда.
а вот и нет - процы шустрее, но и объём данных в разы больше - ресурсов ВСЕГДА мало.
Общался со знакомыми, пишут софт для банков. Объемы данных - суровые крайне. Ассемблерные вставки не используют вообще, ибо возни много, а выигрыш в производительности получается довольно скромный. Если данных действительно много, эффективнее использовать соответствующие подходы к организации вычислений (типа GPGPU), нежели пытаться взвалить на себя работу компилятора.
в новом коде C вставки, а сама программа на каком-нить python'е ;) пример: mercurial.
Тем проще такой код портировать куда-нибудь :)
я к тому, что быстрее с нуля. используя новые ЯП, новые ОС, и новые CPU
Быстрее или нет - надо разбираться в каждом конкретном случае. Какой-то софт вообще достаточно будет просто перекомпилировать под новую платформу, с каким-то придется возиться, а вот так однозначно говорить сразу за всех будет неправильно.
[quote=Iskan Der]Насчет "по-человечески" еще можно поспорить, ну да ладно, а вот про короткий цикл вы зря: игровые движки не так часто с нуля создаются, у многих из них ноги еще из бородатых годов растут.
ИМХО это как тот случай, когда есть смысл начать с нуля[/quote]
Это один из элементов "русского" подхода к программированию: зачем разгребать чужой старый код, лучше забить на него (а также на бразилионы денег, потраченных в свое время на его создание) длинный толстый болт и написать все с нуля. Даже НацОС по такому сценарию ваять хотели поначалу, да вроде одумались :)
Насчет "сплошь и рядом" - это уже ваши домыслы. Большинство пользуется достаточно свежим софтом, новые версии которого регулярно выходят, т.е. исходники еще никем не потеряны. Если оно того будет стоить, переедут и на ARMы, деваться некуда.
Таки всё не так... Исходники и сами разработчики потерялись давным давно... А вот толпа индусов, которая пишет новые плагины и перекраивает мордочку, а так же изменяет/добавляет функционал навешивая это поверх - осталась. И в этом салате никто уже и не помнить, какими там вызовами что-либо из ядра получать надо. Проще свою библиотеку рядом положить.
Общался со знакомыми, пишут софт для банков. Объемы данных - суровые крайне. Ассемблерные вставки не используют вообще, ибо возни много, а выигрыш в производительности получается довольно скромный. Если данных действительно много, эффективнее использовать соответствующие подходы к организации вычислений (типа GPGPU), нежели пытаться взвалить на себя работу компилятора.
Ммм... Не правильный пример. Объёмы - дело вторичное. А вот скорость разработки/доработки - первичное. То есть важна надёжность и возможность допилить быстро.
Тем проще такой код портировать куда-нибудь smile
И тем не менее - всё тот же хак...
Это один из элементов "русского" подхода к программированию: зачем разгребать чужой старый код, лучше забить на него (а также на бразилионы денег, потраченных в свое время на его создание) длинный толстый болт и написать все с нуля. Даже НацОС по такому сценарию ваять хотели поначалу, да вроде одумались smile
Да... лучше тащить корыто старых багов, аки M$... Ага...
Насчет "сплошь и рядом" - это уже ваши домыслы. Большинство пользуется достаточно свежим софтом,
угу. софт свежий, но есть одна очень нужная программка, которую и заменить нечем. и новой не будет...
Ассемблерные вставки не используют вообще, ибо возни много, а выигрыш в производительности получается довольно скромный.
Тем проще такой код портировать куда-нибудь smile
дык я и не спорю - ассемблерные вставки даю мизерный выигрыш (потому что даже x86 много разных, всё вроде-бы работает, но не быстрее С), и к тому-же традиционно дороги (времени на них много уходит).
Быстрее или нет - надо разбираться в каждом конкретном случае. Какой-то софт вообще достаточно будет просто перекомпилировать под новую платформу, с каким-то придется возиться, а вот так однозначно говорить сразу за всех будет неправильно.
это ясно. просто такие случаи очень частые. да и потом, вторая версия - скомпиллим, третья - скомпиллим... Рано и поздно всё рухнет... Вспомним Win98 или скажем KDE3...
Это один из элементов "русского" подхода к программированию: зачем разгребать чужой старый код, лучше забить на него (а также на бразилионы денег, потраченных в свое время на его создание) длинный толстый болт и написать все с нуля. Даже НацОС по такому сценарию ваять хотели поначалу, да вроде одумались smile
ага, БГ тоже так думал, и тратил деньги на написание миллинниума. а зачем он рюшечки привинчивал ненужные, на серверную NT5?
а что такую классную KDE3 похоронили? заменили на KDE4, в которой во втором релизе(sic!) всё падало и глючило? да... это всё русские ;)
Таки всё не так... Исходники и сами разработчики потерялись давным давно...
Это у кого? Сорцы офиса и фотошопа, думаю, у кого-нибудь да найдутся :) Много ли таких "заброшенных" проектов, пользующихся большой популярностью (и не имеющих замен)?
Ммм... Не правильный пример. Объёмы - дело вторичное. А вот скорость разработки/доработки - первичное. То есть важна надёжность и возможность допилить быстро.
По части скорости разработки/доработки ассемблер очень мало когда с ЯВУ может конкурировать.
Тем проще такой код портировать куда-нибудь smile
И тем не менее - всё тот же хак...
Да... лучше тащить корыто старых багов, аки M$... Ага...
Во-первых, никто не запрещает причесывать старый код в ходе портирования (то же выкидывание ненужных ассемблеров я уже упоминал).
Во-вторых, это всяко лучше, чем изобретать с нуля велосипед каждый раз, когда надо сгонять в магазин за хлебом.
ага, БГ тоже так думал, и тратил деньги на написание миллинниума. а зачем он рюшечки привинчивал ненужные, на серверную NT5?
а что такую классную KDE3 похоронили? заменили на KDE4, в которой во втором релизе(sic!) всё падало и глючило? да... это всё русские ;)
Я не утверждаю, что каждую идею нужно насиловать до конца времен, но выкидывать все старые наработки просто потому, что все равно на другой процессор переезжаем - как-то расточительно, не находите? Даже в самой правильной в мире ОС - линуксе - наверняка найдется немало кода, написанного/спроектированного еще в раннем палеозое. И ничего, живет.
По части скорости разработки/доработки ассемблер очень мало когда с ЯВУ может конкурировать.
Где я писал обратное?
По части скорости разработки/доработки ассемблер очень мало когда с ЯВУ может конкурировать.
за то был в разы быстрее. когда процессоры были все одинаковые и простые, вроде i8086, сейчас они слишком сложные, и всего просто не упомнишь, и никто не будет 10 лет изучать i80586. а компилятор - он всё помнит, потому, несмотря на довольно большую неадекватность, делает код быстрее. И меньше (а потому - ещё быстрее). потому сейчас ИМХО асмом пользуются только кодеры всяких ОЭВМ с оперативной памятью а 4кб :) (это мне смешно, им - не очень)
Во-первых, никто не запрещает причесывать старый код в ходе портирования (то же выкидывание ненужных ассемблеров я уже упоминал).
Во-вторых, это всяко лучше, чем изобретать с нуля велосипед каждый раз, когда надо сгонять в магазин за хлебом.
часто и запрещает и мешает то, что все блоки взаимосвязаны. а написать аналог на C просто невозможно (вот например BSR, на i80486 6-103 такта, слабо такое на C? И мне слабо. Думаю даже на 686м и то дольше будет. Следовательно, менять весь алгоритм. А вставки как раз туда и ставили, где без них никак. BSR ведь не просто так придумали? Ага - нужно. Вот только мою реализацию на С этой BSR самый умный компилятор в неё не свернёт)
Даже в самой правильной в мире ОС - линуксе - наверняка найдется немало кода, написанного/спроектированного еще в раннем палеозое. И ничего, живет.
подтверждаю: ChangeLog sed начинается с Thu Mar 23 18:04:46 1989, ЕМНИП с нуля никогда не переписывалась. А зачем? ;)
(на самом деле это я про Linux-версию)
[quote=Iskan Der]По части скорости разработки/доработки ассемблер очень мало когда с ЯВУ может конкурировать.
за то был в разы быстрее. когда процессоры были все одинаковые и простые, вроде i8086, сейчас они слишком сложные...потому сейчас ИМХО асмом пользуются только кодеры всяких ОЭВМ с оперативной памятью а 4кб :)[/quote]
Об чем и речь. Надо ли при таких делах носиться с этим ассемблером аки дураку с фантиками или можно под шумок повыкидывать отовсюду, где возможно?
часто и запрещает и мешает то, что все блоки взаимосвязаны. а написать аналог на C просто невозможно...
Вопрос в том, так уж ли много такого ассемблерного кода, который нельзя заменить на С-шный аналог без существенного проигрыша в производительности? У меня таких данных нет.
Войдите или зарегистрируйтесь, чтобы ответить.
