Уважаемый автор, а скажите, пожалуйста, что Вы думаете о мнении Caroline Bullock, Technology of Business reporter из BBC, которое изложено в статье «Why is Russia so good at encouraging women into tech?» ( http://www.bbc.com/news/business-39579321 )?
Просто одна цитата цифрами:
> According to Unesco, 29% of people in scientific research worldwide are women, compared with 41% in Russia. In the UK, about 4% of inventors are women, whereas the figure is 15% in Russia.
К сожалению — это из-за того, что вместо нормальной философии Вам преподавали исключительно историю философии и требовали зубрить даты, фамилии и изречения отдельных философов?
Или из-за того, что курс философии в аспирантуре по большей смысловой части состоял из семинаров, где учащимся приходилось готовить доклады, аргументировать свою точку зрения, вступать в дискуссии, рассказывать о своей научной работе аспирантам других специальностей, чтобы они при этом все поняли и т.д.?
Если первый случай, то Вам катастрофически не повезло с преподавателями (к сожалению, это часто встречается), а если второе, то проблема в Вас.
И, к сожалению, нередко наблюдается ситуация, когда второй метод преподавания философии, что у студентов, что у аспирантов вызывает гораздо больше негатива, чем первый, из-за банальной собственной лени (рефератиком из интернетика уже не отделаться — думать надо)…
> =отсутствие на работе 2 месяца в году…
А в чем проблема в отсутствии на работе 2 месяца в году?
Немало должностей по ТК имеют оплачиваемый отпуск по 1,5-2 месяца и ничего, работают компании.
Так это и есть высокая плотность. Больше единиц оборудования в меньшем объеме (В С7000 16 серверов на 10 юнитов) и следовательно, больше энергопотребление в меньшем объеме.
Другое дело, что среднестатистические датацентры рассчитываются на малое энергопотребление, а не на высокую производительность оборудования, отсюда и лимиты в 10кВт на стойку.
Что по охлаждению, то воздухом можно снять 20-25кВт со стойки. Системами на подобие с водяной дверью порядка 40кВт, а водой до 400кВт (рекорд РСК).
Так что если Вы лимитированы питанием и/или охлаждением, то высокоплотные системы просто не для Ваших задач, а если Вам нужна высокая плотность, то Вас уже не заботят стандартные датацентры, а инженерная инфраструктура подгоняется под используемое оборудование.
В итоге в этом случае я дошел до реального break strict-aliasing rules.
Это действительно баг в коде boost::container::flat_map, но который на моем наборе компиляторов стрелял только в gcc 4.3.4.
https://github.com/boostorg/container/blob/develop/include/boost/container/flat_map.hpp#L61-L70
Функция force хотя бы работает, а вот force_copy сильно не всегда. Почему они написаны именно так я не знаю. В рассылке мне ответили только то, что да, это ломает strict-aliasing, но зачем так сделали — осталось без ответа.
Так что минус один баг в компиляторе, +1 баг в Бусте.
Но чтобы не было все так хорошо с компиляторами (и в моем списке осталось ровно 2 бага), вспомню еще один случай на компиляторе из RHEL7.0, когда при включении LTO он просто падал с segmentation fault на некотором коде :)
Вы перепутали право авторства (право на имя) и имущественные права на результаты интеллектуальной деятельности.
Право авторства неотчуждаемы, и в России, и в США. Те никто не может заявить, что это придумал он, а не реальный автор. Неотчуждаемость права авторства, кстати, не требует обязательного сообщения имени автора, по этому имен разработчиков Windows, да и любых продуктов из России Вы не найдете.
А все то, что Вы написали — это про имущественные права (грубо говоря кто деньги может зарабатывать на результате деятельности), которые очень часто, но неверно называют авторскими правами.
Нашел свободный день на исследование и обнаружил, что проблему в gcc 4.3.4 вызывает включение -fstrict-aliasing.
При этом, добавление -Wstrict-aliasing=1 (самый высокий уровень предупреждений) никаких релевантных предупреждений не дает (что при компиляции в gcc 4.3.4, что при использовании более новых версий). Точнее даже в коде, из которого собирается проблемный исполняемый файл и библиотеки предупреждений просто нет.
Более того, при использовании gcc версии 4.4.4 и новее никаких проблем с работой кода не наблюдается.
Так что ситуация понятнее не стала.
Интересно было бы еще запустить тесты на gcc 4.3.[5-6] и 4.4.[0-3], но я сходу не нашел старых дистрибутивов линуксов, где они есть по умолчанию, чтобы не пересобирать компиляторы самостоятельно.
По словам разработчиков Эльбруса у них полностью свой бэкенд компилятора, а фронтенд от компании EDG (к слову точно такой же фронтенд использует компилятор Intel, но его почему то форком GCC никто не называет).
Я в своей практике общения с g++ сталкивался с двумя глобальными проблемами из-за -O3.
Первая — gcc 4.4.4 на некотором коде с некоторым набором параметров компилятора просто падал с core dump. Тогда оптимизация была просто понижена до -O0 (чтобы вообще не разбираться), благо не компилировался код вспомогательного приложения и разбираться, что не нравится компилятору особого смысла не было — и так все работало быстро.
Вторая проблема была с gcc 4.3.4. В приложении использовался Boost и его контейнеры из Boost.Container. Наиболее яркое и запомнившееся проявление проблемы было, когда был boost::container::vector с данными, если у него посмотреть size(), то там одно значение (неправильное или 0), если посчитать end()-begin() — другое значение (почти всегда правильное), если отладчиком посмотреть в структуру, где оно хранит данные, то в памяти значения всегда верные.
Ни в одной другой версии компилятора (новее) воспроизвести не удалось. В gcc 4.3.4 Нормально работало только с оптимизацией -O1. Я бы еще понял, если бы код был многопоточный, но код был однопоточным и по сути логически один и тот же код давал то правильные данные, то неправильные.
Если у Вас есть идея, как можно подебажить второй случай, то я с радостью ее выслушаю, так как мне было бы интересно попытаться докопаться до причины такого поведения компилятора.
Кажется, Вам немедленно нужно обратиться в компанию ВСМПО-АВИСМА для закупки титановых защитных щитков во избежание катастрофы.
А аргументация, базирующаяся на никнейме собеседника — это пожалуй даже оригинальная вещь. +1 Вам за изобретательность.
Резюмируя вышесказанное я вынужден процитировать господина mayorovp:
> Ваше мнение было очень ценным для нас. Только, кажется, вы забыли его аргументировать.
P.S. В тред призывается к.ф.-м.н. kbtsiberkin. Может быть он, как практикующий теорфизик, скажет по существу что-нибудь еще.
> Контекст статьи «использования для высокопроизводительных математических вычислений». И именно в этом контексте фортран никого интересовать не может.
Вот именно в этой области фортран дико популярен и конкурирует с C&C++ нередко выигрывая у них.
А приведенные выше MatLab, Python, та же Mathematica — это чаще всего лишь инструменты прототипирования или текущих расчетов над небольшими моделями.
Справедливости ради MatLab поддерживает параллельные вычисления на суперкомпьютерах, но на практике я не видел чтобы это активно применялось, хотя раз поддерживает, то наверняка не просто так…
> 1. Для повышения производительности часто используется выравнивание строк.
Или не используется, если некоторые алгоритмы можно преобразовать так, чтобы вместо перебора двух индексов перебирать один, проходя по всей матрице последовательно (фактически построчно).
В этом случае для векторизации выравнивание отдельных строк не требуется, так как конец одной строки и начало следующей можно обрабатывать в одной векторной инструкции. Да и для компилятора такой код векторизовать будет проще, чем перебор двух индексов.
Спасибо!
Но там ссылка на письмо от 2005 года, те еще до вступления в силу новой 4 части ГК (которая сейчас действует), в комментариях это как фактор риска описывают.
Не видели ли Вы каких либо более новых разъяснений/комментариев на этот счет?
А есть ли какие-либо разъяснения от налоговой и/или других органов на эту тему? (Только может быть не продажа, а лицензирование — заключение лицензионных договоров?) И что делать с налогами, которые сверху (взносы в ПФР и ФОМС), должен ли их платить лицензиат?
Почему выкидывать? Нагрузка на сервер, это один из многих параметров, которые необходимо учитывать.
Вот к примеру у меня есть система, в которой при нагрузке более 60% latency начинает взлетать чуть ли не экспоненциально. К счастью в этой системе это не критично, но неприятно, так как в худшем случае ждать запуска задачи иногда приходится в несколько раз дольше, чем она будет выполняться (характер нагрузки — пакетный).
Недавно на хабре в комментариях видел пример, где система работала под нагрузкой процентов в 90, но там поток задач был равномерен, одинаков и известен, по этому задержки были приемлемыми и не взлетали в небеса.
Другая сторона медали — резервирование.
Если у Вас есть кластер из 2 нод, то загружать каждую более чем на 50% категорически нельзя, ибо в случае выхода из строя одной из них вторая умрет от перегрузки.
Если ноды 3, то предел загрузки каждой из них — 2/3, если мы хотим пережить отказ одной ноды без падения.
Третья сторона — рост системы. Новое оборудование прирастает обычно дискретно, а нагрузка может увеличится непредсказуемо и нужно держать оперативный резерв для прохождения пиков или просто роста аудитории.
И это далеко не все стороны, которые могут учитываться в реальной задаче и зависеть от загрузки оборудования.
Если сложить все это вместе, то вполне может оказаться, что в какой-то системе эти 30% загрузки — это и есть максимальная эффективность, при которой можно оказывать качественный сервис и еще одна доля процента экономии приведет к краху.
А еще удобнее, когда есть репозитории. Тогда вообще все прекрасно и практически однокомандно.
В другой стороны, я не совсем понимаю, зачем из tar.gz архива ставить анализатор в /usr/bin. У меня он прекрасно поселился в ~/bin/pvs/… и работал без проблем, главное, PATH правильный подсовывать, так как вроде бы анализатор еще один файл из этого же каталога вызывает и без PATH он его не находит.
Вышесказанное, однако, не относится к пакетам. Из них действительно принято ставить в /usr/bin или в иерархию /opt.
P.S. Интересное решение получилось у вас. Хотя демолицензия у меня уже кончилась результатов анализа я заготовил достаточно, чтобы по выходным их вдумчиво читать и анализировать. Так что может быть, я Вам еще о чем-нибудь и напишу.
Просто одна цитата цифрами:
> According to Unesco, 29% of people in scientific research worldwide are women, compared with 41% in Russia. In the UK, about 4% of inventors are women, whereas the figure is 15% in Russia.
Или из-за того, что курс философии в аспирантуре по большей смысловой части состоял из семинаров, где учащимся приходилось готовить доклады, аргументировать свою точку зрения, вступать в дискуссии, рассказывать о своей научной работе аспирантам других специальностей, чтобы они при этом все поняли и т.д.?
Если первый случай, то Вам катастрофически не повезло с преподавателями (к сожалению, это часто встречается), а если второе, то проблема в Вас.
И, к сожалению, нередко наблюдается ситуация, когда второй метод преподавания философии, что у студентов, что у аспирантов вызывает гораздо больше негатива, чем первый, из-за банальной собственной лени (рефератиком из интернетика уже не отделаться — думать надо)…
А в чем проблема в отсутствии на работе 2 месяца в году?
Немало должностей по ТК имеют оплачиваемый отпуск по 1,5-2 месяца и ничего, работают компании.
Другое дело, что среднестатистические датацентры рассчитываются на малое энергопотребление, а не на высокую производительность оборудования, отсюда и лимиты в 10кВт на стойку.
Что по охлаждению, то воздухом можно снять 20-25кВт со стойки. Системами на подобие с водяной дверью порядка 40кВт, а водой до 400кВт (рекорд РСК).
Так что если Вы лимитированы питанием и/или охлаждением, то высокоплотные системы просто не для Ваших задач, а если Вам нужна высокая плотность, то Вас уже не заботят стандартные датацентры, а инженерная инфраструктура подгоняется под используемое оборудование.
Segmentation fault процесса компилятора я все же никак не могу списать на ошибку в своем коде, а не в компиляторе и -O3 :)
Вопрос, зачем так сделали в Boost пока так и остается без ответа в рассылке и багтрекере.
Это действительно баг в коде boost::container::flat_map, но который на моем наборе компиляторов стрелял только в gcc 4.3.4.
https://github.com/boostorg/container/blob/develop/include/boost/container/flat_map.hpp#L61-L70
Функция force хотя бы работает, а вот force_copy сильно не всегда. Почему они написаны именно так я не знаю. В рассылке мне ответили только то, что да, это ломает strict-aliasing, но зачем так сделали — осталось без ответа.
Так что минус один баг в компиляторе, +1 баг в Бусте.
Но чтобы не было все так хорошо с компиляторами (и в моем списке осталось ровно 2 бага), вспомню еще один случай на компиляторе из RHEL7.0, когда при включении LTO он просто падал с segmentation fault на некотором коде :)
Право авторства неотчуждаемы, и в России, и в США. Те никто не может заявить, что это придумал он, а не реальный автор. Неотчуждаемость права авторства, кстати, не требует обязательного сообщения имени автора, по этому имен разработчиков Windows, да и любых продуктов из России Вы не найдете.
А все то, что Вы написали — это про имущественные права (грубо говоря кто деньги может зарабатывать на результате деятельности), которые очень часто, но неверно называют авторскими правами.
При этом, добавление -Wstrict-aliasing=1 (самый высокий уровень предупреждений) никаких релевантных предупреждений не дает (что при компиляции в gcc 4.3.4, что при использовании более новых версий). Точнее даже в коде, из которого собирается проблемный исполняемый файл и библиотеки предупреждений просто нет.
Более того, при использовании gcc версии 4.4.4 и новее никаких проблем с работой кода не наблюдается.
Так что ситуация понятнее не стала.
Интересно было бы еще запустить тесты на gcc 4.3.[5-6] и 4.4.[0-3], но я сходу не нашел старых дистрибутивов линуксов, где они есть по умолчанию, чтобы не пересобирать компиляторы самостоятельно.
Первая — gcc 4.4.4 на некотором коде с некоторым набором параметров компилятора просто падал с core dump. Тогда оптимизация была просто понижена до -O0 (чтобы вообще не разбираться), благо не компилировался код вспомогательного приложения и разбираться, что не нравится компилятору особого смысла не было — и так все работало быстро.
Вторая проблема была с gcc 4.3.4. В приложении использовался Boost и его контейнеры из Boost.Container. Наиболее яркое и запомнившееся проявление проблемы было, когда был boost::container::vector с данными, если у него посмотреть size(), то там одно значение (неправильное или 0), если посчитать end()-begin() — другое значение (почти всегда правильное), если отладчиком посмотреть в структуру, где оно хранит данные, то в памяти значения всегда верные.
Ни в одной другой версии компилятора (новее) воспроизвести не удалось. В gcc 4.3.4 Нормально работало только с оптимизацией -O1. Я бы еще понял, если бы код был многопоточный, но код был однопоточным и по сути логически один и тот же код давал то правильные данные, то неправильные.
Если у Вас есть идея, как можно подебажить второй случай, то я с радостью ее выслушаю, так как мне было бы интересно попытаться докопаться до причины такого поведения компилятора.
А аргументация, базирующаяся на никнейме собеседника — это пожалуй даже оригинальная вещь. +1 Вам за изобретательность.
Резюмируя вышесказанное я вынужден процитировать господина mayorovp:
> Ваше мнение было очень ценным для нас. Только, кажется, вы забыли его аргументировать.
P.S. В тред призывается к.ф.-м.н. kbtsiberkin. Может быть он, как практикующий теорфизик, скажет по существу что-нибудь еще.
Вот именно в этой области фортран дико популярен и конкурирует с C&C++ нередко выигрывая у них.
А приведенные выше MatLab, Python, та же Mathematica — это чаще всего лишь инструменты прототипирования или текущих расчетов над небольшими моделями.
Справедливости ради MatLab поддерживает параллельные вычисления на суперкомпьютерах, но на практике я не видел чтобы это активно применялось, хотя раз поддерживает, то наверняка не просто так…
Или не используется, если некоторые алгоритмы можно преобразовать так, чтобы вместо перебора двух индексов перебирать один, проходя по всей матрице последовательно (фактически построчно).
В этом случае для векторизации выравнивание отдельных строк не требуется, так как конец одной строки и начало следующей можно обрабатывать в одной векторной инструкции. Да и для компилятора такой код векторизовать будет проще, чем перебор двух индексов.
Но там ссылка на письмо от 2005 года, те еще до вступления в силу новой 4 части ГК (которая сейчас действует), в комментариях это как фактор риска описывают.
Не видели ли Вы каких либо более новых разъяснений/комментариев на этот счет?
Вот к примеру у меня есть система, в которой при нагрузке более 60% latency начинает взлетать чуть ли не экспоненциально. К счастью в этой системе это не критично, но неприятно, так как в худшем случае ждать запуска задачи иногда приходится в несколько раз дольше, чем она будет выполняться (характер нагрузки — пакетный).
Недавно на хабре в комментариях видел пример, где система работала под нагрузкой процентов в 90, но там поток задач был равномерен, одинаков и известен, по этому задержки были приемлемыми и не взлетали в небеса.
Другая сторона медали — резервирование.
Если у Вас есть кластер из 2 нод, то загружать каждую более чем на 50% категорически нельзя, ибо в случае выхода из строя одной из них вторая умрет от перегрузки.
Если ноды 3, то предел загрузки каждой из них — 2/3, если мы хотим пережить отказ одной ноды без падения.
Третья сторона — рост системы. Новое оборудование прирастает обычно дискретно, а нагрузка может увеличится непредсказуемо и нужно держать оперативный резерв для прохождения пиков или просто роста аудитории.
И это далеко не все стороны, которые могут учитываться в реальной задаче и зависеть от загрузки оборудования.
Если сложить все это вместе, то вполне может оказаться, что в какой-то системе эти 30% загрузки — это и есть максимальная эффективность, при которой можно оказывать качественный сервис и еще одна доля процента экономии приведет к краху.
10BASE-T — это 10 Мбит/с.
Странно видеть такого гостя из мезозоя в современной СХД :)
А стандарт на 10Гбит/с по витой паре называется 10GBASE-T.
В другой стороны, я не совсем понимаю, зачем из tar.gz архива ставить анализатор в /usr/bin. У меня он прекрасно поселился в ~/bin/pvs/… и работал без проблем, главное, PATH правильный подсовывать, так как вроде бы анализатор еще один файл из этого же каталога вызывает и без PATH он его не находит.
Вышесказанное, однако, не относится к пакетам. Из них действительно принято ставить в /usr/bin или в иерархию /opt.
P.S. Интересное решение получилось у вас. Хотя демолицензия у меня уже кончилась результатов анализа я заготовил достаточно, чтобы по выходным их вдумчиво читать и анализировать. Так что может быть, я Вам еще о чем-нибудь и напишу.