Тут есть некий концептуальный момент. Проблема не столько в конкретных фейлах, сколько в самой новой политике партии трансформации винды в сервис. Скан всех винтов, так, что даже DWS это останавливает только временно, обязательный онлайн логин в вижалстудии (когда и без него все работает), микротранзакции в косынке, удаленное управление активацией, желание все перевести на UWP (где win32 резаный и нет даже GetThreadTimes) и прочая залочка — это все только начало. Собственно курс озвучен официально. А в такой парадигме фейлы неизбежно будут резать «по живому», не трогай пока работает и при обновлении проверяй самостоятельно тут не получится. Какая парадигма для кого лучше уже каждый решает сам.
Не минусовал, но я застал то время, когда N9 раскупались как горячие пирожки. Там в мессенджере было десятки протоколов из коробки, включая наши, и он был очень удобный. Система выглядела прорывно на тот момент. JOLLA, которая была призвана его заменить — на самом деле куцое подобие. Тех же протоколов там до сих пор единицы. Так что вполне предположу что да — вполне были шансы. Я именно нокию хотел брать на тот момент. И это был такой облом что MeeGo прикрыли.
А я таки нашел мелким текстом вариант зарегаться без карты, но через некоторое время мне этот аккаунт заблокировали без объяснения причин. Видимо предполагается что я пойду восстанавливать через саппорт и они таки получат карту =)
Тут недавно статистика убунты вышла www.ubuntu.com/desktop/statistics
Я тоже удивился, но по карте там получается что Россия — один из основных пользователей этого дистрибутива.
Ну да :) Не замечал, чтобы были проблемы с портируемостью. Да и куда деваться, выигрыш был слишком существенен чтобы игнорировать, а вызов асм функции сбивает оптимизирующий компилятор еще больше + он не может переделать ей ABI, перемапить регистры итд. Так что хорошо еще что не на асме =)
Я пробовал rust еще, но на нем так же не получается догнать асм + у него пока нет alloca и другие проблемы.
Я как раз бился над вычисляемым goto в си, для того чтобы прыгнуть в нужное место раскрученного цикла и сравниться с ручным асмом. Оказалось это можно, примерно вот так:
int p = (n/8) & 7;
switch(p)
{
case 0: do { do_some_part_job;
case 7: do_some_part_job;
case 6: do_some_part_job;
case 5: do_some_part_job;
case 4: do_some_part_job;
case 3: do_some_part_job;
case 2: do_some_part_job;
case 1: do_some_part_job;
} while(--n > 0);
break;
}
Но от компилятора сильно зависит, нужны нестандартные расширения или нет. MSVC, например, нужно было default: __assume(0);, чтобы он понял что остальные варианты switch недоступны и range проверка не нужна.
Да, изначально именно его и использовал, привлекает то что у него есть JIT. Но у него нашлись баги, mob бранч сломан, там фактически нет того, кто принимает и проверяет патчи. Я даже находил коммит который сломал, но починить самостоятельно за обозримое время не смог, код уже довольно запутанный. Есть еще про проблемы — он не виртуализирует #include, мне пришлось переделывать/вырезать всю работу с FILE и код разошелся с апстримом. Кроме того опять же нет возможности сделать JIT готового откомпилированного байт-кода (или просто его исполнить, для платформ где JIT не поддерживается).
Да, код хороший. С ним больше проблема что он далеко не полный стандарт си понимает, потому и хотел посмотреть что еще есть. Да и не нужен строковый парсер в самом плеере, вм достаточно.
Спасибо, выглядит как именно то что надо. И вм простая, можно отдельно реализовать самостоятельно. У меня оказывается звезда на этот проект уже стояла, видимо отложил на посмотреть потом :)
Уже использую picoc как просто интерпретатор. Проблема в том, что если встроить его, скажем, в плеер некого формата, то развитие и фиксы багов приведут к несовместимости версий плееров. Отладить 1 раз байткод-интерпретатор, встраивать в формат именно байт-код, а потом спокойно доводить компилятор видится проще.
А не знаете случаем легковесного компилятора си в байткод с интерпретатором. Именно легковесного, чтобы интерпретатор влез на микроконтроллер (компилятор не обязательно).
В nginx тоже своя легкая вм для реврайтов. Насколько я понял, здесь требуется высокая скорость создания контекста и низкое потребление памяти вкупе с приемлемой производительностью. Разве LLVM/GraalVM здесь подойдет?
Давно уже пользуюсь github.com/nothings/stb
Интересно было бы сравнить и его. Так же кроме ImageMagiсk есть еще GraphicsMagick, чья цель как раз была оптимизация — его тоже стоит проверить.
Для меня Unity давно стал показателем некачественной игры. Конечно есть пара хороших (например Pillars Of Eternity), но в основном — качество не очень. И даже у хороших проектов, которые переходили на Unity наблюдаю регресс. Например Shadows: Heretic Kingdoms был на модифицированном Ogre (Ogre Карл) и был вполне неплох, а новый Shadows Awakening — перешли на Unity и поглядите на этих эпилептических мышей. Life Is Strange 2 — резко повысились требования на ровном месте. Проблемы с загрузкой — компилится очень много шейдеров, если у драйвера нет кэша — то это надолго. В общем, складывается впечатление, что хорошие проекты на Unity — не благодаря, а вопреки (и ниже качеством чем было, если с чего-то перешли).
Есть еще всякие мелочи — заставляют ставить в систему MediaFeaturePack, чтобы декодировать h264. Серьезно? А в движок встроить декодер никак? Да тот же ffmpeg поддерживает и аппаратное ускорение.
Я тоже удивился, но по карте там получается что Россия — один из основных пользователей этого дистрибутива.
Вроде близкое к тому что вам надо на нем делают.
github.com/r-lyeh-archived/scriptorium
Я пробовал rust еще, но на нем так же не получается догнать асм + у него пока нет alloca и другие проблемы.
Но от компилятора сильно зависит, нужны нестандартные расширения или нет. MSVC, например, нужно было default: __assume(0);, чтобы он понял что остальные варианты switch недоступны и range проверка не нужна.
Интересно было бы сравнить и его. Так же кроме ImageMagiсk есть еще GraphicsMagick, чья цель как раз была оптимизация — его тоже стоит проверить.
Есть еще всякие мелочи — заставляют ставить в систему MediaFeaturePack, чтобы декодировать h264. Серьезно? А в движок встроить декодер никак? Да тот же ffmpeg поддерживает и аппаратное ускорение.