Ну тут довольно много писать просто придется. Попробую которко. Во первых указателями на ноды оперировать слишком жирно, особенно в x64. В классисеском оптимизированном варианте там либо 2 таблицы lson\rson заводят, либо вообще одну state, где кодируют признак листа и смещения. Второй основно хак — это входные биты слать от старшего в байте\инте или 64бит регистре, и ипользовать что то типа add eax, eax для вытеснения бита в carry и использовать инструкцию adc без бранчей. Потом к текущему стейту прибавляем этот adc (обычно умноженный на 2\4), делаем запрос в таблицу state по вычисленному смещению, выясняем лист ли это, если да — то output byte, если нет то циклимся. Все, внутренний цикл очень короткий. Надо оптимизировать си код, пока инннер луп не будет выглядеть близким к тому что надо, это можно сделать, я проделовал чтобы было хорошо под всеми мажорными компиляторами.
У вас в С++ даже ассерты не ушли, надо -DNDEBUG добавить чтобы они исчезли. Код ужасно оптимизирован. Кстати в clang, rust использует то же AST дерево, так что добиться на С++ той же оптимизации обычно можно, я другого не встречал. А вот в обратную, как я ни старался, у меня не получалось в низкоуровневом коде. Там есть проблемы, например пока отсутствует alloca.
Спасибо за перевод. А нету ли в современном железе аналога CSAA, только чтобы вместо кучи сэмплов рассчитывало одно единственное число перекрытости пикселя треугольником? Для векторной графики это было бы идеально, глубина тут не нужна.
Та же самая 5.1.6.2 из Ubuntu 16.04. Копирую из Far Manager, при этом оно показывает экран с превью как вставится, можно порулить параметрами если что не так.
Только что попробовал — нормально все вставилось во Writer, я просто даблкликнул на таблицу и там уже нажал ctrl-v, данные нормально обновились. Ntfs тоже чинится ntfsfix из ntfs-3g (хотя я повреждений не наблюдал при вытаскивании никогда, оно там специально не кэшируется при записи и если копирование завершено испортиться ничего не должно).
Это верно, возможно мои проблемы были слишком сложные (+у вас все же через интегратора), уж точно не выдать новые ключи. Для решения одной мне даже пришлось самому патчить ядро win2000. Однако поддержка все равно оставила негативное впечатление, на специалиста который мог что-то сделать или хотя-бы внутренний баг завести дело так и не попало, в отличии от некоторых конкурентов.
Их и было немало, я обращался в техподдержку МС около 10 раз. Реальной помощи не было от слова совсем. При этом помочь реально можно было, справились своими силами, за исключением может случая пропажи аутлук аккаунта — это может было невозможно решить, просто фатальный сбой облака. Когда читал статью выше я аж успокоился, оказывается не только у меня так.
По моему опыту — крутость тех-поддержки мс это такой миф. На хабре даже статьи про это есть, мой личный опыт отлично выражает эта статья https://habrahabr.ru/post/316912/.
Ну теоретически и MJPEG можно по 802.11g передать в приемлимом качестве, а RFX качественее MJPEG. Дьявол кроется в деталях — надо измерять и сравнивать. Кстати не факт что у вас H264 не включался, алгоритм выбора виндового сервера не известен. Чтобы быть уверенным надо собрать клиент с чем-то типа libfreerdp и прологировать что там приходит, в самом портоколе может быть все вот это github.com/neutrinolabs/xrdp/blob/devel/xrdp/xrdp_mm.c#L65. Так же WMP, например, умеет делать отдельный канал для видео, хотя в игре поддержка врядли есть.
Если честно — не знаю как выяснили, но этот кодек совместим, может декодировать то что приходит с виндового RDP и наоборот. Благодаря нему Remmina может коннектиться к винде, а на xrdp/freerdp можно заходить с винды. RemoteFX очень даже хороший в сценарии работы в ворде, почих статичных приложений, бравзере без сильной анимации. А вот для игр и видео в плеере — h264 лучше.
Так же есть очень простой софт для переброски игр, такие как Single Player Game Transmitter — в них очень просто поменять кодек. Я менял на h265/nvidia, так еще лучше.
Все же дкмаю это GPU кодер такой эффективный по сравнению с прошлым. По названию ничего не выдает в нем HEVC, h264 вполне поддерживает 4:4:4 en.wikipedia.org/wiki/H.264/MPEG-4_AVC
Support of monochrome (4:0:0), 4:2:0, 4:2:2, and 4:4:4 chroma subsampling (depending on the selected profile).
И все современные h264 кодеры это умеют. Еслиб там был h265, думаю они бы не примянули это упомянуть. Думаю дело в поддержке железа, h265 поддержтивают далеко не все. И те что поддерживают иногда есть проблемы, вот например проблема на интеле: habrahabr.ru/company/intel/blog/311320/#comment_9839892.
Только где новый кодек? По названию это все тот же h264, только в режиме yuv 4:4:4. Он должен быть четче, ценой небольшого доп. битрейта. А вот задержка из-за битрейта наоборот может чуть возрасти. Вот снизиться задержка может другими параметрами, например отключенными B кадрами. По качеству весь вопрос только какую реализацию кодека использовать и какие настройки. Очень сомневаюсь, что на nvidia картах можно переплюнуть хардварный nvidia кодек, скорее всего он и используется, как и в куче другого софта.
PS: А RemoteFX, кстати, это фактически JPEG2000, вот его исходники github.com/neutrinolabs/librfxcodec. А когда он появился, помню было несколько страниц маркетинговой воды какой он хороший, но что внутри jpeg умалчивалось. Вот сейчас у меня стойкое ощущение того же самого, когда от 4:4:4 якобы опять все стало значительно лучше. Все-таки, задержка и меньший битрейт это точно не от 4:4:4.
Да вобщем-то в мажорных дистрибутивах типа ubuntu и opensuse вручную править fstab не нужно, можно прямо в GUI и прямо во время инсталяции перенести и /usr и /home как хочешь.
Добавлю, что сейчас софт на Linux вовсе не обязателньо ставится именно в систему, есть специальные форматы однофайловых приложений, которые можно скопировать куда угодно: snap, flatpak, appimage. Так же есть дистрибутивы, которые группируют приложения по отдельным папкам, а не размазывают, например GoboLinux.
Нет, те что быстрее это из «еще несколько проприетарных». Я не помню уже какие именно пробовал, но что то типа таких undo.io/products/undodb, если поискать можно еше несколько аналогичных найти. Вот из них на то время точно были быстрее стокового gdb. Сейчас уже обычно rr хватает, с ним никаких проблем по скорости.
Тоже хотел про rr написать, классная штука. Кроме этого есть CLion и еще несколько проприетарных отладчиков с этой функцией (они быстрее gdb). В свое время на винде мне этого не хватало, и вот наконец появилось.
У меня учетка outlook.com, которую я завел для Xbox, однажды просто внезапно исчезла. Пароль вводил довольно длинный и только на Xbox. Новая учетка пока живет, но осадочек остался.
Сходу совсем хороших примеров не найду, но нашел вот это www.virtualdub.org/blog/pivot/entry.php?id=205 специфический кейс для yuv.
Так же есть очень простой софт для переброски игр, такие как Single Player Game Transmitter — в них очень просто поменять кодек. Я менял на h265/nvidia, так еще лучше.
И все современные h264 кодеры это умеют. Еслиб там был h265, думаю они бы не примянули это упомянуть. Думаю дело в поддержке железа, h265 поддержтивают далеко не все. И те что поддерживают иногда есть проблемы, вот например проблема на интеле: habrahabr.ru/company/intel/blog/311320/#comment_9839892.
PS: А RemoteFX, кстати, это фактически JPEG2000, вот его исходники github.com/neutrinolabs/librfxcodec. А когда он появился, помню было несколько страниц маркетинговой воды какой он хороший, но что внутри jpeg умалчивалось. Вот сейчас у меня стойкое ощущение того же самого, когда от 4:4:4 якобы опять все стало значительно лучше. Все-таки, задержка и меньший битрейт это точно не от 4:4:4.