Хабрахабр: Вторая неделя с компанией Intel / Комментарии

Хабрахабр: Вторая неделя с компанией Intel / Комментарии http://habrahabr.ru/rss/company/intel/blog/70211/ ru editor@habrahabr.ru habrahabr.ru Sat, 11 Feb 2012 21:33:21 GMT http://habrahabr.ru/ http://habrahabr.ru/i/logo.gif Хабрахабр 08.10.2009 08:50:12 vtsymbal http://habrahabr.ru/company/intel/blog/70211/#comment_2057337 http://habrahabr.ru/company/intel/blog/70211/#comment_2057337 Я думаю, что то, чем занимается компания является следствием нескольких причин: тем, что исторически корпорация производила все последние годы, ситуацией на рынке, в конце концов, размером штата сотрудников. Чтобы вырваться на рынок с конечными продуктами, необходимо быть не хуже конкурентов, причем сразу. А для этого у больших компаний, как ни странно, нет ресурсов.
Поэтому с хорошими идеями и конечной продукцией выходят маленькие компании, которые потом выкупаются монстрами вместе со штатом сотрудников.]]> Thu, 08 Oct 2009 08:50:12 GMT vtsymbal 01.10.2009 07:19:00 spycode http://habrahabr.ru/company/intel/blog/70211/#comment_2035284 http://habrahabr.ru/company/intel/blog/70211/#comment_2035284 Thu, 01 Oct 2009 07:19:00 GMT spycode 24.09.2009 13:08:30 Tagrim http://habrahabr.ru/company/intel/blog/70211/#comment_2014887 http://habrahabr.ru/company/intel/blog/70211/#comment_2014887 Thu, 24 Sep 2009 13:08:30 GMT Tagrim 24.09.2009 12:29:44 vikky13 http://habrahabr.ru/company/intel/blog/70211/#comment_2014769 http://habrahabr.ru/company/intel/blog/70211/#comment_2014769 Thu, 24 Sep 2009 12:29:44 GMT vikky13 23.09.2009 15:16:04 vtsymbal http://habrahabr.ru/company/intel/blog/70211/#comment_2011878 http://habrahabr.ru/company/intel/blog/70211/#comment_2011878 Дело в том, что принимаемый нами уровень абстракции зависит от эффективности решеия задачи на нем. Если раньше, например, кодеки и фильтры писали исключительно на ассемблере, то теперь, с хорошим оптимизирующим компилятором С/C++ в этом нет особой необходимости.
В кластерных приложениях «узким местом» производительности чаще всего является интерфейс коммуникации, а не производительность узлов, поэтому разрботчик хочет иметь в своем распоряжении все рычаги для оптимизции взаимодействия между процессами, тоесть управлять интерфейсами котрые стоят либо непосредственно над транспортным уовнем, либо близко к нему. Если же интерфейсы будут покрыты какими либо аморфными абстракциями, то ни о какой оптимизации и речи не может быть. Понятно, что кластерные приложения, это те задачи, которым не хватает производительности одного PC, поэтму в угоду возможности оптимизации в жертву приносится некоторое удобство пользования абстракциями.]]> Wed, 23 Sep 2009 15:16:04 GMT vtsymbal 23.09.2009 13:30:26 vtsymbal http://habrahabr.ru/company/intel/blog/70211/#comment_2011386 http://habrahabr.ru/company/intel/blog/70211/#comment_2011386 или же на многопроцессорные, но с более мощными одноядерными процессорами
Таких систем не бывает (по крайней мере, если речь идет об х86 архитектуре)]]> Wed, 23 Sep 2009 13:30:26 GMT vtsymbal 23.09.2009 13:25:41 Tagrim http://habrahabr.ru/company/intel/blog/70211/#comment_2011359 http://habrahabr.ru/company/intel/blog/70211/#comment_2011359 Wed, 23 Sep 2009 13:25:41 GMT Tagrim 23.09.2009 12:53:53 vtsymbal http://habrahabr.ru/company/intel/blog/70211/#comment_2011216 http://habrahabr.ru/company/intel/blog/70211/#comment_2011216 Ну т.е. Intel предлагает каждый раз изобретать свои велосипеды? ;)
Не совсем. В виде MPI Intel редлагает стандартный интерфейс. Под стандартным понимается, что он принят в индустрии «де-факто» как стандарт, и вопрос портирования состоит только в отладке спортрованного проекта. Кроме того, под «стандртным интерфейсом» кроется понятие совместимости.., с планировщиками очердей, сетевыми средами, и т.д.
Поэтому собрать свой велосипед под свои задачи из стандартных комплектующих иногда проще и дешевле, чем получить лишь красивый и бестящий звонок от модели, которая не ездит по большинству имеющихся дорог.

Однако, беда в том, что MPI слишком низкоуровневый!

В этом его приемущество. Т.е. это зависит от того, с какой стороны на этот вопрос смотреть.

Я вот не знаю как с помощью разумных временных затрат решать подобный тип задач на MPI, т.к. примитивные MPI-ные барьеры просто не предназначены для этого.

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

Любая более-менее нестандартная и нетривиальная задача на распараллеливание решается в MPI с большим треском и все трудности перекладываются на прикладных программистов…

Я слышал также мнение апологетов .Net и Java, что язык С++ плох тем, что перекладывает сложности программирования, обусловлнные архитектурой вычислительной системы, на плечи программистов. :) По-моему это просто вопрос компетенции и опыта, не более того. ]]> Wed, 23 Sep 2009 12:53:53 GMT vtsymbal 23.09.2009 10:04:21 vtsymbal http://habrahabr.ru/company/intel/blog/70211/#comment_2010455 http://habrahabr.ru/company/intel/blog/70211/#comment_2010455
Обычно так и делают. Это называется стресс-тесты.]]> Wed, 23 Sep 2009 10:04:21 GMT vtsymbal 23.09.2009 09:57:03 Terror http://habrahabr.ru/company/intel/blog/70211/#comment_2010431 http://habrahabr.ru/company/intel/blog/70211/#comment_2010431
Спасибо Вам за содержательные ответы.]]> Wed, 23 Sep 2009 09:57:03 GMT Terror 23.09.2009 09:28:42 vtsymbal http://habrahabr.ru/company/intel/blog/70211/#comment_2010269 http://habrahabr.ru/company/intel/blog/70211/#comment_2010269
В некоторых тулах (Shark) есть возможность оценить производительность с изменением размера кэша последнего уровня (LLC) процессора (при фиксированно частоте). Однако, эта оценка дается относительно определенного участка кода, что логично. Что-то пдобное используется и в экспериментальных версиях нашей PTU. Оценивать же производительность всего приложения, зная только параметры процессора — бесперспективная задача. Ибо обобщенная производительнось уредненного по больнице приложения зависит от процессора процентов на 20, а по некоторым оценкам вообще на 5. А «прочих равных условий» в смысле конфиигураций систем в жизни не бывает.]]> Wed, 23 Sep 2009 09:28:42 GMT vtsymbal 23.09.2009 09:18:38 Terror http://habrahabr.ru/company/intel/blog/70211/#comment_2010201 http://habrahabr.ru/company/intel/blog/70211/#comment_2010201
Понятно, что производительность алгоритма будет зависеть не только от тактовой частоты процессора, но и от конфигурации системы, текущей загрузки. Но тут можно делать оговорку — что результаты даются на систему с другой частотой процессора и прочих равных. ]]> Wed, 23 Sep 2009 09:18:38 GMT Terror 23.09.2009 08:34:33 vtsymbal http://habrahabr.ru/company/intel/blog/70211/#comment_2009983 http://habrahabr.ru/company/intel/blog/70211/#comment_2009983 Wed, 23 Sep 2009 08:34:33 GMT vtsymbal 23.09.2009 07:54:33 vtsymbal http://habrahabr.ru/company/intel/blog/70211/#comment_2009777 http://habrahabr.ru/company/intel/blog/70211/#comment_2009777 Wed, 23 Sep 2009 07:54:33 GMT vtsymbal 23.09.2009 07:45:58 parizene http://habrahabr.ru/company/intel/blog/70211/#comment_2009738 http://habrahabr.ru/company/intel/blog/70211/#comment_2009738 Wed, 23 Sep 2009 07:45:58 GMT parizene 23.09.2009 07:44:09 vtsymbal http://habrahabr.ru/company/intel/blog/70211/#comment_2009732 http://habrahabr.ru/company/intel/blog/70211/#comment_2009732 software.intel.com/ru-ru/articles/intel-parallel-amplifier, раздел Concurrency-анализ). Запустив Concurrency Analysis, мы получаем диаграмму масштабируемости программы вцелом на процессоре, в которм она исполнялась. Для почти идеально масштабируемого приложния ее пик находится в точке N (как дельта-функция), равной количеству ядер в системе. В реале же, диаграмма будет распределена по количеству ядер каким-либо образом, и это распределение можно, с некоторым приближеим, экстраполировать, чтобы понять, как программа будет вести себя, исполняясь в процессоре с бОльшим кол-вом ядер.
Что же касается тактовой частоты, то тут по-прежнему все просто: производительность большинства программ растет пропорционально росту тактовой частоты. Вот только значительного роста последней можете уже не ожидать :)]]> Wed, 23 Sep 2009 07:44:09 GMT vtsymbal 23.09.2009 07:37:23 izard http://habrahabr.ru/company/intel/blog/70211/#comment_2009711 http://habrahabr.ru/company/intel/blog/70211/#comment_2009711 Wed, 23 Sep 2009 07:37:23 GMT izard 23.09.2009 06:49:52 Winter_mute http://habrahabr.ru/company/intel/blog/70211/#comment_2009556 http://habrahabr.ru/company/intel/blog/70211/#comment_2009556 Wed, 23 Sep 2009 06:49:52 GMT Winter_mute 22.09.2009 21:24:22 Terror http://habrahabr.ru/company/intel/blog/70211/#comment_2008927 http://habrahabr.ru/company/intel/blog/70211/#comment_2008927
У меня есть предложение для VTune. Добавить возможность прогнозирования (разумеется примерного) времени выполнения анализируемого кода на других процессорах. Например, с другой тактовой частотой, количеством ядер и т.д. Если это, конечно, возможно и вяжется с идеологией VTune.]]> Tue, 22 Sep 2009 21:24:22 GMT Terror 22.09.2009 16:42:53 vtsymbal http://habrahabr.ru/company/intel/blog/70211/#comment_2008181 http://habrahabr.ru/company/intel/blog/70211/#comment_2008181 Tue, 22 Sep 2009 16:42:53 GMT vtsymbal 22.09.2009 16:41:32 vtsymbal http://habrahabr.ru/company/intel/blog/70211/#comment_2008175 http://habrahabr.ru/company/intel/blog/70211/#comment_2008175 При линковке с TBB run-time программист может пользоваться гораздо более широким набором функционала, который будет является надстройкой над планировщиком Microsoft, и который, например, позволит пользоваться не только дополнительными параллельными алгоритмами, но и эффективными аллокаторами.

>Что из Интеловской параллельной студии войдёт в МС студю 2010?
Если вы имеете ввиду в поставку от Microsoft, то ничего. Parallel Studio останется plug-in’ом в MSVS2010, который надо приобретать отдельно, и не у MSFT.

>Продвинутая оптимизация Интеловского компилятора хоть краем туда войдёт?
Она там окажется вместе и интеловским компилятором, который в Parallel Studio является основным компонентом в инструменте Parallel Composer
Вообще со структурой Parallel Studio можно ознакомиться в моей обзорной статье на русском языке software.intel.com/ru-ru/articles/intel-parallel-studio-parallelism-toolkit/

>Какие новые, и сейчас не известные вашим-пользователям-программистам возможности туда войдут?
Обычно такие данные предоставляются только организациям, подписавшим NDA.

>Какие планы насчёт включения массовых вычислений с помощью графических адаптеров?
Я не силен в этом вопросе. Наверное, лучше спросить об этом Вику Жислину, когда она будет вести конференцию по графическим адаптерам.
]]> Tue, 22 Sep 2009 16:41:32 GMT vtsymbal 22.09.2009 16:38:13 vtsymbal http://habrahabr.ru/company/intel/blog/70211/#comment_2008168 http://habrahabr.ru/company/intel/blog/70211/#comment_2008168 — Регистрация данных
— Снижение шума/нелинейная фильтрация
— Выделение признаков/распознавание образов
— Восстановление изображений

Каждый из этих этапов выполняется в конвейерном режиме, то есть все задачи выполняются одновременно, но над разными во времени участками данных. В зависимости от объема информации параллельность может быть как на уровне одного персонального компьютера, так и на уровне дата-центров. Внутри каждого этапа есть простор для декомпозиции задач по данным (разные участки в пространстве) и одновременной их обработки. Надо сказать, что как раз обработка 2D/3D изображений, а также обработка одномерных и многомерных сигналов, является передним форонтом, где применяются самые эффективные и новые методы распараллеливания. Благодаря близко к линейному приросту производительности от количества исполняемых потоков, такие системы наибольшим образом выигрывают от многоядерности.
]]> Tue, 22 Sep 2009 16:38:13 GMT vtsymbal 22.09.2009 16:36:01 vtsymbal http://habrahabr.ru/company/intel/blog/70211/#comment_2008164 http://habrahabr.ru/company/intel/blog/70211/#comment_2008164 Надо сказать, что что-то более высокоуровневое, чем MPI, обычно пишут сами разработчики систем. MPI, как и сокеты, RDMA, Corba, COM, etc. – это всего лишь интерфейсы, в которых есть синхронные и асинхронные сообщения. А на более высоком уровне абстракции можно реализовать каналы, приоритезацию (я точно не знаю, но врядли она на транспортном уровне в .Net), объекты сообщений, и т.д. У вас правильно было замечено, что интерфейсная среда должна предоставлять возможности балансировки нагрузки и анализа перегрузки/ошибок. Intel MPI их предоставляет. Возможно MC# намного облегчает разработку систем распределенных вычислений, предоставляя уже готовые абстракции. Однако они не так уж сложны и их можно реализовать на любых интерфейсах, вопрос только в опыте и привязанностях.
]]> Tue, 22 Sep 2009 16:36:01 GMT vtsymbal 22.09.2009 16:34:15 vtsymbal http://habrahabr.ru/company/intel/blog/70211/#comment_2008159 http://habrahabr.ru/company/intel/blog/70211/#comment_2008159 software.intel.com/en-us/articles/intel-parallel-advisor-lite/ ). Этот путь, кстати, прошел Parallel Amplifier, который был выложен на сайт новых разработок в виде проекта PTU. Он там и сейчас присутствует ( software.intel.com/en-us/articles/intel-performance-tuning-utility/ ) и продолжает развиваться, а результаты в виде конечного продукта мы у видим в HE-версиях профилировщиков.

Что касается бесплатных версий. Дело в том, что Intel (SSG) не зарабатывает продажей софта, и не ставит себе это целью, и ценообразование на инструменты оптимизации производительности носит психологический характер. В западном (преимущественно американском) рынке ПО существует стереотип: бесплатоное ПО (не путать с open source) – это неподдерживаемые программы, написанные кучкой энтузиастов, или research-проект, перспективы которого туманны, а поэтому принимать его в свой «парк инструментов» не имеет смысла. Если же производитель берет оплату за ПО, значит он и берет на себя некоторую ответственность по сопровождению, поддержке пользователей, обновению версий, расширению функционала, и т.д. Чем выше стоимость ПО, тем сильнее должны «вылизывать» пользователя, в том числе предлагая различные сервисы.

Мы находимся где-то посередине этих двух крайностей, то есть между research-проектом и дорогостоящим проприетарным софтом. Это позволяет нам, предлагая инновационные методы распараллеливания программ и анализа производительности, не концентрировать огромное количество ресурсов в суппорт-инфраструктуре (примером последнего может быть IBM). Поэтому непосредственным суппортом (first-line support) у нас занимаются не натренированные девочки-телефонистки, а инженеры-консультанты, корорые непосредственно принимают участие в разработке продуктов, например, путем участия в architecture-board или в QA-процессах. Теже инженеры и разработчики отвечают на вопросы в форумах ISN по продуктам: англоязычном ( software.intel.com/en-us/forums/ ) и русскоязычном ( software.intel.com/ru-ru/forums/ ).

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

Ну и 30 дней бесплатного пользования никто не отменял.
В этой иерархии ценообразования нет особого места для совсем бесплатных версий. Что-то там урезать в ПО, потом защищать от кракинга, чтобы потом раздавать это бесплатно, мы считаем нецелесообразным, хотябы потому, что на это необходимо тратить драгоценные человекочасы.]]> Tue, 22 Sep 2009 16:34:15 GMT vtsymbal 22.09.2009 16:04:37 vtsymbal http://habrahabr.ru/company/intel/blog/70211/#comment_2008105 http://habrahabr.ru/company/intel/blog/70211/#comment_2008105 Просто и дешево пишутся только программы, решающие никому не нужные задачи. Остальные задачи либо уже решены, либо требуют вложения ресурсов в их решение. Количество естественно ресурсов зависит от сложности, и возможности свести задачу к уже решенной.
Что же касается эффективности параллельных программ, то это зависит от математической структуры алгоритмов — есть непараллелящиеся, трудно поддающиеся распараллеливанию и соответственно легко распараллеливаемые алгоритмы. Рендеринг сам по себе — довольно хорошо поддающаяся распараллеливанию задача. ]]> Tue, 22 Sep 2009 16:04:37 GMT vtsymbal 22.09.2009 14:32:30 Tagrim http://habrahabr.ru/company/intel/blog/70211/#comment_2007871 http://habrahabr.ru/company/intel/blog/70211/#comment_2007871 Tue, 22 Sep 2009 14:32:30 GMT Tagrim 22.09.2009 13:47:12 vtsymbal http://habrahabr.ru/company/intel/blog/70211/#comment_2007711 http://habrahabr.ru/company/intel/blog/70211/#comment_2007711 В связи со всем этим процессоры поддерживают 32-битный режим, не смотря на то что они уже 64-битные по своей архитектуре. И продлится это, скорее всего, довольно долго, и в основном во имя backward compatibility.

На моем рабочем лэптопе стоит и Windows XP и Linux Fedora, в основном из-за того, что приходится бывать у клиентов с разными специализациями. Программисты, естественно, тестируют продукты на всевозможных ОС (все виды Windows, c десяток Linux-дистрибутивов, и внутри каждого по три версии, и конечно же MacOS, куда же без нее :)), так как мы разрабатываем кросс-платформенные продукты. Что иметь в качестве рабочей среды, каждый решает сам, что ему удобнее или в чем больше приходится разбираться, с тем и работает. Бухгалтерия и Human Resources работают, естественно, под Windows :)
Операционная система домашнего компьютера определяется, наверное, игрушками, в которые играется владелец :) Лично у меня домашнего нет (правда это не значит, что я играюсь на работе :))
]]> Tue, 22 Sep 2009 13:47:12 GMT vtsymbal 22.09.2009 12:19:27 vtsymbal http://habrahabr.ru/company/intel/blog/70211/#comment_2007309 http://habrahabr.ru/company/intel/blog/70211/#comment_2007309
Что касается клиентского ПО, то тут немного сложнее, хотя бы потому, что клиентского ПО очень много. Действительно, последовательные программы разрабатывать много проще, и часто производители ПО просто «не заморачиваются» с параллелизмом. Однако, если взять отдельные сегменты приложений, где скорость работы программы является ее конкурентным преимуществом, то тут дела обстоят как раз наоборот – редкая программа не использует все имеющиеся ядра. К примеру, все современные кодеки исключительно оптимизированы для выполнения в одном потоке, и вдобавок еще и распараллелены. Кому, скажем, нужен кодек H.264, если он не может загрузить работой все четыре ядра под 100%? Графические приложения тоже не отстают. Adobe, например, прилагает очень серьезные усилия для оптимизации и распараллеливания своих продуктов.
Именно для разработки клиентских приложений и предназначена Parallel Studio (обзор: software.intel.com/ru-ru/articles/intel-parallel-studio-parallelism-toolkit). В частности, для анализа эффективности и оптимизации использования всех ядер микропроцессора используется Amplifier (подробно на русском языке тут: software.intel.com/ru-ru/articles/intel-parallel-amplifier), а для отладки ошибок многопоточности и памяти – Inspector (еще одна статья на русском: software.intel.com/ru-ru/articles/intel-parallel-inspector-finding-memory-errors)

Несколько особняком здесь стоят игры. С одной стороны, польователи рассчитывают на серьезный прирост производительности в игрушках на мультиядерной платформе, а с другой, игровые движки разрабатывались довольно давно, и заточены исключительно под однопотоковое исполнение, и переделать их очень сложно из-за собенностей структуры игрового ПО – проще переписать заново. Так вот заново написанные игры и используют многопоточность на столько, на сколько это возможно.
]]> Tue, 22 Sep 2009 12:19:27 GMT vtsymbal 22.09.2009 12:12:59 vtsymbal http://habrahabr.ru/company/intel/blog/70211/#comment_2007271 http://habrahabr.ru/company/intel/blog/70211/#comment_2007271 Не раскрывая особых секретов, скажу, что мы готовим к выпуску HE (“Hi-End”) версию инструментов, которые называться будут скорее всего по-другому, и будут иметь возможности анализа .Net-приложений. Первую бета-версию пользователи предположительно увидят только в следующем году.]]> Tue, 22 Sep 2009 12:12:59 GMT vtsymbal 22.09.2009 09:52:09 orcy http://habrahabr.ru/company/intel/blog/70211/#comment_2006517 http://habrahabr.ru/company/intel/blog/70211/#comment_2006517 Tue, 22 Sep 2009 09:52:09 GMT orcy 22.09.2009 08:32:20 Yfka http://habrahabr.ru/company/intel/blog/70211/#comment_2006081 http://habrahabr.ru/company/intel/blog/70211/#comment_2006081
Расскажите об этом как можно подробнее? (Причём не как маркетологи на сайте пишут, а как программист программисту)

Вот возможные пункты: (Но это что я могу предположить, а вы то знаете особенности наверняка)
Что именно Интел туда поставляет, что и как вы помогли сделать Микрософту?

Что из Интеловской параллельной студии войдёт в МС студю 2010?

Продвинутая оптимизация Интеловского компилятора хоть краем туда войдёт?

Какие новые, и сейчас не известные вашим-пользователям-программистам возможности туда войдут?

Ну, и напоследок:
Какие планы насчёт включения массовых вычислений с помощью графических адаптеров?

Заранее, Спасибо!]]> Tue, 22 Sep 2009 08:32:20 GMT Yfka 21.09.2009 15:01:10 Winter_mute http://habrahabr.ru/company/intel/blog/70211/#comment_2004340 http://habrahabr.ru/company/intel/blog/70211/#comment_2004340 Mon, 21 Sep 2009 15:01:10 GMT Winter_mute 21.09.2009 14:52:08 Boomburum http://habrahabr.ru/company/intel/blog/70211/#comment_2004310 http://habrahabr.ru/company/intel/blog/70211/#comment_2004310 Mon, 21 Sep 2009 14:52:08 GMT Boomburum 21.09.2009 12:35:57 brainerazer http://habrahabr.ru/company/intel/blog/70211/#comment_2003833 http://habrahabr.ru/company/intel/blog/70211/#comment_2003833 Mon, 21 Sep 2009 12:35:57 GMT brainerazer 21.09.2009 10:34:17 Terror http://habrahabr.ru/company/intel/blog/70211/#comment_2003435 http://habrahabr.ru/company/intel/blog/70211/#comment_2003435
Не входит ли в планы компании Intel создание упрощенных (с урезанным функционалом), бесплатных версий, таких продуктов как VTune и Intel Parallel Studio?]]> Mon, 21 Sep 2009 10:34:17 GMT Terror 21.09.2009 10:13:03 Lucky_Student http://habrahabr.ru/company/intel/blog/70211/#comment_2003364 http://habrahabr.ru/company/intel/blog/70211/#comment_2003364 Так как вы занимаетесь (занимались) вопросами производительности, хочу задать очередной свой вопрос про будущее.
Как скоро 64-битные системы выйдут на первый план, скоро ли они вытеснят 32-битную архитектуру?
И вопрос-оффтопик. Какое у вас распределение ОС по компании (для личного использования)? Большинство использует Windows? И тот же самый вопрос касательно компьютеров для рабочего использования. Преимущественно работаете на Windows или тестируете что-то под Linux, MacOS?
]]> Mon, 21 Sep 2009 10:13:03 GMT Lucky_Student