Показаны сообщения с ярлыком Google. Показать все сообщения
Показаны сообщения с ярлыком Google. Показать все сообщения

четверг, 7 июня 2007 г.

Ужасный Google или Непростое поглощение PeakStream

Недружественное поглощение Не так давно мы уже писали о том, что Google приобрел PeakStream, несколько заметок по этому поводу появилось и в российской web-периодике - здесь и здесь. Теперь же хочется представить вашему вниманию альтернативный взгляд на это событие от западного аналитика Эшли Ванса.




Кому нужны нефть и газ, когда есть google-ads?

Дерзкое, если не сказать эксцентричное, поглощение стратапа PeakStream компанией Google должно было напугать основных участников микропроцессорного рынка, производителей серверов и прочего железа. Google, занимающаяся прежде всего рекламой, сожрала ценную компанию, продукты которой имели потенциально большую важность для ИТ-индустрии в целом. При этом целью пожирателя было простое удовлетворение собственных потребностей и ничто иное. В результате был нанесен существенный урон, я бы даже сказал, удар по разработчикам высокотехнологичных серверных приложений, последствия которого ещё только предстоит пожинать в течение нескольких следующих лет.

Мы уверены, что такие поглощения будут продолжаться и дальше, если индустрия будет столь недальновидна. Стратап PeakStream, существующий на рынке около 2 лет, занимался разработкой инструментов, облегчающих распараллеливание однопоточных приложений на многоядерных x86 процессорах Intel и AMD, а в будущем и на GPGPU() карточках от Nvidia и AMD\ATI.

Защитники PeakStream’a и его технологий, а также технологий, которые разрабатываются сейчас пока ещё независимой компанией RapidMind, говорят об этих компаниях как об ангелах воплоти, которые уберегали программистов от жесткого ручного хардкодинга многопоточных моделей. Критики же такого подхода говорят о том, что такие технологии по сути дела являются морфием для программистов, что они реально не решают стоящих перед ИТ-сообществом проблем и что такая халява все равно долго не продержится.

Согласно нашим данным, на протяжении двух последних месяцев PeakStream вела активные переговоры о поглощении с несколькими крупными игроками ИТ-рынка. Мы не можем назвать полный перечень этих компаний, но разумно предположить, что в этот список вошли Intel, AMD, Nvidia, Sun Microsystems, IBM, HP и Microsoft. Неправда ли, именно производители ПО и микропроцессоров выглядят наиболее подходящими кандидатами на заключении такой сделки, поскольку они могли обеспечить значительную поддержку инструментам PeakStream’a и как следствие оказать благотворное влияние на индустрию в целом.

Вместо этого инженеры PeakStream’a отправились оказывать благотворное влияние на Google.

Недавно из достоверных источников нам стало изветсно, что Google не собирается заниматься распространением и продажей инструментов, разработанных PeakStream. Причина, думаю, вам понятна – основной бизнес Google сосредоточен в области рекламы и поисковых сервисов.

Вдобавок ходят слухи, что развитие GPGPU технологий не интересует Google, а ведь именно GPGPU инструментарий был изюминкой PeakStream. Вместо этого компания, съевшая талантливых параллельных программистов, собирается пустить их в оборот при разработке многопоточного кода для x86 процессоров.

Нам удалось проследить судьбу некоторых из бывших пикстримщиков, которые теперь работают в Google. Один из них также как и раньше работает над JIT’ом для многоядерных процессоров. Другой работает над компилятором для x86 платформы, а ещё один переключился на алгоритмы генерации случайных чисел с использованием GPU и CPU с упором на HPC(high performance computing) область.
Приобретение Googl’ом этих талантливых инженеров – это ещё один пример хитрого шага этой умной компании, которая все больше и больше обгоняет Yahoo! и Microsoft. Нет, ну вы можете всерьез представить, что Yahoo! или Microsoft будут приобретать компанию, наподобие PeakStream, для того чтобы улучшить свои поисковые сервисы или лежащие в их основе файловые системы. Вряд ли мы когда-либо станем свидетелями столь удивительных событий.
Вот где Google берет место для Gmail'a!
Хорошо, если говорить начистоту, то Google конечно интересует не только поиск, но и аппаратное обеспечение, что опять же является неплохой встряской для рынка железа.

К примеру, наверняка многие из вас знают, что Google является основным потребителем процессоров и жестких дисков, по этому показателю его обгоняют разве что основные производители серверов. При этом компания покупает это оборудование в первую очередь для удовлетворения собственных потребностей, а не для перепродажи, чем по сути занимаются серверо-производители. Более того, Google сама планирует начать выпуск собственных коммутаторов и прочего сетевого оборудования.

И вот теперь Google запросто покупает недешевую PeakStream как будто бы просто потому, что пикстримщики могут ей пригодиться. Такая покупка про запас. Если бы у Google было столько денег лет пять назад, то вполне возможно, что VMware стала бы просто одной из примочек к Goobuntu, к счастью этого не случилось и сейчас VMware по сути дела дефакто одна из самых применяемых на практике систем виртуализации. И кто знает, может быть в следующем году Google захочется купить Sun, чтобы заполучить нескольких талантливых Java программистов или заграбастать Red Hat, для того чтобы Linux в Google работал получше, да постабильнее.

Вообщем если нас послушать, то покупка PeakStream’a совсем не рядовое поглощение, однако с другой стороны теперь на рынке осталась всего лишь одна компания подобного профиля(single-threaded-to-multi-threaded code) - RapidMind.

Думается, что производителям серверов больше бы понравилось, если бы в этом сегменте рынка была хоть какая-нибудь конкуренция. Она, как известно, всегда способствует прогрессу, а именно этого сейчас так не хватает в нише инструментов для «упрощенного» параллельного программирования. Если бы PeakStream остался в живых, то года через два мы вполне бы могли наблюдать кучу HPC приложений, заточенных под GPGPU или многоядерные процессоры. Это позволило бы находить больше нефти и газа, создавать более безопасные автомобили, в конце концов, это сказалось бы и на наших с вами бюджетах тоже.

Вместо этого производители серверов вынуждены молиться на RapidMind, которой предстоит в одиночку решить все эти сложные проблемы, если конечно её не купит ещё какой-нибудь Google. И тогда уж точно в пору будет создавать супер-пупер машину, которая будет денно и нощно обучать программистов практике параллельного программирования.

Если же вы думаете, что все это пустой треп, то просто сохраните эту заметку и вернитесь к ней, когда вы будете платить по 10 баксов за литр бензина в 2009 году, просто потому что Exxon не смогла обнаружить новые запасы нефти. Вы припомните мои слова, когда будете болезненно хихикать, глядя на кучу бесполезных графических карточек, валяющихся без дела в углу вашего офиса.

Что ж можете и дальше наслаждаться быстрым поиском от Google, не думаю, правда, что это вам поможет.

Источник - The Register

среда, 6 июня 2007 г.

Google купил Peakstream

На днях Google заявил о поглощении компании Peakstream. Стартап Peakstream занимался разработкой инструментария для параллельного (многопоточного) программирования. Аналитики склонны расценивать этот шаг Google как ещё один стимул к продвижению параллельного программирования в мейнстрим. О деталях и целях поглощения официальные лица Google ничего не сообщают. Интересный комментарий этой новости вы можете найти в блоге Джо Лендмана, известного вам по моим прошлым постам. Примечательной также является точка зрения Адама Беберга (тех.директор Mithral Communications & Design), который считает, что главной проблемой многоядерных процессоров станет низкий спрос на них со стороны основного покупательского сектора ПК (домашние пользователи). Беберг считает, что Intel с сотоварищами будет крайне сложно убедить пользователей в полезности многоядерности.

Источник - EETimes

четверг, 31 мая 2007 г.

Google+Параллелизм: экспансия продолжается

Нужен ли параллелизм?...2 дня назад на Thinking Parallel появилась занятная статья - "How Much of the Industry Will Go Parallel?" - "Насколько параллелизм востребован IT-индустрией сегодня ?", в которой Michael Suess высказывает свои предположения по этому поводу. Нужно сказать, что Michael Suess вообще достаточно интересная личность, и с точки зрения параллельного программирования тоже ;) (особенно мне ценен его цикл интервью, ru: здесь и здесь). Дак вот Михаил считает, что параллельное программирование будет интересно прежде всего двум группам разработчиков. К первой группе относятся те, кто вечно борется с нехваткой ресурсов и производительности - это все возможные разработчики игр, систем моделирования, систем обработки сигналов и информации. Ко второй же ещё более малочисленной на сегодняшний день группе относятся разработчики, которые захотят использовать многоядерный параллелизм для придания своим приложениям большей интерактивности и других(не известных на сегодняшний день) преимуществ и фишек. Среди прочих Михаил приводит такой пример - вы ведете конференцию по ICQ\Skype, а параллельно с этим сторонняя утилита распознает некоторые ключевые слова в вашем диалоге и подыскивает информацию, которая может потенциально вас заинтересовать... скажем вы часто говорите про параллельное программирование - вот вам свежая подборка с тематических новостных сайтов и блогов, обсуждаете девушек - вот вам... ну вообще додумаете сами).


GearsИ все бы, как говориться, ничего, но вот только сегодня получаю подтверждение, что параллелизмом интересуются не только ресурсо-фобы(первая группа), но и Google. Новое приложение этой компании можно смело отнести к каркасу, который призван поддерживать вторую группу "параллельных разработчиков". Новый продукт называется Google Gears и призван помочь разработчикам в создании нового(в какой-то степени) класса приложений - offline-online application. Эти приложения работают в рамках браузера, но при этом для их работы не обязательно требуется доступ в интернет (т.е. для выполнения некоторых функций им может быть нужен доступ в сеть, но вообще они могут работать и без него). Краткое описание этой новинки от Google находиться здесь. И так, этот библиотечный каркас включает в себя:

  • Локальный сервер - используется для кэширования и обслуживания ресурсов, которые нужны приложению для работы (HTML, JavaScript, рисунки, видео и т.д.). Приложение получит доступ к ним локально, если доступ к удаленному серверу отсутствует.
  • БД - для хранения всего этого дела и прочей информации приложения
  • и самое интересное Пул процессов(worker thread pool). Концепция пула процессов далеко не нова - это некоторое хранилище процессов, которые выделяются по требованию приложения. Дак вот Google встроил такой пул в свой каркас, как раз для того чтобы упростить разработку интерактивных (т.н. насыщенных параллелизмом) приложений. Полное описание worker thread pool API находится здесь. Вкратце скажу, что процессы, которые выделяются из пула, могут взаимодействовать только через посылку сообщений. Сообщения представляют собой строки, если нужно передать не строку, требуется предварительная "сериализация". Отдельно отмечу, что в пуле хранятся не потоки операционной системы, а т.н. легковесные процессы, что в сочетании с использованием сообщений для взаимодействия таких процессов делают всю систему похожей на Erlang-овские системы.


Такие дела, да чуть не забыл, все это великолепие за лицензировано как Open Source.

пятница, 25 мая 2007 г.

Параллельное программирование. Что делать?

Параллельное программирование. Что делать?



Автор - Joseph Landman(с) | scalability.org
Перевод - Петров Александр(с)

Ранее мы уже обсуждали некоторые аспекты будущего параллельного программирования и современных тенденций в области. Грубо говоря, на сегодняшний день мы можем выделить два типа параллельных систем и инструментов их создания – системы с разделяемой (общей) памятью и системы с распределенной памятью. Наиболее известными инструментами создания таких систем являются OpenMP и MPI, соответственно. Впрочем есть и другие типы систем, и соответственно другие инструменты, но наиболее широко распространены именно эти.

Проблемы?

Используя OpenMP, вы по сути дела снабжаете свой код некоторыми пометками, которые позволяют компилятору «развернуть» эти пометки в недостающий код. Т.е., другими словами, OpenMP является макрорасширением языка (языком в языке) – компилятор выполняет автоматическое распараллеливания вашего алгоритма, руководствуясь вашими пометками (иногда это вызывает интересные проблемы - пример). Однако OpenMP предполагает, что вы программируете систему с разделяемой памятью – OpenMP не способна генерировать код, предназначенный для распределенного исполнения.

Используя MPI, вы полновластно владеете своим кодом. Вы – а не компилятор выполняете основную работу, используя библиотечные функции MPI. Компилятор не способен оптимизировать (в плане параллелизма) ваш mpi-код, поскольку это всего лишь вызовы функций. Ещё хуже, что вы по сути дела находитесь в свободном плавании и вольны выбирать тот способ решения задачи, какой вам заблагорассудиться, понятно, что этот способ вовсе не обязательно будет лучшим или вообще правильным.

Раньше я уже говорил, о том, что нам следует пересмотреть те инструменты, языки, которые мы используем для параллельного программирования. Дело не в том будет ли программист сам писать весь код или отдаст часть задач на откуп компилятору – вопрос не в предоставлении программисту большей или меньшей степени контроля над кодом, вопрос в том, что нам нужны более выразительные средства управления параллелизмом.

Я вовсе не хочу сказать, что OpenMP – это плохо. Мне нравиться OpenMP, но мы не сможем использовать OpenMP в распределенных системах (а именно за ними будущее высокопроизводительных вычислений). Я не хочу сказать, что MPI – это плохо, просто MPI – это довольно-таки низкоуровневый инструмент, используя, MPI вам приходиться явно прописывать все то, что обычно генерирует за нас сам компилятор.

MPI – это что-то вроде ассемблера в параллельном программировании. Поэтому используя его, нужно быть готовым к тому, что совсем не просто написать рабочий код, неп росто его отлаживать, не просто его оптимизировать. Большинство программ MPI-программистов дают лишь 10-15% прирост производительности при увеличении числа ядер. Очень редко эта цифра достигает 50+%. Проблема не в программистах (а вы как думали?!) – проблема в том, что при распараллелировании крайне тяжело выделить действительно продолжительные по времени исполнения куски кода.

Другой вопрос, который заинтересовал меня, когда я размышлял о файловых системах и прочих хранилищах информации – это концепция локальности. Сегодня большинство MPI программ написаны так, словно распределенное взаимодействие происходит без задержек (моделирование и учет задержек эт.вообще большая проблема как в аппаратуре, так и в софте– вот, имхо, интересный пример) Сегодня мы как бы считаем, что все узлы нашей системы расположены локально – и в этом смысле, мы не учитываем задержки внутри нашей системы (или считаем величину этих задержек одинаковой и постоянной).

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

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

Программирование масштабных многопроцессорных систем будет только усложняться с ростом их масштаба. К тому же очевидно в скором времени появиться не-SMP системы (aSMP - асимметричные многопроцессорные системы), а также системы, использующие дополнительные сопроцессоры (называемые также акселераторами или APU (accelerator processing units)). Любая из этих нелокальных систем потребует четкого представления принципов распределенного (как в пространстве, так и во времени) доступа к данным. Надеюсь мы сможем преодолеть господствующие сегодня стереотипы и найти простые способы решения этих непростых проблем.

Честно говоря, я, например, уже знаю даже название гипотетического языка, который будет работать в таких распределенных системах.

Это Фортран.

Joseph Landman(с).




Данная заметка показалась мне интересной, поскольку она более-менее отражает сегодняшние стремления параллельных программистов (нет не стремление программировать на Фортране, а необходимость создания более выразительных инструментов) в интересном свете распределенных систем.

Реальными примерами систем, о которых говорит автор, являются Googl-овская MapReduce и системы на основе идей GPGPU (General-Purpose computation on graphics processing units (GPUs)).
MapReduce - сильно распределенная система – это кластер из 1800 узлов (в каждом по 2 Intel Xeon 2GHz), между которыми распределяются данные и задания. При таком количестве узлов одной их основных проблем кластера является его отказоустойчивость – в том, смысле, что при выходе одного узла система должна перенаправить его данные и его задания другому узлу и т.д. Система называется MapReduce – поскольку модель этой системы основана на использовании двух широко распространенных в функциональном программировании функций: Map (отображение одного множества в другое путем применения функции преобразования к элементам исходного множества) и Reduce (получение агрегированной характеристики элементов множества (нпр. их суммы)).


GPGPU cистемы принадлежат к другому классу систем, которые автор, называет APU-системы. В таких системах (аппаратно-программных комплексах, по сути) центральному процессору аккомпанирует целый ряд внешних, обычно специализированных вычислителей. Это могут быть как ПЛИСы, так и микроконтроллеры или специализированные микропроцессоры (нпр. сигнальные(DSP) процессоры). Очевидно, что такие системы прямо-таки насыщены параллелизмом (вычислителей-то много) и они не являются однородными (в отличие, скажем, от сегодняшних многоядреных процессоров). Они не являются однородными поскольку в них могут использоваться различные каналы связи между элементами системы, что влечет отсутствие локальности, о которой говорит автор. В GPGPU системах, в качестве специализированного вычислителя выступает процессор видео карточки.

Google Hot Trends

Чуть больше года после запуска Google сервиса Google Trends, 22 мая компания представила вниманию общественности новый инструмент анализа общественного мнения, основных тенденций и трендов. Новый сервис называется Google Hot Trends и в некотором смысле дополняет Google Trends. Google Hot Trends анализирует поток поисковых запросов к Google Search, Google News и Google Blog Search и составляет отчет о наиболее частых\популярных запросах. Основным отличием Google Hot Trends от Google Zeitgeist будет оперативность Hot Trends. В своем блоге Google утверждает, что данные Google Hot Trends будут обновляться несколько раз в день, тогда как Google Zeitgeist («дух времени») предоставляет лишь еженедельные, ежемесячные и ежегодные отчеты. Представляется, что сочетание Google Zeitgeist и Google Hot Trends будет особо плодотворным.

Источник – Quick Online Tips

среда, 9 мая 2007 г.

Look once... and pay. PageRank on the street.

Совсем недавно узнал, что оказывается Гугл сделал всех на рынке поисковых услуг за счет такого маркетингового хода как PageRank (вообще-то это алгоритм расчета ранга(веса) web-страницы, но сказать, что успех Гугла на рынке связан с алгоритмом, у меня язык не поднимается). И вот после того, ка PageRank помог Гуглу стать мировым лидером среди поисковиков, компания решила повторить этот трюк.

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

За техническую сторону дела отвечает небольшая ИК камера, способная определить смотрит ли на неё чей-нибудь глаз или нет. (похожим образом работает "защита от красных глаз" в цифровых фотоаппаратах). Вот собственно и сама камера -

Правда на сегодняшний день камера функционирует только на расстоянии меньше метра и существенно зависит от характеристик смотрящего на неё существа. Думаю, такой штуковине не лишним будет динамик задорно призывающий посетителей посмотреть на неё.

Источник - EETimes