Ну в любом случае это следует прояснить с разработчиками. Если бага в документации - пусть исправят документацию, если бага в докер-файле - пусть исправят докер-файл.
Но вообще, включение JIT не должно приводить к просадкам. Тем более к ТАКИМ просадкам. Как по мне - это бага где-то глубже. А наличие postgresql-llvmjit просто провоцирует её.
И вообще, come on, если ваша компания занимается разработкой тулинга для postgres, то вы явно должно понимать внутренности postgres лучше других и репортить такие штуки разработчикам самого движка.
Листы резать - да, просто. Хоть лобзиком, хоть фрезой. Я вон вообще точил титановый пруток на хоббийном токарном станке.
А вы загрузить алюминиевую болванку в тот ваш фрезер, у которого высота от стола до шпинделя аж 45мм. Вставьте фрезу в шпиндель и вдруг окажется что вы даже не можете профрезеровать эту болванку, ибо высоты по Z не хватит. Потому что надо чтобы Z travel был хотя бы высота болванки + длина фрезы + зазор. А фреза нужна такой длины, чтобы она доставала от высоты "уха" до дна.
Дальше, у детали из статьи есть отверстия в "ушах". Скажите на милость, каким инструментом вы их будете фрезеровать? Вам надо либо деталь переставлять набок (и тогда она она точно не влезет в этот станок) либо городить четвертую ось (точно не на этом станке).
Короче, это так кажется что ЧПУ резание это как 3д-печать - нарисовал модельку, загрузил в слайсер, нажал на кнопку и оно само все сделало. Вот только нет. Для ЧПУ даже слайсеров нет, есть CAM, где надо вручную описывать каждую операцию и собственным мозгом следить чтобы инструмент не влетел в заготовку.
Требования к жесткости совсем другие, опять же... Длины фрезы "от бормашины" тупо не хватит чтобы обойти всю деталь. Надо использовать нормальные фрезы, а они длинные и создают большой рычаг на тот хлипенький портал станка. Вы не смотрите что там два "толстых вала", а уприте часовой индикатор в шпиндель и надавите пальцем на фрезу - будете очень удивлены.
Проблема решена. Но чтобы она не повторялась, рекомендуем запускать PostgreSQL в Docker с выключенным по умолчанию JIT.
Проблема не решена, к сожалению. Такое поведение PostgreSQL должно расцениваться как ошибка. И я очень удивлен что оно попало в релиз. Надо докопаться до реальной сути проблемы. Вы не пробовали написать в mailing list на эту тему? Если это реальная бага в postgres, то её надо хотя-бы зарепортить. Либо это какая-то ваша мисконфигурация в базе/системе/где-то еще и тогда ее нужно найти и устранить.
Хорошо что в английском есть два слова: router and milling machine. У нас и то и другое называют "фрезером", но проблема в том, что один - для древесины и мягких материалов, а второй - для металлов.
То что вы показали, которое на жиденьких цилиндрических направляющих, алюминий может разве что облизывать. Там даже на всех промофотках в него зажато либо вспененый пластик для моделирования либо кусок фанеры. Да, им можно гравировать по алюминию. Но фрезеровать его, да еще и с большим вылетом фрезы... Вам не понравится ни процесс ни результат.
Расход режущего инструмента и всякого другого будет дикий. Среднее время жизни сменной режущей пластины в ЧПУ - один час. Время жизни фрезы - не сильно выше. Зная скорость обработки можно посчитать сколько кубических метров или кг металла она сможет удалить. И это не то чтобы очень большое число. Плюс, сделать полую мачту как в статье - не выйдет. Ибо сверлить на такую глубину.... Банально нечем. А кроме инструмента еще надо менять СОЖ, менять/ремонтировать изношенные направляющие (нагрузка при резании сильно выше чем при печати), делать профилактику шпинделям и так далее....
Поэтому в массовом производстве всегда используют литье (или экструзию) с последующей доводкой важных поверхностей на металлорежущих станках.
Знаете, сколько раз я на код-ревью получал ответ (от инициатора код-ревью) в духе "ну дык этож петон! Какие дженерики??"
Ну дык, автор отправляется читать книжку, PR откладывается пока автор занимается самопросвещением.
Конечно, мне наверное просто говорить, потому что я еще и мейнтейню бОльшую часть проектов где делаю код-ревью. Так что последнее слово в основном остается за мной.
Благо дело, на текущем проекте я как раз ответственное лицо за настройку/прикуручивание всяческих линтеров. Пускай неумехи страдают :))
В обсуждаемой статье речь про МК, и про ядро Linux ни слова. В чем связь?
Цитату про ядро я взял из статьи. Можете сами проверить.
В письме пишется, если я правильно понял, про FP-сопроцессор в x86:
Потому что Линус смотрит на вещи в основном с точки зрения x86. Но это относится и к другим архитектурам, например к ARM. FPU изредка используется для SIMD инструкций (например в коде raid6), но все такие места обложены kernel_fpu_begin для x86 или kernel_neon_begin для ARM.
EDIT: В том коде, который может потенциально компилироваться под ARM нет вообще ни одной double или float переменной. Я вообще не уверен что порт ядра на ARM умеет работать с FP в ядерном контексте.
Если кратко - сохранять FP контекст при переключении в режим ядра - очень дорого. FP контекст переключается только когда переключаются поток в user land. Это происходит куда реже чем прыжки между user mode и kernel mode.
Самый простой язык - это ассемблер. Там не то что объектов, классов и наследования нет, там даже строк (ну кроме древнего x86), структур и массивов нет.
Но без понимания большей картины - Roblox бесполезен.
Как ребенку научиться понимать большую картину? Прочитать учебник "основы понимания больших картин" издательства "минобразование"? Или может пробовать, экспериментировать, учиться на ошибках и т.д.?
Пусть начинает с чего-то простого. Не обязательно знать язык на 100% чтобы делать что-то.
Начинать с простых задач. Типа "я хочу создать кубик и чтобы он крутился на месте". Потом "а теперь пусть он двигается по квадратной траектории". Дальше - больше.
То что PCIe умудряется работать в таких условиях - это настоящее инженерное чудо. Браво авторам спецификации и инженерам которые делали трансиверы.
Revolutionary!
Я думал что крипта - это про децентрализацию, независимость от государства и прочую анархию. Зачем вообще регистрировать "криптобизнес"?
Даже само слово kryptós значит "спрятанный", "сокрытый"
Ну в любом случае это следует прояснить с разработчиками. Если бага в документации - пусть исправят документацию, если бага в докер-файле - пусть исправят докер-файл.
Но вообще, включение JIT не должно приводить к просадкам. Тем более к ТАКИМ просадкам. Как по мне - это бага где-то глубже. А наличие
postgresql-llvmjitпросто провоцирует её.И вообще, come on, если ваша компания занимается разработкой тулинга для postgres, то вы явно должно понимать внутренности postgres лучше других и репортить такие штуки разработчикам самого движка.
Листы резать - да, просто. Хоть лобзиком, хоть фрезой. Я вон вообще точил титановый пруток на хоббийном токарном станке.
А вы загрузить алюминиевую болванку в тот ваш фрезер, у которого высота от стола до шпинделя аж 45мм. Вставьте фрезу в шпиндель и вдруг окажется что вы даже не можете профрезеровать эту болванку, ибо высоты по Z не хватит. Потому что надо чтобы Z travel был хотя бы высота болванки + длина фрезы + зазор. А фреза нужна такой длины, чтобы она доставала от высоты "уха" до дна.
Дальше, у детали из статьи есть отверстия в "ушах". Скажите на милость, каким инструментом вы их будете фрезеровать? Вам надо либо деталь переставлять набок (и тогда она она точно не влезет в этот станок) либо городить четвертую ось (точно не на этом станке).
Короче, это так кажется что ЧПУ резание это как 3д-печать - нарисовал модельку, загрузил в слайсер, нажал на кнопку и оно само все сделало. Вот только нет. Для ЧПУ даже слайсеров нет, есть CAM, где надо вручную описывать каждую операцию и собственным мозгом следить чтобы инструмент не влетел в заготовку.
Требования к жесткости совсем другие, опять же... Длины фрезы "от бормашины" тупо не хватит чтобы обойти всю деталь. Надо использовать нормальные фрезы, а они длинные и создают большой рычаг на тот хлипенький портал станка. Вы не смотрите что там два "толстых вала", а уприте часовой индикатор в шпиндель и надавите пальцем на фрезу - будете очень удивлены.
Проблема не решена, к сожалению. Такое поведение PostgreSQL должно расцениваться как ошибка. И я очень удивлен что оно попало в релиз. Надо докопаться до реальной сути проблемы. Вы не пробовали написать в mailing list на эту тему? Если это реальная бага в postgres, то её надо хотя-бы зарепортить. Либо это какая-то ваша мисконфигурация в базе/системе/где-то еще и тогда ее нужно найти и устранить.
Oh sweet summer child...
Хорошо что в английском есть два слова: router and milling machine. У нас и то и другое называют "фрезером", но проблема в том, что один - для древесины и мягких материалов, а второй - для металлов.
То что вы показали, которое на жиденьких цилиндрических направляющих, алюминий может разве что облизывать. Там даже на всех промофотках в него зажато либо вспененый пластик для моделирования либо кусок фанеры. Да, им можно гравировать по алюминию. Но фрезеровать его, да еще и с большим вылетом фрезы... Вам не понравится ни процесс ни результат.
Расход режущего инструмента и всякого другого будет дикий. Среднее время жизни сменной режущей пластины в ЧПУ - один час. Время жизни фрезы - не сильно выше. Зная скорость обработки можно посчитать сколько кубических метров или кг металла она сможет удалить. И это не то чтобы очень большое число. Плюс, сделать полую мачту как в статье - не выйдет. Ибо сверлить на такую глубину.... Банально нечем. А кроме инструмента еще надо менять СОЖ, менять/ремонтировать изношенные направляющие (нагрузка при резании сильно выше чем при печати), делать профилактику шпинделям и так далее....
Поэтому в массовом производстве всегда используют литье (или экструзию) с последующей доводкой важных поверхностей на металлорежущих станках.
Надо просто считать по весу. Процессор сколько весит - грамм 5? Зато чугунный корпус - все 15кг.
Второй закон термодинамики не позволяет.
Ну дык, автор отправляется читать книжку, PR откладывается пока автор занимается самопросвещением.
Конечно, мне наверное просто говорить, потому что я еще и мейнтейню бОльшую часть проектов где делаю код-ревью. Так что последнее слово в основном остается за мной.
О да, линтеры спасают жизнь.
Такое должно безжалостно зарезаться на code review. А у автора потом спрашивать все ли у него хорошо в жизни....
Так то в C тоже можно кастить все указатели в
(void*)и потом в требуемый тип, а в какой-нибудь Java - вObjectи обратно.Цитату про ядро я взял из статьи. Можете сами проверить.
Потому что Линус смотрит на вещи в основном с точки зрения x86. Но это относится и к другим архитектурам, например к ARM. FPU изредка используется для SIMD инструкций (например в коде raid6), но все такие места обложены
kernel_fpu_beginдля x86 илиkernel_neon_beginдля ARM.EDIT: В том коде, который может потенциально компилироваться под ARM нет вообще ни одной double или float переменной. Я вообще не уверен что порт ядра на ARM умеет работать с FP в ядерном контексте.
Я это пише в применении к
https://yarchive.net/comp/linux/kernel_fp.html
Если кратко - сохранять FP контекст при переключении в режим ядра - очень дорого. FP контекст переключается только когда переключаются поток в user land. Это происходит куда реже чем прыжки между user mode и kernel mode.
... поэтому там никто не будет вычислять арктангенс в double.
Самый простой язык - это ассемблер. Там не то что объектов, классов и наследования нет, там даже строк (ну кроме древнего x86), структур и массивов нет.
Знаете что с вами сделают за попытку использовать floating point в ядре? Хинт: уж точно по головке не погладят.
Да и у многих МК нет аппаратной поддержки FP.
Как ребенку научиться понимать большую картину? Прочитать учебник "основы понимания больших картин" издательства "минобразование"? Или может пробовать, экспериментировать, учиться на ошибках и т.д.?
Пусть начинает с чего-то простого. Не обязательно знать язык на 100% чтобы делать что-то.
Начинать с простых задач. Типа "я хочу создать кубик и чтобы он крутился на месте". Потом "а теперь пусть он двигается по квадратной траектории". Дальше - больше.