Рубрика «высокая производительность» - 167

Споры о том, что лучше: ручное управление или автоматическое ведутся во многих областях науки и техники. Положиться на человека или отдаться на откуп бесстрастным механизмам и алгоритмам? Похоже, что в мире создания Enterprise решений чаша весов склонилась все-таки в сторону автоматического управления памятью, большей частью из-за того, что возиться с указателями, ручным управлением памятью и закрашивать седину после каждого бага, появившегося из-за «неправильного» компилятора С/C++ не хочется сейчас уже никому. Но до сих пор возникают на форумах топики, где не сдающиеся суровые приверженцы ручного управления памятью яростно и непримиримо отстаивают свои ретроградные взгляды в борьбе с прогрессивной частью человечества. Пусть их, оставим их в покое.

Одной из наиболее часто использующихся платформ с механизмами автоматического управления памятью стала Java. Но, автоматическое управление памятью принесло не только комфорт в нелегкий труд программистов, но и свои недостатки, с которыми приходиться сталкиваться всё чаще и чаще. Современные многопользовательские приложения, способные обработать огромный поток транзакций, требуют значительных аппаратных ресурсов, размеры которых раньше было трудно даже вообразить. Однако, дело не в размерах этих ресурсов, дело в том, что сборщик мусора, существующий в большинстве современных JVM, не может работать эффективно с большими объемами памяти.
Читать полностью »

Анализ некоторых python ORM на непроизводительные расходы

Введение

При разработке приложения на python django, я столкнулся с его неадекватным торможением.
После нескольких попыток улучшить довольно сложные алгоритмы расчетов, я обратил внимание, что существенные улучшения этих алгоритмов приводили к весьма скромному результату — из чего я сделал вывод, что узкое место вовсе не в алгоритмах.

Последующий анализ показал, что действительно, основным непроизводительным потребителем ресурсов процессора оказался django ORM, который был использован для доступа к данным, необходимым при расчетах.Читать полностью »

disclaimer Так получилось, что последний месяц я разбираюсь с ZooKeeper, и у меня возникло желание систематизировать то, что я узнал, собственно пост об этом, а не о сервисе блокировок, как можно было подумать исходя из названия. Поехали!

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

От распределенного сервиса блокировок разумно требовать:

  1. работоспособность в условиях моргания сети (первое правило распределенных систем — никому не говорить о распределенных системах сеть ненадежна)
  2. отсутствие единой точки отказа

Создать подобный сервис нам поможет ZooKeeper

image В википедии написано, что ZooKeeper — распределенный сервис конфигурирования и синхронизации, не знаю как вам, но мне данное определение мало что раскрывает. Оглядываясь на свой опыт, могу дать альтернативное определение ZooKeeper, это распределенное key/value хранилище со следующими свойствами:

  • пространство ключей образует дерево (иерархию подобную файловой системе)
  • значения могут содержаться в любом узле иерархии, а не только в листьях (как если бы файлы одновременно были бы и каталогами), узел иерархии называется znode
  • между клиентом и сервером двунаправленная связь, следовательно, клиент может подписываться как изменение конкретного значения или части иерархии
  • возможно создать временную пару ключ/значение, которая существует, пока клиент её создавший подключен к кластеру
  • все данные должны помещаться в память
  • устойчивость к смерти некритического кол-ва узлов кластера

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

Современный сервер – это электронное устройство, где движущихся механических частей почти нет. Почти – потому что жесткий диск, например, ярко выделяется в этом ряду.

Flash память в дата центрах: почему она иногда дешевле жестких дисков?
Всё это в некоторых случаях можно заменить на одно компактное устройство

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

Критический взгляд со стороны на процессоры МультиклетВ последние пару недель на многих сайтах были заметки о начале производства (на азиатских заводах) отечественных процессоров Мультиклет с «прорывной архитектурой и фантастической производительностью», в том числе и на Хабре: Первая опытно-промышленная партия отечественных мультиклеточных процессоров MCp. Все эти заметки в целом рассматривали разработку с позитивной стороны, основываясь на преимуществах в изложении разработчиков. Я всегда интересовался отечественными разработками, и попробую рассказать об этом процессоре чуть более критически, и описать в меру своих возможностей суть этой новой архитектуры.

Источники информации — ограниченная документация доступная на сайте разработчика, и ответы сотрудников компании на вопросы. Читать полностью »

Критический взгляд со стороны на процессоры Мультиклет / MulticletВ последние пару недель на многих сайтах были заметки о начале производства (на азиатских заводах) отечественных процессоров Multiclet с «прорывной архитектурой и фантастической производительностью», в том числе и на Хабре: Первая опытно-промышленная партия отечественных мультиклеточных процессоров MCp. Все эти заметки в целом рассматривали разработку с позитивной стороны, основываясь на преимуществах в изложении разработчиков. Я всегда интересовался отечественными разработками, и попробую рассказать об этом процессоре чуть более критически, и описать в меру своих возможностей суть этой новой архитектуры.

Источники информации — ограниченная документация доступная на сайте разработчика, и ответы сотрудников компании на вопросы. Читать полностью »

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

Я понимаю, конечно, что Сколково, гос-корпорации, непонятное название, много псевдонаучного PR по поводу этих самых клеток и прочие негативные коннотации имеют место быть, но партия процессоров изготовлена. Их даже можно потрогать руками и посетовать на кривые ножки :) в новости на картинке не фотошоп — на сайте разработчиков и в прокремлёвской газете (не, ну мне самому стыдно, однако… против факта не попрёшь).

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

Новый лидер списка Top 500 построен в Ливерморской национальной лаборатории. Его производительность — 16,32 петафлопс, что в полтора раза больше предыдущего чемпиона — Fujitsu K c его 10,51 петафлопс. При этом он потребляет 7,9 мегаватт против 12,6 у Fujitsu. IBM Sequoia построен на архитектуре Blue Gene/Q и содержит 1,6 миллиона ядер и 1,6 петабайт памяти — по гигабайту на каждое ядро. Компьютер занимает 96 стоек. Работает он под управлением ОС Linux.

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

картинка зумается

Не знаю как обычному %читательу%, а мне практически каждый день приходиться пробегать по блогах или новостных сайтах и открывать все статьи через ссылки «читать дальше». Часто это связано с вычиткой сайта и проверкой работы авторов, а иногда и во время простого просмотра. Если такое проделывать каждый день на том же сайте, — возникает чувство потери времени.

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


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js