AFAIK, стандарт описывает интерфейс, но не описывает имплементацию. Соответственно в gcc libc++, clang libc++ и msvc libc++, например, могут быть совершенно разные по скорости движки для регулярных выражений. То же самое касается и других алгоритмов, например алгоритмов сортировки. Для них, стандарт, вроде бы описывает только ограничение по O большому и все.
Еще я помню как пытался поставить 6-значный PIN на карточку. Стандарт это позволяет как бы. И софт в в пин-паде это определенно поддерживал. А вот софт в самом банкомате - к сожалению нет. Поэтому мне банкомат напечатал сообщение об ошибке через принтер. Но по ходу где-то налажал с длинной текста или терминирующим символом, потому что после сообщения об ошибке мне принтер напечатал еще два метра бумаги с кусками содержимого памяти. При чем там можно было найти интересные штуки типа выписки предыдущего клиента с остатком на его счету.
Когда я описал эту проблему техподдержке они мне ответили "ну не надо пробовать ставить такой длинный PIN, позязя".
Самое ужасное что числодробилка из C++ - такая себе. Мешают штуки типа pointer aliasing, динамическая аллокация памяти и т.д. Я видел вырожденные примеры, где даже Java обгоняла C++.
Ну в вашем примере вы упомянули конструктор. Значит проверки будут происходить в рантайме. А значить даже в каком-нибудь пайтоне можно описать класс BoundedNumber который точно так же будет проверять в конструкторе что там ему пришло на вход.
А хотелось бы перенести проверки на этап компиляции. Правда, это возможно только на всяких экзотических языках типа Coq, где компиляция программы будет эквивалентна доказательству теоремы "Значения типов bounded_value никогда ни при каких обстоятельствах не выйдут за указанные пределы"
На ноутбуке у меня похоже несколько хостов PCIe. На части портов показывает:
Скорее несколько мостов PCIe. Можете использовать `lspci -t`. Несколько PCI Host Bridge тоже бывает, но на х86 мне такое не встречалось.
Я правильно понимаю, что 8GT/s это PCIe Gen 3, а 16GT/s это Gen 4 ?
Типа того. AFAIK, Gen3/Gen4 - это чисто маркетинговые обозначения, спецификация ими не оперирует, соответственно lspci тоже не умеет показывать эти обозначения.
На некоторых портах показывает "возможность" Margining, но флажок MargReady везде с минусом:
А это как раз в этом посте и описано, почитайте. Как минимум в одном случае вам нужна поддержка этой фичи драйвером устройства.
Ну в любом случае это следует прояснить с разработчиками. Если бага в документации - пусть исправят документацию, если бага в докер-файле - пусть исправят докер-файл.
Но вообще, включение JIT не должно приводить к просадкам. Тем более к ТАКИМ просадкам. Как по мне - это бага где-то глубже. А наличие postgresql-llvmjit просто провоцирует её.
И вообще, come on, если ваша компания занимается разработкой тулинга для postgres, то вы явно должно понимать внутренности postgres лучше других и репортить такие штуки разработчикам самого движка.
Листы резать - да, просто. Хоть лобзиком, хоть фрезой. Я вон вообще точил титановый пруток на хоббийном токарном станке.
А вы загрузить алюминиевую болванку в тот ваш фрезер, у которого высота от стола до шпинделя аж 45мм. Вставьте фрезу в шпиндель и вдруг окажется что вы даже не можете профрезеровать эту болванку, ибо высоты по Z не хватит. Потому что надо чтобы Z travel был хотя бы высота болванки + длина фрезы + зазор. А фреза нужна такой длины, чтобы она доставала от высоты "уха" до дна.
Дальше, у детали из статьи есть отверстия в "ушах". Скажите на милость, каким инструментом вы их будете фрезеровать? Вам надо либо деталь переставлять набок (и тогда она она точно не влезет в этот станок) либо городить четвертую ось (точно не на этом станке).
Короче, это так кажется что ЧПУ резание это как 3д-печать - нарисовал модельку, загрузил в слайсер, нажал на кнопку и оно само все сделало. Вот только нет. Для ЧПУ даже слайсеров нет, есть CAM, где надо вручную описывать каждую операцию и собственным мозгом следить чтобы инструмент не влетел в заготовку.
Требования к жесткости совсем другие, опять же... Длины фрезы "от бормашины" тупо не хватит чтобы обойти всю деталь. Надо использовать нормальные фрезы, а они длинные и создают большой рычаг на тот хлипенький портал станка. Вы не смотрите что там два "толстых вала", а уприте часовой индикатор в шпиндель и надавите пальцем на фрезу - будете очень удивлены.
Проблема решена. Но чтобы она не повторялась, рекомендуем запускать PostgreSQL в Docker с выключенным по умолчанию JIT.
Проблема не решена, к сожалению. Такое поведение PostgreSQL должно расцениваться как ошибка. И я очень удивлен что оно попало в релиз. Надо докопаться до реальной сути проблемы. Вы не пробовали написать в mailing list на эту тему? Если это реальная бага в postgres, то её надо хотя-бы зарепортить. Либо это какая-то ваша мисконфигурация в базе/системе/где-то еще и тогда ее нужно найти и устранить.
Хорошо что в английском есть два слова: router and milling machine. У нас и то и другое называют "фрезером", но проблема в том, что один - для древесины и мягких материалов, а второй - для металлов.
То что вы показали, которое на жиденьких цилиндрических направляющих, алюминий может разве что облизывать. Там даже на всех промофотках в него зажато либо вспененый пластик для моделирования либо кусок фанеры. Да, им можно гравировать по алюминию. Но фрезеровать его, да еще и с большим вылетом фрезы... Вам не понравится ни процесс ни результат.
Расход режущего инструмента и всякого другого будет дикий. Среднее время жизни сменной режущей пластины в ЧПУ - один час. Время жизни фрезы - не сильно выше. Зная скорость обработки можно посчитать сколько кубических метров или кг металла она сможет удалить. И это не то чтобы очень большое число. Плюс, сделать полую мачту как в статье - не выйдет. Ибо сверлить на такую глубину.... Банально нечем. А кроме инструмента еще надо менять СОЖ, менять/ремонтировать изношенные направляющие (нагрузка при резании сильно выше чем при печати), делать профилактику шпинделям и так далее....
Поэтому в массовом производстве всегда используют литье (или экструзию) с последующей доводкой важных поверхностей на металлорежущих станках.
AFAIK, стандарт описывает интерфейс, но не описывает имплементацию. Соответственно в gcc libc++, clang libc++ и msvc libc++, например, могут быть совершенно разные по скорости движки для регулярных выражений. То же самое касается и других алгоритмов, например алгоритмов сортировки. Для них, стандарт, вроде бы описывает только ограничение по O большому и все.
Да если бы :)
Еще я помню как пытался поставить 6-значный PIN на карточку. Стандарт это позволяет как бы. И софт в в пин-паде это определенно поддерживал. А вот софт в самом банкомате - к сожалению нет. Поэтому мне банкомат напечатал сообщение об ошибке через принтер. Но по ходу где-то налажал с длинной текста или терминирующим символом, потому что после сообщения об ошибке мне принтер напечатал еще два метра бумаги с кусками содержимого памяти. При чем там можно было найти интересные штуки типа выписки предыдущего клиента с остатком на его счету.
Когда я описал эту проблему техподдержке они мне ответили "ну не надо пробовать ставить такой длинный PIN, позязя".
Ну я думаю что кросс-компиляция даже в те времена существовала. Так что первый софт скорее всего готовили на машине другой архитектуры.
Чем старее и "круче" банк тем тупее у него требования к паролям. Когда-то у CBS, кажется, требование к "паролю" было - ровно 6 цифр.
Самое ужасное что числодробилка из C++ - такая себе. Мешают штуки типа pointer aliasing, динамическая аллокация памяти и т.д. Я видел вырожденные примеры, где даже Java обгоняла C++.
Ну в вашем примере вы упомянули конструктор. Значит проверки будут происходить в рантайме. А значить даже в каком-нибудь пайтоне можно описать класс
BoundedNumberкоторый точно так же будет проверять в конструкторе что там ему пришло на вход.А хотелось бы перенести проверки на этап компиляции. Правда, это возможно только на всяких экзотических языках типа Coq, где компиляция программы будет эквивалентна доказательству теоремы "Значения типов bounded_value никогда ни при каких обстоятельствах не выйдут за указанные пределы"
А еще в Германии права, свободы, автобаны и самая мощная экономика ЕС.
Самое смешное начинается после родов: "Ну а что вы хотите, это все из-за беременности..."
Ну автор вон целый пост настрочил, не разобравшись.
Скорее несколько мостов PCIe. Можете использовать `lspci -t`. Несколько PCI Host Bridge тоже бывает, но на х86 мне такое не встречалось.
Типа того. AFAIK, Gen3/Gen4 - это чисто маркетинговые обозначения, спецификация ими не оперирует, соответственно lspci тоже не умеет показывать эти обозначения.
А это как раз в этом посте и описано, почитайте. Как минимум в одном случае вам нужна поддержка этой фичи драйвером устройства.
PCI Express Base Specification. Раздел 7. Software Initialization and Configuration. Там где-то с секции 7.6 начинается описание capabilities
А у вас там там вообще много PCIe устройств? Все что сидит в PCH видится как просто PCI, например.
lspciпоказывает. Надо только запускать как-то так: `sudo lspci -vvv`, ищите строчкуLnkCapНу если запускать с
-vvvто вот например:Внимание на
LnkSta2То что 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кг.