В англоязычной литературе я не нашел ни одного упоминания о том, что Гольфстрим остановился.
Есть упоминания о быстром замедлении течения но я видел это только в бульварной прессе. Да и замедление течения скорее связано с глобальными климатическими изменениями, а не по причине разлития нефти.
Хочу также добавить, что Гольфстрим всего навсего в незначительной степени влияет на умеренный климат Европы(пруф).
Я не могу в данном случае вступить в дискуссию поскольку использую Emacs, база которого написана на C, но все расширения, которые собственно и делает его чем-то большим чем просто текстовым редактором — на Lisp. И да — работает все это отлично.
В случае Java мне кажется есть какое-то непонимание, возможно и с моей стороны в том числе. Я лично не разрабатываю на Java, но мне всегда казалось что GC не основная ее проблема(как и многих других языков bytecode которых не подвергается агрессивным оптимизациям как в случае с GCC).
AllexIn у каждого языка и его библиотек есть свои сильные и слабые стороны и, естественно, свои ниши применения.
Но IMHO нельзя сказать, что программа написанная на C++ автоматически работает быстрее, чем, например, на Python.
Очень многое зависит от реализации платформы и собственно алгоритма.
Естественно, GC вносит свои 5 копеек в производительность, но с другой стороны в некоторых случаях он может даже в итоге ее увеличить. К примеру immutable объекты в правильной реализации не дублируются. Это означает, что если Вы пишете многопоточную программу которая имеет дело с однородными данными(скажем frontend распределенной файловой системы) то потребление памяти может оказаться ниже нежели при написании на C++, что приводит к меньшей фрагментации последней.
И никто не говорил, что написание на C++ невозможно писать нормально =). Ровные руки и дело в шляпе.
Каждой задаче свой язык. Я согласен, что для некоторых задач к сожалению применимы в данный момент C/C++. Это не означает, что остальные языки для развлечений.
Я лично не большой фанат языков подобных C или С++ потому, что их сложность и неоднозначность отвлекают от алгоритмической части. Тем не менее я трачу порядка 80% своего рабочего времени именно на написание кода на них. В свободное от работы время с удовольствием балуюсь Python или Ruby.
Как отметил товарищ madfly все зависит от распараллеливания задач. Чтоб делать громкое заявления HDD быстрее(иногда) DDR нужно во первых отключить дисковый кэш, перевести планировщик ввода/вывода в режим «noop», использовать один процессор(с одним ядром и без поддержки физических потоков).
И, конечно, добавить в итоге результаты нагрузки на CPU.
В целом — тест не о чем.
Использую Emacs с темным фоном иначе под конец дня вылазят глаза от яркого свечения экрана.
Иногда даже использую очки «хамелеон» чтоб расслабить глаза.
ИМХО это все индивидуально и зависит от восприимчивости к яркости. Так, в моем случае я вынужден носить очки «хамелеон» даже весной и осенью(или заснеженной зимой).
Не думаю, что провайдеры обращают внимание на QoS опции пакетов в общей очереди в принципе. Скорее всего это обязывает их отключить дополнительную классификацию по пункту назначения.
Я уверен, что провайдеры все равно делили и будут делить трафик между абонентами. Внутри очереди абонента всегда сохранялся и будет сохраняться приоритет выставленный пользователем.
Тянуть форк дебиана? Нуну. Лучше бы сделали альтернативу и возможность бесшовного переключения систем инициализации и управления системой.
Идея systemd хороша — унификация системы управления. Как для разработчиков ПО, так и для «паковальщиков» онного это глобальное упрощение — не надо создавать отдельно скрипты инициализации под разные дистрибутивы и окружения.
С другой стороны — systemd ужасный геморрой. Его отладить практически невозможно. Это то же самое, что отлаживать X/Gnome/KDE/etc. Но в отличии от графической(звуковой, игровой, какой угодно) подсистемы — система инициализации более критична, особенно в секторе серверов.
Сказать ваша система говно — просто, а создать хорошую архитектуру — довольно сложно, и почему-то никто не берется. Все кричат и и машут вилками.
Старая система init.d имеет свои ограничений, потому был создан upstart, который по неясным мне причинам умер. Каким-то образом вирус systemd проник во множество дистрибутив, скорее всего потому, что был многообещающим. Сейчас г-н Poettering занимается инцестом, но вместо того, чтоб сделать форк systemd и показать многоуважаемому автору сего продукта какой должна быть архитектура сложной системы — пожалуйста, мы сделаем форк debian и будет заниматься своим инцестом.
К стати — вариант с кэшем не совсем уместен по отношению к первому примеру, поскольку второй индекс — это как раз строка, то есть во внутреннем цикле будет проход как раз по строке — последовательно в памяти. Прошу прощения — невнимательно читал. Ведь я же все знаю про массивы! ;)
Все-таки мало кому из начинающих разработчиков может прийти в голову думать о проблемах касательно способа доступа к памяти или особенностях реализации компилятора/виртуальной машины/интерпретатора.
Изначальный код, возможно, будет превосходно работать с каким-то компилятором в силу того, что он попадает под определенный шаблон оптимизации, точно так же, как и во многих случая i*2 === i<<1 для беззнаковых целых, если процессор поддерживает операцию сдвига.
Или например в с/с++ массивы вида int (a*)[n] и int **a неравноправны по отношению как к потреблению памяти так и доступа.
Я согласен, что задача интересна тем, чтоб посмотреть как человек будет пытаться анализировать ситуацию. И да, возникают вопросы =)
Я думаю, что это не задача для новичка, потому, что это архитектурно-зависимая проблема.
Также задача зависит от уровня оптимизации компилятора, который может «удачный» вариант развернуть в неудачный ассемблер. Был у меня такой опыт, когда мне нужно было оптимизировать кусок кода, но после компиляции, ассемблер на выходе был хуже, чем изначальный вариант. А все потому, что своими действиями я сбивал оптимизатор компилятора и тот принимал малопитательные решения.
Если уже говорить о кешах — тут вообще тоска — размер строки кэша может варьироваться от 16 байт до 256. Я думаю что даже эти рамки можно поставить под сомнение. Так что же, писать код который будет зависеть от процессора? А как быть с системами реального времени где кэш часто отсутствует в меру своей непредсказуемости? Да и не стоит забывать про то что есть системы без поддержки страниц памяти, или наоборот с поддержкой огромных страниц.
Ну а если конкретнее — Вы хотели инициализировать массив — мой ответ memset!
Я думаю, что для абстрагирования от длины конвейера(и для программной совместимости) в ARM всегда присуствует только 2 «зафиксированных» шага перед точкой выполнения инструкции.
Но было бы интересно услышать мнение эксперта.
Сейчас еще открыт список нововведений для ChibiOS 3.0. Если кому интересно — можно поучаствовать в дебатах. Текущий список TODO тут.
Еще одно примечательное отличие от FreeRTOS — стабильные LTS релизы, что для некоторых компаний может играть решающую роль.
Да и как-то вся инфраструктура у ChibiOS на первый взгляд более организована.
Лично мне больше по душе структура API и повсеместное использование doxygen.
У FreeRTOS, в отличии от ChibiOS, нет HAL для периферии — приходится тягать библиотеки поставщиков.
В ChibiOS по большему счету также используются внешние библиотеки под HAL, но они уже аккуратно обернуты в законченный API.
К примеру порт для pic32mx абсолютно не зависит на microchip и прекрасно собирается чистым gcc.
Я согласен, что отсутсвие POSIX-совместимости затрудняет переносимость с одной OS на другую, но в мире встраиваемых систем гораздо чаще идет работа с устройствами, а не файлами, а тут, увы POSIX не лучший кандидат на абстракцию.
По личному опыту скажу, что в большинстве случаев ОС не меняют как перчатки. Также многие компании имеют свои слои абстракций, которые затачиваются под внутренние требования.
Есть упоминания о быстром замедлении течения но я видел это только в бульварной прессе. Да и замедление течения скорее связано с глобальными климатическими изменениями, а не по причине разлития нефти.
Хочу также добавить, что Гольфстрим всего навсего в незначительной степени влияет на умеренный климат Европы(пруф).
В случае Java мне кажется есть какое-то непонимание, возможно и с моей стороны в том числе. Я лично не разрабатываю на Java, но мне всегда казалось что GC не основная ее проблема(как и многих других языков bytecode которых не подвергается агрессивным оптимизациям как в случае с GCC).
Но IMHO нельзя сказать, что программа написанная на C++ автоматически работает быстрее, чем, например, на Python.
Очень многое зависит от реализации платформы и собственно алгоритма.
Естественно, GC вносит свои 5 копеек в производительность, но с другой стороны в некоторых случаях он может даже в итоге ее увеличить. К примеру immutable объекты в правильной реализации не дублируются. Это означает, что если Вы пишете многопоточную программу которая имеет дело с однородными данными(скажем frontend распределенной файловой системы) то потребление памяти может оказаться ниже нежели при написании на C++, что приводит к меньшей фрагментации последней.
И никто не говорил, что написание на C++ невозможно писать нормально =). Ровные руки и дело в шляпе.
Я лично не большой фанат языков подобных C или С++ потому, что их сложность и неоднозначность отвлекают от алгоритмической части. Тем не менее я трачу порядка 80% своего рабочего времени именно на написание кода на них. В свободное от работы время с удовольствием балуюсь Python или Ruby.
И, конечно, добавить в итоге результаты нагрузки на CPU.
В целом — тест не о чем.
Иногда даже использую очки «хамелеон» чтоб расслабить глаза.
ИМХО это все индивидуально и зависит от восприимчивости к яркости. Так, в моем случае я вынужден носить очки «хамелеон» даже весной и осенью(или заснеженной зимой).
Я уверен, что провайдеры все равно делили и будут делить трафик между абонентами. Внутри очереди абонента всегда сохранялся и будет сохраняться приоритет выставленный пользователем.
Идея systemd хороша — унификация системы управления. Как для разработчиков ПО, так и для «паковальщиков» онного это глобальное упрощение — не надо создавать отдельно скрипты инициализации под разные дистрибутивы и окружения.
С другой стороны — systemd ужасный геморрой. Его отладить практически невозможно. Это то же самое, что отлаживать X/Gnome/KDE/etc. Но в отличии от графической(звуковой, игровой, какой угодно) подсистемы — система инициализации более критична, особенно в секторе серверов.
Сказать ваша система говно — просто, а создать хорошую архитектуру — довольно сложно, и почему-то никто не берется. Все кричат и и машут вилками.
Старая система init.d имеет свои ограничений, потому был создан upstart, который по неясным мне причинам умер. Каким-то образом вирус systemd проник во множество дистрибутив, скорее всего потому, что был многообещающим. Сейчас г-н Poettering занимается инцестом, но вместо того, чтоб сделать форк systemd и показать многоуважаемому автору сего продукта какой должна быть архитектура сложной системы — пожалуйста, мы сделаем форк debian и будет заниматься своим инцестом.
Все-таки мало кому из начинающих разработчиков может прийти в голову думать о проблемах касательно способа доступа к памяти или особенностях реализации компилятора/виртуальной машины/интерпретатора.
Изначальный код, возможно, будет превосходно работать с каким-то компилятором в силу того, что он попадает под определенный шаблон оптимизации, точно так же, как и во многих случая i*2 === i<<1 для беззнаковых целых, если процессор поддерживает операцию сдвига.
Или например в с/с++ массивы вида int (a*)[n] и int **a неравноправны по отношению как к потреблению памяти так и доступа.
Я согласен, что задача интересна тем, чтоб посмотреть как человек будет пытаться анализировать ситуацию. И да, возникают вопросы =)
Также задача зависит от уровня оптимизации компилятора, который может «удачный» вариант развернуть в неудачный ассемблер. Был у меня такой опыт, когда мне нужно было оптимизировать кусок кода, но после компиляции, ассемблер на выходе был хуже, чем изначальный вариант. А все потому, что своими действиями я сбивал оптимизатор компилятора и тот принимал малопитательные решения.
Если уже говорить о кешах — тут вообще тоска — размер строки кэша может варьироваться от 16 байт до 256. Я думаю что даже эти рамки можно поставить под сомнение. Так что же, писать код который будет зависеть от процессора? А как быть с системами реального времени где кэш часто отсутствует в меру своей непредсказуемости? Да и не стоит забывать про то что есть системы без поддержки страниц памяти, или наоборот с поддержкой огромных страниц.
Ну а если конкретнее — Вы хотели инициализировать массив — мой ответ memset!
Но было бы интересно услышать мнение эксперта.
Если я правильно понимаю, то в ARM PC равен ССК, и как такового АСК нет в принципе.
Еще одно примечательное отличие от FreeRTOS — стабильные LTS релизы, что для некоторых компаний может играть решающую роль.
Да и как-то вся инфраструктура у ChibiOS на первый взгляд более организована.
У FreeRTOS, в отличии от ChibiOS, нет HAL для периферии — приходится тягать библиотеки поставщиков.
В ChibiOS по большему счету также используются внешние библиотеки под HAL, но они уже аккуратно обернуты в законченный API.
К примеру порт для pic32mx абсолютно не зависит на microchip и прекрасно собирается чистым gcc.
По личному опыту скажу, что в большинстве случаев ОС не меняют как перчатки. Также многие компании имеют свои слои абстракций, которые затачиваются под внутренние требования.