Кстати, 64-битную архитектуру AMD реализовала первая, и уже Intel пришлось догонять (недоразумение с Itanium оставим за скобками). Так что да, у догоняющих иногда получается более инновационно. А иначе как догонять…
Меня особенно порадовало «времени просто заняться сексом нет, отчего мужики спиваются, а женщины изменяют мужьям», т.е. на то, чтобы бухать и изменять мужьям — на это время есть. Интересно, в чём тогда состоит измена, если времени заняться сексом нет? Трудятся совместно с любовником на благо капиталиста?
А разработчик может тоже с чистой совестью ответить, что не имеет доступа. К исходникам своего проекта — да (в той его части, в которой оно ему надо для работы).
Скорее всего, просто не хотят, чтобы к ним пришёл какой-нибудь роспотребнадзор с проверками, и минимизируют риски по проектам, которые в этом центре разрабатываются.
Есть несколько групп разработчиков, которые занимаются разными типами проектов. В стенах московского офиса, в частности, ведется работа над сервисом словарей, утилитами для runtime тестирования, отдельными частями Chrome OS, технологией Native Client. Последняя в будущем реализует запуск машинного (нативного) кода в различных браузерах. Причем независимо от операционной системы и безопасно с точки зрения пользователя. Это, кстати, открытый проект, исходники которого всегда доступны на сайте code.google.com/p/nativeclient. Runtime-тестирование — это отдельная тема. В московском офисе Google работает Костя Серебряный, который создал утилиту ThreadSanitizer (сode.google.com/p/dataracetest), позволяющую полуавтоматически находить data races (состояние гонки). Такие ошибки очень сложно поймать обычными средствами тестирования и отладки, особенно когда объем кода очень большой.
Как связан закон о персональных данных с центром разработки?
Я тоже это не вполне понял.
Ну ладно бы, они вообще весь бизнес в россии сворачивали — минимизировать риски в случае возникновения претезий. Но ведь «поисковик может сохранить часть штата в сферах продаж, делового партнерства, техподдержки, маркетинга и коммуникаций. А по данным Bloomberg, параллельно с выводом департамента разработки из страны, Google планирует увеличить в России инвестиции в бизнес-операции.» — как это тогда понимать?
Видимо, смысл в том, что центр разработки — это самая уязвимая часть бизнеса из того, что находится в России, и его «эвакуируют».
Интересно, что у них там разрабатывают (или, теперь уже «разрабатывали»)?
А вот это не имеет никакого отношения к мозгам. Ну во всяком случае не к техническим мозгам. А к управленческим. А их как не было, так и нет. Вот эти мозги — да — они в неволе не размножаются. В неволе — только «эффективные» менеджеры.
Открою страшную тайну: можно и без подписки — если перейти на статью по ссылке выдачи поиска гугла. Гуглите по первой строке статьи «Google Inc. is shutting its engineering office in Russia after the government cracked», открывайте первую ссылку, и можно читать спокойно.
Просто для тех, кто вдруг решит делать проект на VNC2 (Vinculum II) — подумайте дважды, надо ли оно вам.
Глючит всё: препроцессор-компилятор-линкер (весь toolchain по сути), дебаггер, среда, отладочный модуль, библиотеки, RTOS. Компилятор производит огромный image даже на максимальной оптимизации (на которой он глючит ещё больше). Ассемблер не документирован, архитектура не документирована, использование периферии — только через библиотеки, предоставляемые FTDI (исходники закрыты) — причём библиотеки очень неудобные и убогие местами. По сути, засекретили всё, что можно и нельзя — и это сильно усложняет и без того трудную отладку этого рассадника багов.
Ошибки в компиляторе просто шокирующие. Например, криво поддерживается инициализация переменной выражением при объявлении — последующие функции используют неинициализированное значение переменной (и это при минимальной регистровой оптимизации).
Т.е. вот такой код не работает:
void foo (unsigned short sector)
{ unsigned int offset = (unsigned int) sector*0x1000;
erase(offset); // функция вызывается с неинициализированным значением offset
// чтобы заработало, нужно отделить декларацию offset от её инициализации
}
«address» — это зарезервированное ключевое слово языка, однако это нигде не документировано, и из сообщения об ошибке хрен поймёшь, почему нормальный код не компилируется.
Вот такой код
#define sl(a) strlen(a)
sl(«a,b»); // fails
выдаст вам ошибку «P4001 argument mismatch», потому что запятая внутри строке интерпретируется как разделитель параметров макроса.
А, например,
sizeof("\r\n")
вернёт вам «5», потому что backspace считается за часть строки.
Если вы включаете прямо или косвенно больше 70-ти #include-ов в свой модуль — выдаётся "#include nested too deep" — даже если никакого «nested» нет и в помине — специально для теста включал пустые заголовки последовательно. Т.е. тупо вместо уровня вложенности считают общее количество вложений. Это накладывает серьёзные ограничения на организацию программы.
И таких глюков — просто пруд пруди. И это в последней верссии компилятора, спустя 4 года выхода продукта.
Крайне не рекомендую. Сам им занимаюсь только потому, что проект (без моего участия) дошёл до стадии, когда менять процессор уже поздно.
Если внутри самого обработчика вы уже не ждёте событий — то это нормальная практика event-driven приложения. Все ожидания тоже реализуются как события таймера (для совсем коротких можно делать исключения и реализовать программным циклом).
В принципе, как тут уже заметили, любая линейная программа (да и вообще любая программа) это автомат. Просто в атоматном программировании какая-то часть переменных состояния явно выделяется и называется таковыми, и алгоритм строится вокруг текущего состояния.
Вы в обработчике события вы так или иначе проверяете переменные, которые отражают текущее состояние программы, и выполняете какие-то действия в зависимости от этого, и меняете эти переменные — переключая ваш автомат в другое состояние.
Автоматному способу организации программы очень мешают «блокирующие» функции с ожиданием внешних событий. Пока такая функция выполняется (ничего, по сути, не делая — лишь ожидая внешнего события) — вы не можете обрабатывать другие события. К сожалению, иногда приходится использовать стороннее API с такими функциями. Тогда их можно вызывать в отдельном треде, тщательно изолируя от основного треда, и посылая события по завершении блокирующей функции. Объём кода в допонительном коде нужно при этом минимизировать, чтобы снизить усилия и вероятность ошибок синхронизации/thread safety. Ещё одна хорошая причина иметь более одного потока выполнения — это если приложение выполняется на многоядерном процессоре или многопроцессорной системе, и есть желание использовать воможности параллельной обработки для вычислительно сложных задач. Но в общем случае, «threads are evil».
Я упомянул про автоматное программирование, потому что у автора основной цикл занимает секунды. Скорее всего, он ожидает внешних событий непосредственно в этом цикле — ожидает сотни миллисекунд тут и там, вместо того, чтобы запомнить состояние «ждём следующий символ» или «ждём 100 мс перед тем, как проверить состояние линии» — и освободить процессор для других задач.
Чтобы понятнее было, о чём идёт речь: GPS модуль NEO-6M порядка 300 руб., компас на HMC5883L порядка 70 руб. в розницу, с доставкой. Smartflower 32 will retail at £15,000 plus VAT for standard installations (порядка 1.1 млн рублей).
Ну как бы нет смысла совсем напрягать дорогих клиентов ручным вводом координат и времени.
Если панели лежат в одной (параллельных) плоскостях, а источник далеко, никакой разницы напряжения не возникает.
Хотя можно, конечно, водить панелью по сторонам в поисках солнца или сделать дополнительно уголок из 3-х датчиков освещённости в перпендикулярных плоскостях для наведения. Плюсом была бы некоторая универсальность — например, работа при наличии отражённого источника излучения (например, такого). Минус — в облачный день не настроится, нужно забивать координаты вручную при развёртывании.
GPS всё же проще (точнее, GPS+датчик магнитного поля). Стоит копейки (по сравнению со стоимостью всего девайса), зато для развёртывания в любой точке земли нужно только нажать кнопку. Если не смог по GPS — тогда уже звать юзера и просить ввести координаты/время вручную.
По результатам эксперимента наиболее энергоэффективный дом использовал на 55% меньше электричества, чем контрольный. Второй дом сэкономил 37%.
А почему сравнивают только электричество? Отапливались они тоже электричеством? И даже «энергоэффективный»?
P.S. глянул отчёт, так и есть.
All three houses are all-electric (with the exception of a gas log fireplace that is not used during the testing) and use air-source heat pumps for heating and cooling.
«Для подбора ключей в нашем исследовании использовался набор программируемых пользователем вентильных матриц (FPGA), которые вошли в моду пару лет назад для майнинга цифровой валюты Bitcoin, а после падения популярности этого развлечения сильно подешевели.»
Вы удивитесь, но это развлечение по-прежнему популярно, просто теперь никто не использует для этого FPGA — давно разработаны и производятся специализированные ASIC.
Прочитав про ваши трудности с организацией кода и шайтанство с длительностью циклов, обработкой прерываний и тд — захотелось порекомендовать вам почитать про автоматное программирование и событийно-ориентированное программирование. Если уж вы решили заниматься встроенным программированием — без этого никуда. Либо мультитред, либо автоматы. Причём мультитред — по сути частный случай автомата, где контекст треда является состоянием автомата. Поскольку операционки у вас нет, да и смысла в ней нет на такой простой системе и для такой простой задачи, то остаютсятся автоматы (оно и предпочтительнее в большинстве случаев, даже если мультитрединг поддерживается — чем кувыркаться с синхронизацией тредов, реентерабельностью, thread safety и прочими «радостями»).
Поначалу кажется, что это сложнее, чем «линейное» кодироваине, но это вопрос привычки.
Интересно, а как решается проблема полярности? Если во всех соединениях магниты, то становится довольно сложно следить, чтобы N всегда приходился на S. Или в стыкующих кубиках не магниты, а железо?
Повторюсь, выше уже отвечал на аналогичный комментарий. Если ребёнок достаточно разумен, чтобы магнит выковырять, то он достаточно разумен, чтобы его не толкать в рот, особенно если его перед этим проинструктировать и объяснить, чем это грозит.
Единственный вариант — если ребёнок специально выковырял и запихал два магнита с временным промежутком себе (или кому-то) в кишечник. Но это уже какие-то суициидальные (криминальные) наклонности, если есть желание, то будет и возможность, хоть какие игрушки ему давай.
Если ребёнок достаточно разумен, чтобы его достать, то он также достаточно разумен, чтобы не толкать его в рот и держаться подальше от магнитов, если один вдруг случайно в рот таки попал — после соответствующего инструктажа от родителей.
Если ребёнок недостаточно разумен — то и нефиг ему такой конструктор давать.
А так можно до маразма дойти легко, и держать детей в обитой войлоком комнате — а то вдруг дитя вздумает головой об стенку стукнуться из любопытства.
Скорее всего, просто не хотят, чтобы к ним пришёл какой-нибудь роспотребнадзор с проверками, и минимизируют риски по проектам, которые в этом центре разрабатываются.
Вроде, ничего супер критичного.
Я тоже это не вполне понял.
Ну ладно бы, они вообще весь бизнес в россии сворачивали — минимизировать риски в случае возникновения претезий. Но ведь «поисковик может сохранить часть штата в сферах продаж, делового партнерства, техподдержки, маркетинга и коммуникаций. А по данным Bloomberg, параллельно с выводом департамента разработки из страны, Google планирует увеличить в России инвестиции в бизнес-операции.» — как это тогда понимать?
Видимо, смысл в том, что центр разработки — это самая уязвимая часть бизнеса из того, что находится в России, и его «эвакуируют».
Интересно, что у них там разрабатывают (или, теперь уже «разрабатывали»)?
Глючит всё: препроцессор-компилятор-линкер (весь toolchain по сути), дебаггер, среда, отладочный модуль, библиотеки, RTOS. Компилятор производит огромный image даже на максимальной оптимизации (на которой он глючит ещё больше). Ассемблер не документирован, архитектура не документирована, использование периферии — только через библиотеки, предоставляемые FTDI (исходники закрыты) — причём библиотеки очень неудобные и убогие местами. По сути, засекретили всё, что можно и нельзя — и это сильно усложняет и без того трудную отладку этого рассадника багов.
Ошибки в компиляторе просто шокирующие. Например, криво поддерживается инициализация переменной выражением при объявлении — последующие функции используют неинициализированное значение переменной (и это при минимальной регистровой оптимизации).
Т.е. вот такой код не работает:
«address» — это зарезервированное ключевое слово языка, однако это нигде не документировано, и из сообщения об ошибке хрен поймёшь, почему нормальный код не компилируется.
Вот такой код
выдаст вам ошибку «P4001 argument mismatch», потому что запятая внутри строке интерпретируется как разделитель параметров макроса.
А, например, вернёт вам «5», потому что backspace считается за часть строки.
Если вы включаете прямо или косвенно больше 70-ти #include-ов в свой модуль — выдаётся "#include nested too deep" — даже если никакого «nested» нет и в помине — специально для теста включал пустые заголовки последовательно. Т.е. тупо вместо уровня вложенности считают общее количество вложений. Это накладывает серьёзные ограничения на организацию программы.
И таких глюков — просто пруд пруди. И это в последней верссии компилятора, спустя 4 года выхода продукта.
Крайне не рекомендую. Сам им занимаюсь только потому, что проект (без моего участия) дошёл до стадии, когда менять процессор уже поздно.
В принципе, как тут уже заметили, любая линейная программа (да и вообще любая программа) это автомат. Просто в атоматном программировании какая-то часть переменных состояния явно выделяется и называется таковыми, и алгоритм строится вокруг текущего состояния.
Вы в обработчике события вы так или иначе проверяете переменные, которые отражают текущее состояние программы, и выполняете какие-то действия в зависимости от этого, и меняете эти переменные — переключая ваш автомат в другое состояние.
Автоматному способу организации программы очень мешают «блокирующие» функции с ожиданием внешних событий. Пока такая функция выполняется (ничего, по сути, не делая — лишь ожидая внешнего события) — вы не можете обрабатывать другие события. К сожалению, иногда приходится использовать стороннее API с такими функциями. Тогда их можно вызывать в отдельном треде, тщательно изолируя от основного треда, и посылая события по завершении блокирующей функции. Объём кода в допонительном коде нужно при этом минимизировать, чтобы снизить усилия и вероятность ошибок синхронизации/thread safety. Ещё одна хорошая причина иметь более одного потока выполнения — это если приложение выполняется на многоядерном процессоре или многопроцессорной системе, и есть желание использовать воможности параллельной обработки для вычислительно сложных задач. Но в общем случае, «threads are evil».
Я упомянул про автоматное программирование, потому что у автора основной цикл занимает секунды. Скорее всего, он ожидает внешних событий непосредственно в этом цикле — ожидает сотни миллисекунд тут и там, вместо того, чтобы запомнить состояние «ждём следующий символ» или «ждём 100 мс перед тем, как проверить состояние линии» — и освободить процессор для других задач.
Smartflower 32 will retail at £15,000 plus VAT for standard installations (порядка 1.1 млн рублей).
Ну как бы нет смысла совсем напрягать дорогих клиентов ручным вводом координат и времени.
Хотя можно, конечно, водить панелью по сторонам в поисках солнца или сделать дополнительно уголок из 3-х датчиков освещённости в перпендикулярных плоскостях для наведения. Плюсом была бы некоторая универсальность — например, работа при наличии отражённого источника излучения (например, такого). Минус — в облачный день не настроится, нужно забивать координаты вручную при развёртывании.
GPS всё же проще (точнее, GPS+датчик магнитного поля). Стоит копейки (по сравнению со стоимостью всего девайса), зато для развёртывания в любой точке земли нужно только нажать кнопку. Если не смог по GPS — тогда уже звать юзера и просить ввести координаты/время вручную.
А почему сравнивают только электричество? Отапливались они тоже электричеством? И даже «энергоэффективный»?
P.S. глянул отчёт, так и есть.
Вы удивитесь, но это развлечение по-прежнему популярно, просто теперь никто не использует для этого FPGA — давно разработаны и производятся специализированные ASIC.
Поначалу кажется, что это сложнее, чем «линейное» кодироваине, но это вопрос привычки.
Единственный вариант — если ребёнок специально выковырял и запихал два магнита с временным промежутком себе (или кому-то) в кишечник. Но это уже какие-то суициидальные (криминальные) наклонности, если есть желание, то будет и возможность, хоть какие игрушки ему давай.
Если ребёнок недостаточно разумен — то и нефиг ему такой конструктор давать.
А так можно до маразма дойти легко, и держать детей в обитой войлоком комнате — а то вдруг дитя вздумает головой об стенку стукнуться из любопытства.