31

drBatty пишет:

да откуда?! там половина ПО из 90х, а вторая - вообще непонятно откуда. да и код полон грязными хаками и ассемблерными вставками - о портировании никто не думал никогда.

"Не там" половина ПО вообще из 70х, и ничего, портируется куда-то. Это я к тому, что если проект "живой", то значит сорцы его никто никуда не терял, над ними продолжают работать. Если проект давно заброшен, исходники затерты, авторы уехали на Луну, то и хрен бы с ним, в сущности.

drBatty пишет:

да проще (В РАЗЫ!) 1000 строк переписать, чем 10 строчек в 100 местах. Эти 10 строк жёстко встроены в код, причём их нельзя переписывать буквально - они в самых критических местах. А разные хаки ещё и искать надо.

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

drBatty пишет:

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

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

32

Iskan Der пишет:

"Не там" половина ПО вообще из 70х, и ничего, портируется куда-то.

"здесь" - из 60х bx
я имел ввиду, чем "они" сейчас пользуются...

Iskan Der пишет:

Это я к тому, что если проект "живой", то значит сорцы его никто никуда не терял, над ними продолжают работать. Если проект давно заброшен, исходники затерты, авторы уехали на Луну, то и хрен бы с ним, в сущности.

а если проект стОит того? но требует ядра 2.4? почему не переделать? даже если автор на луне... "У них" это сплошь и рядом, а решения нет, и не будет. Потому они уже лет 15 юзают одну и туже ОС (а что, разве ПО для Win2k не идёт в ХП, коей сейчас большинство? А под ARM не пойдёт. Ни ПО ни сама ХП)

Iskan Der пишет:

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

а вот и нет - процы шустрее, но и объём данных в разы больше - ресурсов ВСЕГДА мало.

Iskan Der пишет:

В итоге многие эти вставки можно вообще к чертям выкинуть и заменить нормальным кодом на С.

в новом коде C вставки, а сама программа на каком-нить python'е bx пример: mercurial.

Iskan Der пишет:

А так да, не утверждаю, что будет легко, но в целом все вполне реализуемо. Если действительно нужно.

угу. я к тому, что быстрее с нуля. используя новые ЯП, новые ОС, и новые CPU. Вот только это ОЧЕНЬ дорого, если нет исходников. вот и будут они сидеть на XP и x86.

Iskan Der пишет:

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

ИМХО это как тот случай, когда есть смысл начать с нуля (в смысле кода. а бренд можно и старый конечно, ну и сюжет... а мы о технической стороне, про сюжеты и бренды я не в курсе).

Карусель разнесло по цепочке за час
Всех известий — конец
Да, весна началась!
(всё к лицу подлецу, как родному отцу, не рассказывай, батя, и так всё пройдёт)

33

drBatty пишет:

а если проект стОит того? но требует ядра 2.4? почему не переделать? даже если автор на луне... "У них" это сплошь и рядом, а решения нет, и не будет. Потому они уже лет 15 юзают одну и туже ОС (а что, разве ПО для Win2k не идёт в ХП, коей сейчас большинство? А под ARM не пойдёт. Ни ПО ни сама ХП)

Насчет "сплошь и рядом" - это уже ваши домыслы. Большинство пользуется достаточно свежим софтом, новые версии которого регулярно выходят, т.е. исходники еще никем не потеряны. Если оно того будет стоить, переедут и на ARMы, деваться некуда.

drBatty пишет:

а вот и нет - процы шустрее, но и объём данных в разы больше - ресурсов ВСЕГДА мало.

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

drBatty пишет:

в новом коде C вставки, а сама программа на каком-нить python'е bx пример: mercurial.

Тем проще такой код портировать куда-нибудь ab

drBatty пишет:

я к тому, что быстрее с нуля. используя новые ЯП, новые ОС, и новые CPU

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

drBatty пишет:
Iskan Der пишет:

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

ИМХО это как тот случай, когда есть смысл начать с нуля

Это один из элементов "русского" подхода к программированию: зачем разгребать чужой старый код, лучше забить на него (а также на бразилионы денег, потраченных в свое время на его создание) длинный толстый болт и написать все с нуля. Даже НацОС по такому сценарию ваять хотели поначалу, да вроде одумались ab

34

Iskan Der пишет:

Насчет "сплошь и рядом" - это уже ваши домыслы. Большинство пользуется достаточно свежим софтом, новые версии которого регулярно выходят, т.е. исходники еще никем не потеряны. Если оно того будет стоить, переедут и на ARMы, деваться некуда.

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

Iskan Der пишет:

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

Ммм... Не правильный пример. Объёмы - дело вторичное. А вот скорость разработки/доработки - первичное. То есть важна надёжность и возможность допилить быстро.

Iskan Der пишет:

Тем проще такой код портировать куда-нибудь smile

И тем не менее - всё тот же хак...

Iskan Der пишет:

Это один из элементов "русского" подхода к программированию: зачем разгребать чужой старый код, лучше забить на него (а также на бразилионы денег, потраченных в свое время на его создание) длинный толстый болт и написать все с нуля. Даже НацОС по такому сценарию ваять хотели поначалу, да вроде одумались smile

Да... лучше тащить корыто старых багов, аки M$... Ага...

35

Iskan Der пишет:

Насчет "сплошь и рядом" - это уже ваши домыслы. Большинство пользуется достаточно свежим софтом,

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

Iskan Der пишет:

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

Iskan Der пишет:

Тем проще такой код портировать куда-нибудь smile

дык я и не спорю - ассемблерные вставки даю мизерный выигрыш (потому что даже x86 много разных, всё вроде-бы работает, но не быстрее С), и к тому-же традиционно дороги (времени на них много уходит).

Iskan Der пишет:

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

это ясно. просто такие случаи очень частые. да и потом, вторая версия - скомпиллим, третья - скомпиллим... Рано и поздно всё рухнет... Вспомним Win98 или скажем KDE3...

Iskan Der пишет:

Это один из элементов "русского" подхода к программированию: зачем разгребать чужой старый код, лучше забить на него (а также на бразилионы денег, потраченных в свое время на его создание) длинный толстый болт и написать все с нуля. Даже НацОС по такому сценарию ваять хотели поначалу, да вроде одумались smile

ага, БГ тоже так думал, и тратил деньги на написание миллинниума. а зачем он рюшечки привинчивал ненужные, на серверную NT5?
а что такую классную KDE3 похоронили? заменили на KDE4, в которой во втором релизе(sic!) всё падало и глючило? да... это всё русские bx

Карусель разнесло по цепочке за час
Всех известий — конец
Да, весна началась!
(всё к лицу подлецу, как родному отцу, не рассказывай, батя, и так всё пройдёт)

36

zerg пишет:

Таки всё не так... Исходники и сами разработчики потерялись давным давно...

Это у кого? Сорцы офиса и фотошопа, думаю, у кого-нибудь да найдутся ab Много ли таких "заброшенных" проектов, пользующихся большой популярностью (и не имеющих замен)?

zerg пишет:

Ммм... Не правильный пример. Объёмы - дело вторичное. А вот скорость разработки/доработки - первичное. То есть важна надёжность и возможность допилить быстро.

По части скорости разработки/доработки ассемблер очень мало когда с ЯВУ может конкурировать.

Iskan Der пишет:

Тем проще такой код портировать куда-нибудь smile

И тем не менее - всё тот же хак...

zerg пишет:

Да... лучше тащить корыто старых багов, аки M$... Ага...

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

37

drBatty пишет:

ага, БГ тоже так думал, и тратил деньги на написание миллинниума. а зачем он рюшечки привинчивал ненужные, на серверную NT5?
а что такую классную KDE3 похоронили? заменили на KDE4, в которой во втором релизе(sic!) всё падало и глючило? да... это всё русские bx

Я не утверждаю, что каждую идею нужно насиловать до конца времен, но выкидывать все старые наработки просто потому, что все равно на другой процессор переезжаем - как-то расточительно, не находите? Даже в самой правильной в мире ОС - линуксе - наверняка найдется немало кода, написанного/спроектированного еще в раннем палеозое. И ничего, живет.

38

Iskan Der пишет:

По части скорости разработки/доработки ассемблер очень мало когда с ЯВУ может конкурировать.

Где я писал обратное?

39

Iskan Der пишет:

По части скорости разработки/доработки ассемблер очень мало когда с ЯВУ может конкурировать.

за то был в разы быстрее. когда процессоры были все одинаковые и простые, вроде i8086, сейчас они слишком сложные, и всего просто не упомнишь, и никто не будет 10 лет изучать i80586. а компилятор - он всё помнит, потому, несмотря на довольно большую неадекватность, делает код быстрее. И меньше (а потому - ещё быстрее). потому сейчас ИМХО асмом пользуются только кодеры всяких ОЭВМ с оперативной памятью а 4кб ab   (это мне смешно, им - не очень)

Iskan Der пишет:

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

часто и запрещает и мешает то, что все блоки взаимосвязаны. а написать аналог на C просто невозможно (вот например BSR, на i80486 6-103 такта, слабо такое на C? И мне слабо. Думаю даже на 686м и то дольше будет. Следовательно, менять весь алгоритм. А вставки как раз туда и ставили, где без них никак. BSR ведь не просто так придумали? Ага - нужно. Вот только мою реализацию на С этой BSR самый умный компилятор в неё не свернёт)

Iskan Der пишет:

Даже в самой правильной в мире ОС - линуксе - наверняка найдется немало кода, написанного/спроектированного еще в раннем палеозое. И ничего, живет.

подтверждаю: ChangeLog sed начинается с Thu Mar 23 18:04:46 1989, ЕМНИП с нуля никогда не переписывалась. А зачем? bx
(на самом деле это я про Linux-версию)

Карусель разнесло по цепочке за час
Всех известий — конец
Да, весна началась!
(всё к лицу подлецу, как родному отцу, не рассказывай, батя, и так всё пройдёт)

40

drBatty пишет:
Iskan Der пишет:

По части скорости разработки/доработки ассемблер очень мало когда с ЯВУ может конкурировать.

за то был в разы быстрее. когда процессоры были все одинаковые и простые, вроде i8086, сейчас они слишком сложные...потому сейчас ИМХО асмом пользуются только кодеры всяких ОЭВМ с оперативной памятью а 4кб ab

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

drBatty пишет:

часто и запрещает и мешает то, что все блоки взаимосвязаны. а написать аналог на C просто невозможно...

Вопрос в том, так уж ли много такого ассемблерного кода, который нельзя заменить на С-шный аналог без существенного проигрыша в производительности? У меня таких данных нет.

41

Iskan Der пишет:

Вопрос в том, так уж ли много такого ассемблерного кода, который нельзя заменить на С-шный аналог без существенного проигрыша в производительности? У меня таких данных нет.

ИМХО - много. но данных тоже нет, как и исходников... скачать что-ли с торрента сырцы NT5... говорят уже есть...

Карусель разнесло по цепочке за час
Всех известий — конец
Да, весна началась!
(всё к лицу подлецу, как родному отцу, не рассказывай, батя, и так всё пройдёт)