На мой взгляд, потеть должна машина, а человек учиться, не выворачивая мозги наизнанку.
Мне всегда казалось, что любое обучение это всегда тяжело. Как говорил препод по матану в университете: "Вы думаете мне дается легко то что я вам преподаю? Я на это потратил 30 лет жизни и не все они были прекрасны, но мне нравится это делать, нравится преодолевать собственное непонимание."
Ну уж в пух и прах. Указал на две явные проблемы, про которые вроде как все и так знают и пытаются исправить. Похоже вы не застали те времена, когда Торвальдс мог такие трехэтажные перлы выдавать, что зачитаешься.
В целом судя по LKLM Rust в ядре однозначно быть ибо в этом заинтересованы почти все, кто должны, а кто не особо заинтересован (как Торвальдс) категорично не отрицают возможность.
Хм. А как же этическая сторона вопроса, особенно в пандемию? Я готов платить музыканту за его труд. И т.к. концерты сейчас не доступны, то покупая его альбомы или пользуясь стримингом я ему деньгу засылаю.
Да, конечно, посредников тут жуть сколько, но хоть и как-то.
Есть ли вообще смысл использовать ядро, если мы говорим о высокой производительности? Или надо уходить в bypass. Вот например хороший текст об этом от cloudflare https://blog.cloudflare.com/kernel-bypass/
Боюсь что 99% внедренцев CRM на деле в этом ничего не понимают. У меня тоже с этими гражданами сугубо негативный опыт. Это проблема современного IT: чудовищно низкий уровень персонала.
Сложный это вопрос. Если проще, то сейчас нет возможности сделать геокластер прямыми средствами. Единственно разумное решение это Dual ETL или что-то похожее на Dual ETL, когда после окончания записи осуществляет перенос данных на другой кластер через gpbackup/gprestore.
Но это если говорить про 6ю версию. В семерке планируются улучшения в этом плане, но это будет анонсировано позже.
— Я запустил оригинальный Doom в DosBox, который запущен на Linux, который запущен в VirtualBox, который работает под Windows. Кому жаловаться на неработающий звук?
— Санитарам.
Поддерживаю. Сам по себе вим устарел технически и не дотягивает до современных ide во многих аспектах, хотя проекты типа neovim пытаются это исправить.
Но в каждой ide есть вим мод. И наверное он там не зря.
Очень странно. Под Винду программируете? Из моего опыта разработки под никсы, на компанию в 50 человек всегда находится 1-2 вимера. Лично я к этому так давно привык, что не воспринимаю ту же idea без vim плагина.
Я как-то из-за необходимости произвольного доступа к файлам в архиве мастерил поделку, которая сохраняла отдельные файлы в виде gz архива в tar, а потом ещё и индекс смещений строил по этому tar, чтоб не надо было ревинд делать. Это было на удивление легко, хоть и весьма любопытно.
Ну все же здесь в первую очередь речь не о tar и его методах сортировок, а о алгоритме XZ. Довольно очевидно, что предварительно сортированные посодержимому данные удобнее для сжатия любым алгоритмом, т.к. он в целом основан на поиске одинаковых частей во входящем потоке и при небольшом буфере и работе в один проход получаем то, что получаем.
То, что сортировка по содержимому и сортировка по дате в данном случае совпадает это частный случай, хотя и любопытный.
Кстати, кто-нибудь шарит в этих алгоритмах? Есть ли не поточные, а много проходные архиваторы? Или хотя бы архиваторы двух стадийные: на первом проходе составляем карту повторений, на втором уже архивируем с учетом статистики.
Пример с Фибоначи очень узок. Редко кому надо проводить рекурсивные математические операции. Для этого есть разнообразные чилодробительные библиотеки, которые работают ещё быстрее.
А если мы перейдем от чисел к строкам или структурам, то потери на работу с этими объектами в памяти изменят ситуацию, и скорость уже не будет в тысячу раз быстрее.
В реальной жизни рекурсию используют для банального обхода дерева или других ациклических структур. И хотя тут тоже можно использовать замыкание, но читабельность может упасть критически.
Вы так говорите, как буд-то TSMC или Samsung против выпускать что-нибудь для Intel. Они были бы рады, но как только Интел перейдет на сторонние линии, это будет удар по имиджу лидера и по капитализации. Поэтому пока они не готовы.
Ну и не свежая мысль, высказанная разными людьми много раз: рано закапываете Intel, они уже были в подобной ситуации с P4, а потом выпустили Core и начали доминацию длинной в 10 лет. Ресурсы для самовыкапывания у них большие.
Мне всегда казалось, что любое обучение это всегда тяжело. Как говорил препод по матану в университете: "Вы думаете мне дается легко то что я вам преподаю? Я на это потратил 30 лет жизни и не все они были прекрасны, но мне нравится это делать, нравится преодолевать собственное непонимание."
Ну уж в пух и прах. Указал на две явные проблемы, про которые вроде как все и так знают и пытаются исправить. Похоже вы не застали те времена, когда Торвальдс мог такие трехэтажные перлы выдавать, что зачитаешься.
В целом судя по LKLM Rust в ядре однозначно быть ибо в этом заинтересованы почти все, кто должны, а кто не особо заинтересован (как Торвальдс) категорично не отрицают возможность.
Хм. А как же этическая сторона вопроса, особенно в пандемию? Я готов платить музыканту за его труд. И т.к. концерты сейчас не доступны, то покупая его альбомы или пользуясь стримингом я ему деньгу засылаю.
Да, конечно, посредников тут жуть сколько, но хоть и как-то.
Так есть же уже вроде готовые библиотеки, в которых все это сделано. Понятно, что они заточены под конкретные карточки, но они есть.
Есть ли вообще смысл использовать ядро, если мы говорим о высокой производительности? Или надо уходить в bypass. Вот например хороший текст об этом от cloudflare https://blog.cloudflare.com/kernel-bypass/
Все же раз существует так мало известных программ с UI на Java, значит есть какие-то более важные причины, нежели недостатки JavaFX
Этому оригиналу столько, что хорошо, что я хоть что-то помню
Боюсь что 99% внедренцев CRM на деле в этом ничего не понимают. У меня тоже с этими гражданами сугубо негативный опыт. Это проблема современного IT: чудовищно низкий уровень персонала.
Сложный это вопрос. Если проще, то сейчас нет возможности сделать геокластер прямыми средствами. Единственно разумное решение это Dual ETL или что-то похожее на Dual ETL, когда после окончания записи осуществляет перенос данных на другой кластер через gpbackup/gprestore.
Но это если говорить про 6ю версию. В семерке планируются улучшения в этом плане, но это будет анонсировано позже.
Поддерживаю. Сам по себе вим устарел технически и не дотягивает до современных ide во многих аспектах, хотя проекты типа neovim пытаются это исправить.
Но в каждой ide есть вим мод. И наверное он там не зря.
Если вы не знаете про пупырышки, то похоже и в слепую не печатаете. Это так? Если да, то тогда вим вообще вам не подходит.
Очень странно. Под Винду программируете? Из моего опыта разработки под никсы, на компанию в 50 человек всегда находится 1-2 вимера. Лично я к этому так давно привык, что не воспринимаю ту же idea без vim плагина.
Я как-то из-за необходимости произвольного доступа к файлам в архиве мастерил поделку, которая сохраняла отдельные файлы в виде gz архива в tar, а потом ещё и индекс смещений строил по этому tar, чтоб не надо было ревинд делать. Это было на удивление легко, хоть и весьма любопытно.
Если они работают в один проход, то они очевидно попадут в ту же историю.
Ну все же здесь в первую очередь речь не о tar и его методах сортировок, а о алгоритме XZ. Довольно очевидно, что предварительно сортированные по содержимому данные удобнее для сжатия любым алгоритмом, т.к. он в целом основан на поиске одинаковых частей во входящем потоке и при небольшом буфере и работе в один проход получаем то, что получаем.
То, что сортировка по содержимому и сортировка по дате в данном случае совпадает это частный случай, хотя и любопытный.
Кстати, кто-нибудь шарит в этих алгоритмах? Есть ли не поточные, а много проходные архиваторы? Или хотя бы архиваторы двух стадийные: на первом проходе составляем карту повторений, на втором уже архивируем с учетом статистики.
Если покупаешь Lenovo, даже без Windows, то все равно платишь MS и в целом это действительно странно. Об этом в статье собственно сказано.
Думаю это на столько зависит от приложения и бизнеса, что даже обсуждать здесь бессмысленно.
Пример с Фибоначи очень узок. Редко кому надо проводить рекурсивные математические операции. Для этого есть разнообразные чилодробительные библиотеки, которые работают ещё быстрее.
А если мы перейдем от чисел к строкам или структурам, то потери на работу с этими объектами в памяти изменят ситуацию, и скорость уже не будет в тысячу раз быстрее.
В реальной жизни рекурсию используют для банального обхода дерева или других ациклических структур. И хотя тут тоже можно использовать замыкание, но читабельность может упасть критически.
Вы так говорите, как буд-то TSMC или Samsung против выпускать что-нибудь для Intel. Они были бы рады, но как только Интел перейдет на сторонние линии, это будет удар по имиджу лидера и по капитализации. Поэтому пока они не готовы.
Ну и не свежая мысль, высказанная разными людьми много раз: рано закапываете Intel, они уже были в подобной ситуации с P4, а потом выпустили Core и начали доминацию длинной в 10 лет. Ресурсы для самовыкапывания у них большие.