Новости информационных технологий - 26088

Постоянно падающая популярность предыдущих публикаций побуждает предпринимать поступки, помогающие популярность поддержать. Приметил – популярность первых публикаций порядочно превышает последующие; поэтому попробую перезагрузиться.

На протяжении предыдущих серий мы тщательно рассмотрели метод SVD и даже довели его до программного кода; начиная с этого текста, я буду рассматривать более общие вещи. Вещи эти, конечно, всегда будут тесно связаны с рекомендательными системами, и я буду рассказывать о том, как они в рекомендательных системах возникают, но постараюсь делать упор на более общих концепциях машинного обучения. Сегодня – об оверфиттинге и регуляризации.

Читать полностью »

Проблема с неработоспособностью HUD в MonoDevelop уходит корнями в старый баг, вызванный переходом на глобальное меню и заключавшийся в том, что менюшки у MonoDevelop не показывалось вообще никакой. Его "починили", выключив использование глобального меню как такового. Это же так просто, не фиксить проблему в своей кривой либе, а сделать чёрный список приложений.
Тяга к экономии пикселей и желание таки прикрутить HUD взяли своё. Целых два часа моего драгоценного времени, несколько костылей и всё таки завелось.

Небольшой экскурс в работу глобального меню: оно экспортируется приложением через D-Bus, а чтобы разработчики не писали дополнительный код, в Canonical наклепали хитровывернутых библиотек, берущих нормальное, человеческое меню оконного тулкита и экспортирующие его за разработчика, причём, как выяснилось, весьма криво, но об этом потом. При этом возможности вручную экспортнуть это меню нет. Точнее, есть какая-то мутная библиотечка с названием libdbusmenu и полным отсутствием хоть какой-то документации, не говоря уже о биндингах к чему-либо. Этакая проприетарщина наоборот — код открыт, но использовать его толком нельзя ввиду невозможности быстро понять, как с этим вообще работать. Таким образом реализовать в GnomePlatform.cs метод SetGlobalMenu (предусмотренный специально для систем с глобальным меню и реализованный в MacPlatform.cs) не представляется возможным, что ж, придётся разбираться с тем, почему не работает костыль с экспортилкой и придумывать свои костыли, чтобы оно заработало. Я такими извращениями не занимался со времён, когда нужно было заставить работать Навител на разнокалиберных китайских железках с изувеченной до неузнаваемости WinCE 4.2.

Читать полностью »

Проблема с неработоспособностью HUD в MonoDevelop уходит корнями в старый баг, вызванный переходом на глобальное меню и заключавшийся в том, что менюшки у MonoDevelop не показывалось вообще никакой. Его "починили", выключив использование глобального меню как такового. Это же так просто, не фиксить проблему в своей кривой либе, а сделать чёрный список приложений.
Тяга к экономии пикселей и желание таки прикрутить HUD взяли своё. Целых два часа моего драгоценного времени, несколько костылей и всё таки завелось.

Небольшой экскурс в работу глобального меню: оно экспортируется приложением через D-Bus, а чтобы разработчики не писали дополнительный код, в Canonical наклепали хитровывернутых библиотек, берущих нормальное, человеческое меню оконного тулкита и экспортирующие его за разработчика, причём, как выяснилось, весьма криво, но об этом потом. При этом возможности вручную экспортнуть это меню нет. Точнее, есть какая-то мутная библиотечка с названием libdbusmenu и полным отсутствием хоть какой-то документации, не говоря уже о биндингах к чему-либо. Этакая проприетарщина наоборот — код открыт, но использовать его толком нельзя ввиду невозможности быстро понять, как с этим вообще работать. Таким образом реализовать в GnomePlatform.cs метод SetGlobalMenu (предусмотренный специально для систем с глобальным меню) не представляется возможным, что ж, придётся разбираться с тем, почему не работает костыль с экспортилкой и придумывать свои костыли, чтобы оно заработало. Я такими извращениями не занимался со времён, когда нужно было заставить работать Навител на разнокалиберных китайских железках с изувеченной WinCE 4.2.

Читать полностью »

Мы уже смирились с тем, что рост тактовой частоты процессоров остановился и производители пошли по пути распараллеливания вычислений. Однако и число ядер типичного процессора общего назначения, быстро одолев отметки 2 и 4, остановилось в районе 8. Некоторые даже собрались хоронить закон Мура.

У такого застоя есть объективная причина. Если разница между 2, 4 или 8 ядрами скорее количественная, то уже 16-ядерный процессор сталкивается с принципиальными ограничениями традиционной архитектуры. Дело в том, что на протяжении последних нескольких десятилетий основой коммуникации между отдельными IP-блоками чипа служила шина. Пока блоков было немного, она справлялась, но когда начали плодиться ядра, эта архитектура исчерпала себя. Шина представляет собой общую среду передачи данных, к которой подключено несколько блоков процессора. В каждый момент времени один блок может передавать данные, а все остальные — получать. Если нескольким блокам нужно передавать одновременно — возникает коллизия, а значит и задержка. При числе ядер больше восьми задержки становятся неприемлемо большими, практически полностью перечёркивая преимущества параллельной работы нескольких ядер.

Число ядер можно увеличить ещё немного, разделив шину на несколько сегментов, объединённых мостами, однако это скорее «костыль», который плохо масштабируется и не решает основную проблему. Настоящее решение, которое позволит объединять сотни блоков на одном чипе — это хорошо известная всем сеть с коммутацией пакетов, или Network on Chip.
Читать полностью »