Предложение отказаться от ASM версии

← →
Yury Sidorov (2007-09-14 13:39) [0]

Моя ветка KOL-CE уже достаточно стабильна и в ближайшем будущем хотелось бы объединить мою и основную ветки. Кроме портирования под Lazarus и wince мной было сделано много исправлений и улучшений (например, скорость ScrollBox-а).

Но объединению мешает ASM версия, которую я у себя совсем не трогал. Т.е. PAS версия абсолютно рассинхронизирована с ASM версией, которая для FPC не используется вообще.

Плюсы ASM версии:
1. Экономия нексольких килобайт кода, но это актуально только для программ типа Hello world.

Минусы:
1. Трудно поддерживать асм и пас версии одновременно. Даже Владимиру Кладову.
2. Иногда асм и пас версии процедур работают по разному. Т.е. вероятность глюков удваивается.
3. У большинства пользователей KOL нет знаний или желания править асм версию.
4. Асм версия не применима для платформы arm-wince.
5. Асм версия не используется в FPC.
6. Асм версия почти не используетя для UNICODE.

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

← →
homm © (2007-09-14 13:58) [1]

Не нужен тебе, не значит что не нужен.

← →
homm © (2007-09-14 13:59) [2]

Проблема рассинхронизации обычно решается синхронизайией :)
А почему вообще в минусы ASM кода попало, что он не применим для каких-то платформ? Просто для количества?

← →
Vladimir Kladov (2007-09-14 14:14) [3]

Я категорически буду возражать, поскольку в отдельных случаях asm радикально ускряет работу. Мне он по крайней мере нужнее чем pas-версия.

Не нужен - есть условная компиляция.

← →
Yury Sidorov (2007-09-14 14:21) [4]

homm: А кто эту синхронизацию делать будет?
Для процессора arm ассемблерный код от х86 не подходит :)

Vladimir Kladov: Возможно логичнее найти некий баланс? Для критических к скорости участков кода оставить асм версию, а для всего остального убрать.
Условная компиляция есть, но проблема в рассинхронизации пас и асм версий...

← →
homm © (2007-09-14 14:26) [5]

> Для процессора arm ассемблерный код от х86 не подходит :)

Это минус ASM кода? Т.е. то, что компилятор дельфи не понимает моей устной речи является минусом самой речи, и мне от нее следует отказаться?

← →
homm © (2007-09-14 14:29) [6]

> а для всего остального убрать

Зачем?

> Условная компиляция есть, но проблема в рассинхронизации
> пас и асм версий...

Я так и не могу понять, в чем тут для тебя проблема; Ты не будешь синхронизировать для процессора, который его и не понимает. Кому плохо?

← →
Yury Sidorov (2007-09-14 14:40) [7]

> > Для процессора arm ассемблерный код от х86 не подходит
> :)
>
> Это минус ASM кода? Т.е. то, что компилятор дельфи не понимает
> моей устной речи является минусом самой речи, и мне от нее
> следует отказаться?

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

> > а для всего остального убрать
>
> Зачем?

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

> > Условная компиляция есть, но проблема в рассинхронизации
>
> > пас и асм версий...
>
> Я так и не могу понять, в чем тут для тебя проблема; Ты
> не будешь синхронизировать для процессора, который его и
> не понимает. Кому плохо?

Как я уже писал, я кое-что исправил/улучшил в пас версии и у меня нет желания делать то же самое в асм версии, т.к. я ее не использую. Поэтому если включить асм верси для KOL-CE и скомпилить под Дельфи, то работать будет все не так или вообще не будет работать.

Поддерживать пас и асм версии очень трудоемко. А искать баги в обеих версиях еще труднее.

← →
homm © (2007-09-14 15:03) [8]

> то ASM код нужно полностью писать заново...
Кому нужно? Он УЖЕ НАПИСАН для win32, почему его нужно менять или выкидывать?

> Затем, что большинство пользователей в ассемблере не шарят
No problem.

> В этом случае асм версия процедуры отключается и успешно
> забывается...
Потому что нет смысла 10 раз переписывать код, который еше не поностью протестирован, раз. Два: а почему из-за этого нужно отказываться от всего оастального УЖЕ НАПИСАННОГО кода?

> я кое-что исправил/улучшил в пас версии и у меня нет желания
> делать то же самое в асм версии
А что, кто-то требует? Почему изи-за этого нужно выключать УЖЕ НАПИСАННЫЙ код?

← →
Galkov © (2007-09-14 15:06) [9]

> и у меня нет желания делать то же самое в асм версии

Все-таки непонятно: кто мешает обложить изменения, не сопровождаемые в ASM, условной компиляцией ???

← →
Yury Sidorov (2007-09-14 15:40) [10]

По моему мнению, асм версия в таком объеме как сейчас мешает развитию.

Все-таки асм версия это был (есть?) способ уменьшить код еще больше для приложения типа Hello world. Эдакий proof of concept для KOL. Когда программа вырастает из этого, то +/-10КБ кода роли не играют. Тут большую роль играет безглючность. Думаю, Владимир, в этом убедился (убедится) разрабатывая свою зумер.
Для каких-то критических к скорости участков кода асм версия будет полезна. Но таких участков не так уж и много и сопровождать асм версию будет несложно.

Как ни печально, но судя по реакции на мое предложение, KOL-CE навсегда останется отдельной веткой :(

← →
Yury Sidorov (2007-09-14 15:41) [11]

homm: Да, асм код уже есть, но его нужно сопровождать и тянуть за собой дальше...

← →
homm © (2007-09-14 15:49) [12]

> Думаю, Владимир, в этом убедился (убедится) разрабатывая свою зумер.

Ты в серьез считаешь, что это првый/самый крупный проект Владимира? :))))

> KOL-CE навсегда останется отдельной веткой :(

И что припятствует его все-же попытаться объеденить? Религия, запрещающая находиться ASM коду, в модуле, над которым ты работаешь?

> Да, асм код уже есть, но его нужно сопровождать и тянуть
> за собой дальше...
Сопровождать? Писать документацию, или объяснять ка он работает? Тянуть? Из интернета что-ли скачивать? Остальный аргументы исскли, остались громкие фразы, за которыми ничего нет?

← →
Yury Sidorov (2007-09-14 15:56) [13]

> > Думаю, Владимир, в этом убедился (убедится) разрабатывая
> свою зумер.
>
> Ты в серьез считаешь, что это првый/самый крупный проект
> Владимира? :))))

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

На остальные вопросы ответы можно найти выше. Разводить флуд не буду...

← →
Galkov © (2007-09-14 16:08) [14]

> На остальные вопросы ответы можно найти выше

Не нашел.

> Все-таки непонятно: кто мешает обложить изменения, не сопровождаемые в ASM, условной компиляцией ???

← →
ANTPro © (2007-09-14 19:45) [15]

> [10] Yury Sidorov (14.09.07 15:40)
> По моему мнению, асм версия в таком объеме как сейчас мешает развитию.

Совсем не ASM версия мешает развитию.

> [10] Yury Sidorov (14.09.07 15:40)
> Как ни печально, но судя по реакции на мое предложение,
> KOL-CE навсегда останется отдельной веткой

Что мешает вынести весь Win32ASM в отдельный файл, а в КОЛ сделать пару больших {$ifdef}?

← →
Yury Sidorov (2007-09-14 22:57) [16]

ASM код и так почти весь в отдельном файле, а слиянию мешает рассинхронизация текущего PAS кода в KOL-CE с ASM кодом. Другими словами я менял только PAS код, а ASM код остался без изменений. Все.

← →
homm © (2007-09-14 23:30) [17]

> ASM код и так почти весь в отдельном файле, а слиянию мешает
> рассинхронизация текущего PAS кода в KOL-CE с ASM кодом.

Чем она тебе мешает???

← →
SPeller © (2007-09-15 06:17) [18]

Предлагаю не писать новые изменения в асм, и постепенно выкидывать тот асм-код, который перестает соответствовать пас-коду. И Юрий будет доволен, дав КОЛ поддержку win-ce, и homm и другие принципиальные поклонники асма тоже не будут ущемлены. Захотят оставить больше асм-кода - переведут изменения в асм и пришлют Владимиру.

← →
Vladimir Kladov © (2007-09-17 20:42) [19]

А я буду добавлять новые вещи на ассемблере. Меня интересует сейчас даже не компактность, а скорость. Я вот сделал сегодня заменитель для системной процедуры move, с оптимизацией на mmx. Дает 2-3% прироста скорости на смешанном тесте. И то хлеб. Иногда процентов не хватает, чтобы в кадр уложиться.

← →
Thaddy (2007-09-17 20:46) [20]

I propose something different:

In some ways I agree with Yuri, In some ways with Vlamidimr.

But there is a solution that I use myself for sometime internally:
I create "clean" versions by using the dipp.exe preprocessor to create the versions I want. I suggest a development tree is made:

-- kol main branch
|--Kol pascal branch //generated with DIPP
|-- kol pas barnch for FPC (with a diff/merge)
|-- kol pas branch for kolce (with a diff/merge)

That would mean maintainabilty for everyone.

← →
exero © (2007-09-17 21:19) [21]

Владимир, если Вас интересует скорость, то вопользуйтесь FastMM4 и FastMove. FastMove использует MMX, SSE, SSE2, SSE3 оптимизацию, в зависимости от процессора. Результат получится несколько более тяжелый, но скрость возрастет.

← →
Vladimir Kladov © (2007-09-17 21:48) [22]

Воспользоваться мало. Необходимо воспользоваться так, чтобы любой код, использующий вызов Move (и со ссылкой на kol.pas в uses) автоматически перенаправлялся на этот вариант move.

← →
GMax (2007-09-17 22:28) [23]

fastlib именно так и работает

← →
Thaddy (2007-09-17 23:03) [24]

It adds a lot of code,,,,
And It can already be used with KOL

← →
Galkov © (2007-09-17 23:18) [25]

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

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

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

Вот собственно и все. Просто следует понимать чего ты делаешь.
Мне скажем, показалось, что тот день затрат на ASM версию для Align - ничего не стоит по сравнению с затратами ВСЕХ пользователей KOL, которые будут иметь 1K кодов вместо 600 байт.
Поэтому взял, и сделал...

Ну или по другому.
В первом варианте имеет смысл вопрос: а надо ли кому-то этот выигриш в 400 байт ???

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

← →
SPeller (work) (2007-09-18 03:46) [26]

Да, но wince?

← →
SPeller (work) (2007-09-18 04:04) [27]

> а с какой такой радости ВСЕ пользователи должны получить
> даже один лишний байт кода ???

С такой же, с какой получают ненужный блокнот с виндой. Потому что всем не угодишь.

← →
D[u]fa © (2007-09-18 09:11) [28]

Yury Sidorov, а нельзя просто для KOL-Ce оставить пас версию и просто не юзать асм версию? в обычном коле буит две версии, а в СЕ тока пас... не пойму зачем все всех на пас перекидывать

← →
misha_shar © (2007-09-18 10:31) [29]

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

← →
Yury Sidorov (2007-09-18 11:39) [30]

D[u]fa: На данный момент KOL-CE и является тем, что будет после возможного объединения с основной веткой, т.к. по мере выхода новых версий KOL, я произвожу слияние изменений с основной веткой. KOL-CE в данный момент не использует асм версию и не предназначен для такого использования. И, как я уже писал:
я кое-что исправил/улучшил в пас версии и у меня нет желания делать то же самое в асм версии, т.к. я ее не использую. Поэтому если включить асм версию для KOL-CE и скомпилить под Дельфи, то работать будет все не так или вообще не будет работать.
Таким образом имеем разную функциональность в асм и пас версиях...

misha_shar: Хоть кто-то поддерживает :)

← →
homm © (2007-09-18 11:50) [31]

> [30] Yury Sidorov (18.09.07 11:39)
> Поэтому если включить асм версию для KOL-CE и скомпилить
> под Дельфи, то работать будет все не так или вообще не будет
> работать.
> Таким образом имеем разную функциональность в асм и пас
> версиях...

Блин, в тех функциях, в которых ты переделал PAS версию, ты можешь просто заменить
{$IFDEF ASM_VERSION} ……… ($ELSEIF ASM_VERSION} ……… {$ENDIF ASM_VERSION}
на
{$IFDEF ASM_noVERSION} ……… ($ELSEIF ASM_VERSION} ……… {$ENDIF ASM_VERSION}

Ивсе! И если «включить асм версию для KOL-CE и скомпилить под Дельфи» все будет работать точно так-же!!! Ну сколько одно и то-же то можно твердить!

← →
Yury Sidorov (2007-09-18 12:08) [32]

Конечно могу. Это в конце концов приведет к отсутствию асм версии для большинства функций. В итоге будет оптимальный вариант - асм версии только для критических к скорости функций. Практически весь TControl не является критическим к скорости...

Что скажет Владимир если я отключу асм для измененных функций?

← →
homm © (2007-09-18 12:12) [33]

> [32] Yury Sidorov (18.09.07 12:08)
> Что скажет Владимир если я отключу асм для измененных функций?

> [19] Vladimir Kladov © (17.09.07 20:42)
> А я буду добавлять новые вещи на ассемблере.

Если ты не в курсе, загляни в модуль KOL.pas, там много таким образом отключеных процедур.

← →
Yury Sidorov (2007-09-18 13:13) [34]

> Если ты не в курсе, загляни в модуль KOL.pas, там много
> таким образом отключеных процедур.

Я об этом упоминал в одном из постов.

← →
Galkov © (2007-09-18 14:01) [35]

> С такой же, с какой получают ненужный блокнот с виндой. Потому что всем не угодишь

Я не добавляю в свой продукт дополнительные "блокноты". Если Вы добавляете - это Ваши проблемы, и Ваших пользователей.

Предложение исключить ASM версию означает, что некто, кому религия не позволяет понимать происходящее (именно так я понимаю нежелание знать ASM) настаивает чтобы и я в свой продукт включал "блокнотики"

Именно так, и не иначе !!!
А Ваше ли это дело, господин предлагающий ???

← →
Yury Sidorov (2007-09-18 16:06) [36]

Galkov, не нужно здесь истерик.
Ассемблер я знаю. Как для х86, так и для arm. Просто я ценю свое время, даже не текущее, а будущее время, которое нужно будет тратить на поддержание асм кода. Для меня словосочетание "дальнейшая поддержка продукта" не пустой звук и я пытаюсь убрать грабли с дороги.
Всему свое применение. В том числе и ассемблеру...

На этой оптимистической ноте эту тему можно прикрыть.

> [36] Yury Sidorov (18.09.07 16:06)
> На этой оптимистической ноте эту тему можно прикрыть.

Т.е. ты уже все решил? :)

← →
Yury Sidorov (2007-09-18 16:19) [38]

Пока у меня желание что-то объединять отпало.

Со своей стороны я поотключаю асм версии измененных процедур и буду синхронизировать kol-ce с основной веткой. Так что все желающие могут пользовать kol-ce как объединенную ветку.

Опять же Владимир не желает пользовать svn, а мне без этого никак.
Поживем увидим...

Для меня использовать svn это просто увеличивать траффик. Потому чтообычный способ выкладывания мне все равно придется поддержать.

Я не вижу смысла выбрасывать ассемблер для PC он нужен. Несколько Кбайт экономии кода, + быстрее работает, что в нем плохого.

WinCE пусть лучше будет отдельной веткой если уж такая великая разница, что весь паскаль-код меняется. Мне WinCE запускать не на чем, разве что на эмуляторах, а это мне неинтересно.

Да посмотрел fastmove именно так и работает. И правда на том же тесте даёт почти двойной прирост скорости. Тогда не буду уже свой доделывать, раз такой хороший есть. (Интересно почему нет быстрого FillChar, или считается что быстрее уже точно некуда).

Великий расKOL... жаль.

← →
Sapersky (2007-09-18 17:59) [42]

Да посмотрел fastmove именно так и работает. И правда на том же тесте даёт почти двойной прирост скорости.

Если fastmove <> FastCode, то посмотрите ещё и последний. Там долго и вполне успешно оптимизируют борландовскую RTL, кое-что вроде даже включено в BDS2006.
Хотя, ИМХО, если скорость программы зависит от функций вроде Move/FillChar - проблема скорее в алгоритме, чем в функциях.

> [39] Vladimir Kladov © (18.09.07 17:20)
> Для меня использовать svn это просто увеличивать траффик.

Через toonel.net(сжатие трафика через прокси) огромная экономия.

Что касается FastCode - тут впечатление у меня сложилось двоякое, вроде и есть небольшой прирост скорости, но иногда (так и не разобрался с чем это связано) программа работала медленне чем без них (обработка данных занимала секунды 2, хотя без замены около 0.7сек). Хотя возможно, тормозила только какая-то одна из функций. Поэтому из всей библиотеки FastCode пользуюсь только FastMove.

← →
Sapersky (2007-09-18 18:43) [45]

Я, честно говоря, тоже не использую. В основном из-за того, что FastCode не оптимизируется под мой заслуженный краснознамённый P3 :) (на нём стандартные функции часто быстрее).
Ещё варианты, почему может тормозить:
1) Непроизвольное смешивание MMX и floating-point кода (в FastCode используется и то, и другое). Если за командой EMMS, заканчивающей MMX-код, следует FP, получается задержка в сколько-то там десятков тактов. Хотя, возможно, на современных CPU это несущественно.
2) MMX/SSE вообще-то требуют выравнивания данных, не помню, как в FastCode решена это проблема. По идее, универсальные функции должны сами как-то изощряться, а может, оставлено на программиста.

← →
Sapersky (2007-09-18 18:58) [46]

... а Владимиру советую, чтобы он не тратил время на изобретение лишних велосипедов.

← →
GMax (2007-09-19 00:09) [47]

>> (Интересно почему нет быстрого FillChar, или считается что быстрее уже точно некуда).

как это нету ? есть.

>как это нету ? есть.

Пусть лучше, а так и будет, производители микропроцессоров затачивают камни под ASM - REP.

Если бы я не тратил время на изобретение велосипедов, KOL"а бы не было.

← →
Sapersky (2007-09-19 18:10) [50]

Я имею в виду, что ознакомившись с трудами предшественников, можно избежать создания моделей имеющих 2-3%-ное "преимущество".
FillChar там, кстати, тоже есть.
Впрочем, как хотите :)

Предложение отказаться от ASM версии Найти похожие ветки