Хм. Интересно почему SDCC умудряется уступать древнющему HiTech C? Или просто проигрывает по плотности, выигрывает по производительности? Я что то сильно сомневаюсь, что в HiTech C делали какие то оптимизации, там наверняка компилятор простой как пробка. На оптимизацию не хватит ни ресурсов процессора, ни памяти. А SDCC то по ресурсам практически никак не ограничен, соответственно оптимизации ограничены только крутостью разработчиков.
с этим и проблема.Сообщение от msm
по крайней мере пока что была
Лучше сделать и жалеть, чем не сделать и жалеть.
Некоторые из моих поделок тут: https://github.com/serge-404
потому что эти авторы HiTech C писали программы под весьма хилые машинки и надо было соблюдать баланс скорость/качество и следить за размером. HiTech C, как говорят, написан на С
SDCC написан на очень мощном компе, людьми которые не привыкли экономить. вот и весь сказ.
С уважением,
Jerri / Red Triangle.
Следить за размерами чего? Авторам HitTech C нужно было следить за размерами в первыю очередь компилятора. А когда приходится следить за размерами, там не до оптимизаций, там тупо делать просто как пробка и все. А когда компилятор работает на мощной машине, можно там хоть террабайт ресурсов выделить, но кодогенерацию при этом сделать вообще идеальной.
Да можно конечно, кто спорит. Осталась мелочь сущая - выделить да сделать.
А пока приходится пользоваться компилером 30-летней давности, который с включенным режимом оптимизации код дает - я на ассемблере разве что так же напишу.
Лучше сделать и жалеть, чем не сделать и жалеть.
Некоторые из моих поделок тут: https://github.com/serge-404
ты можешь выделять что угодно и куда угодно
но против факта не попрешь:
HiTech C дает более качественный и компактный код чем SDCC
С уважением,
Jerri / Red Triangle.
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
s_kosorev, спектр разброса наших тем общения маленько выходит за мои возможности. То же самое скажу и Vitamin'у, хотя он будет как всегда недоволен, и скажет, что я съезжаю. Если не видите разницы между .NET и подходом со slim binaries - пусть будет так, вам виднее.
А вообще давайте не ругаться, давайте лучше библиотеки делать.Можно сразу под главные сишные компилеры.
P.S. Если болдердаш всё-таки доживёт до релиза - я обязательно соберу его как минимум тремя компилерами - Hitech C, IAR C и z88dk, только мне понадобятся консультации знатоков тонкостей этих компилеров.
подход может быть какой угодно, смысл в том что практической разницы нет, даже в случае прекомпиляции инсталером, слимы проигрывают
Почему же?
Я вижу дотнет. Это балда, которая очень тормозит при инсталляции, сильно тормозит при загрузке и жрёт дочёрта памяти. Кодогенерирующий загрузчик для слим бинариз - это часть ОС, которая при загрузке плоского кодового файла с диска (самая медленная часть работы) будет его компилировать в машинный код процессора (гораздо быстрее, чем загружать по сети или читать с диска), где он будет занимать ровно столько кода, сколько и натив. Вот и вся разница.
---------- Post added at 22:57 ---------- Previous post was at 22:55 ----------
Да, эта балда по имени дотнет ещё и несовместима сама с собой ни сверху вниз, ни снизу вверх, и если у вас две проги в памяти требуют разных версий дотнета - будьте уверены, что одновременно загруженные две версии рантайма жрут ещё больше памяти.
это ты не понимаешь просто принцип работы памяти дотнета, кушает он память пропорционально твоей физической памяти и свободной, к тому же он не кушает а резервирует, при малейшем толчке от операционки он её освобождает, про запас память резервирует что бы максимально быстро сборщик мусора работал
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
