Getting OpenMP Up To Speed
"- I understand. You're not a Computer Scientist and just
need to get your scientific research done.
- I agree this is not a good situation, but it is all about
Darwin, you know. I'm sorry, it is a tough world out there."
:):):)
пятница, 30 октября 2009 г.
Cliff Click: Where the metal meets the JVM
Where the metal meets the JVM - very-veeery long interview with Cliff Click.
"The common hardware around today which would be multi-core X86s, has a very conservative memory model. It's much more conservative than the Java memory model. So, although the Java memory model might allow a lot more interesting threads interleavings, a lot more interesting ways in which unsynchronized globals can have their data shared between threads, the X86 memory model is much more constrictive, and so you'll get a much fewer possible interleavings and some races, some data-races will therefore be hidden, some bugs will be hidden from you on an X86 platform."
"The common hardware around today which would be multi-core X86s, has a very conservative memory model. It's much more conservative than the Java memory model. So, although the Java memory model might allow a lot more interesting threads interleavings, a lot more interesting ways in which unsynchronized globals can have their data shared between threads, the X86 memory model is much more constrictive, and so you'll get a much fewer possible interleavings and some races, some data-races will therefore be hidden, some bugs will be hidden from you on an X86 platform."
четверг, 29 октября 2009 г.
Roadrunner: 129.600 cores, 1105 TFlops
Roadrunner - supercomputer from IBM, fastest in the World for today (by version of Top500.org):
- 129.600 cores
- 1.105.000 GFlops
- 129.600 cores
- 1.105.000 GFlops
Tilera Talks 100-Core Processor
Tilera Talks 100-Core Processor.
Abstract
Tilera, which already has 36- and 64-core processors on the market, is announcing its third-generation products, Tile-Gx, which includes plans for a 100-core processor. The chip will appear in 2011. Tilera officials hope the high-core count in its processors will help give the company traction in a space dominated by Intel and AMD, which currently are looking at eight-core processors.
Abstract
Tilera, which already has 36- and 64-core processors on the market, is announcing its third-generation products, Tile-Gx, which includes plans for a 100-core processor. The chip will appear in 2011. Tilera officials hope the high-core count in its processors will help give the company traction in a space dominated by Intel and AMD, which currently are looking at eight-core processors.
вторник, 27 октября 2009 г.
Radeon HD 5900: оружие против Fermi выйдет в конце ноября
Собственно "Radeon HD 5900: оружие против Fermi выйдет в конце ноября".
Цитаты:
"Поскольку ускорители Radeon HD 5950 и HD 5970 по сути являются сдвоенными версиями Radeon HD 5850 и HD 5870, логично предположить, что в распоряжении первого имеется 2880 универсальных потоковых процессоров, в распоряжении второго - 3200."
Похоже, Radeon-ATI-AMD пока ставят на кол-во процессоров, а не на распространение среди разработчиков (как CUDA-Fermi-nVidia). Хотя OpenCL уже поддерживают.
P.S. Ощущение, что настольные системы буквально "мгновенно" проскочат 1TFlop и приблизятся к 1PetaFlop (10^15 FLoating-point OPerations per second).
P.P.S. Ведь Radeon использует CrossFire, следовательно их можно вставлять по 4 в материнку, следовательно - !!!12.800!!! потоковых ядер в системе.
Цитаты:
"Поскольку ускорители Radeon HD 5950 и HD 5970 по сути являются сдвоенными версиями Radeon HD 5850 и HD 5870, логично предположить, что в распоряжении первого имеется 2880 универсальных потоковых процессоров, в распоряжении второго - 3200."
Похоже, Radeon-ATI-AMD пока ставят на кол-во процессоров, а не на распространение среди разработчиков (как CUDA-Fermi-nVidia). Хотя OpenCL уже поддерживают.
P.S. Ощущение, что настольные системы буквально "мгновенно" проскочат 1TFlop и приблизятся к 1PetaFlop (10^15 FLoating-point OPerations per second).
P.P.S. Ведь Radeon использует CrossFire, следовательно их можно вставлять по 4 в материнку, следовательно - !!!12.800!!! потоковых ядер в системе.
воскресенье, 25 октября 2009 г.
Example: Threads ping-pongs
В категории [Example] я буду публиковать небольшие ПОЛНОСТЬЮ ЗАКОНЧЕННЫЕ многопоточные приложения. Я их буду публиковать с импортами, так что их достаточно просто ввести в одно окно IDE и запустить. По причине "одного окна" один из классов будет public, остальные с default областью видимости. Естественно, если Вы каждый класс будете хранить в отдельном файле (не в "одном окне"), то можете все классы делать public.
Сегодняшний пример - два потока перебрасывающиеся объектом.
----------
Сегодняшний пример - два потока перебрасывающиеся объектом.
----------
Guava-libraries from Google
Google опубликовала часть своих библиотек Java, которые они используют в своих проектах, guava-libraries – Project Hosting on Google Code.
Там мало, всего четыре пакета:
Там мало, всего четыре пакета:
- com.google.common.base
- com.google.common.primitives
- com.google.common.io
- com.google.common.util.concurrent
пятница, 23 октября 2009 г.
Link: What Every Programmer Should Know About Memory (114 pages)
В ссылке на PDF из поста JAOO: The Concurrency Revolution: The Hardware Story в конце документа Brian Goetz рекомендует два источника.
Вот ссылка на один из них - What Every Programmer Should Know About Memory (114 pages).
Abstract
As CPU cores become both faster and more numerous, the limiting factor for most programs is now, and will be for some time, memory access. Hardware designers have come up with ever more sophisticated memory handling and acceleration techniques–such as CPU caches–but these cannot work optimally without some help from the programmer. Unfortunately, neither the structure nor the cost of using the memory subsystem of a computer or the caches on CPUs is well understood by most programmers. This paper explains the structure of memory subsystems in use on modern commodity hardware, illustrating why CPU caches were developed, how they work, and what programs should do to achieve optimal performance by utilizing them.
Вот ссылка на один из них - What Every Programmer Should Know About Memory (114 pages).
Abstract
As CPU cores become both faster and more numerous, the limiting factor for most programs is now, and will be for some time, memory access. Hardware designers have come up with ever more sophisticated memory handling and acceleration techniques–such as CPU caches–but these cannot work optimally without some help from the programmer. Unfortunately, neither the structure nor the cost of using the memory subsystem of a computer or the caches on CPUs is well understood by most programmers. This paper explains the structure of memory subsystems in use on modern commodity hardware, illustrating why CPU caches were developed, how they work, and what programs should do to achieve optimal performance by utilizing them.
JMM "casuality loops" VS софисты :)
В работах по JMM (например в этой) интенсивно используется понятие "casuality loop" (циклы причинности), мне это непроизвольно напоминает софизм Еватла :)
"У древнегреческого софиста Протагора учился софистике и в том числе судебному красноречию некий Эватл (Еватл, Эвафл; др.-греч. Εὔαθλος). По заключенному между ними договору Эватл должен был заплатить за обучение 10 тысяч драхм только в том случае, если выиграет свой первый судебный процесс. В случае проигрыша первого судебного дела он вообще не был обязан платить.
Однако, закончив обучение, Эватл не стал участвовать в судебных тяжбах. Как следствие, он считал себя свободным от уплаты за учебу. Это длилось довольно долго, терпение Протагора иссякло, и он сам подал на своего ученика в суд. Таким образом, должен был состояться первый судебный процесс Эватла.
Протагор привёл следующую аргументацию: «Каким бы ни было решение суда, Эватл должен будет заплатить. Он либо выиграет свой первый процесс, либо проиграет. Если выиграет, то заплатит по договору, если проиграет, заплатит по решению суда».
Эватл возражал: «Ни в том, ни в другом случае я не должен платить. Если я выиграю, то я не должен платить по решению суда, если проиграю, то по договору»."
"У древнегреческого софиста Протагора учился софистике и в том числе судебному красноречию некий Эватл (Еватл, Эвафл; др.-греч. Εὔαθλος). По заключенному между ними договору Эватл должен был заплатить за обучение 10 тысяч драхм только в том случае, если выиграет свой первый судебный процесс. В случае проигрыша первого судебного дела он вообще не был обязан платить.
Однако, закончив обучение, Эватл не стал участвовать в судебных тяжбах. Как следствие, он считал себя свободным от уплаты за учебу. Это длилось довольно долго, терпение Протагора иссякло, и он сам подал на своего ученика в суд. Таким образом, должен был состояться первый судебный процесс Эватла.
Протагор привёл следующую аргументацию: «Каким бы ни было решение суда, Эватл должен будет заплатить. Он либо выиграет свой первый процесс, либо проиграет. Если выиграет, то заплатит по договору, если проиграет, заплатит по решению суда».
Эватл возражал: «Ни в том, ни в другом случае я не должен платить. Если я выиграю, то я не должен платить по решению суда, если проиграю, то по договору»."
Немного о транзакциях БД и уровнях их изолированности
Здесь я повторю кратко то, что было на лекции 20.10. касательно механизма транзакций и кое-что добавлю от себя.
Транзакция (Transaction) - некоторая последовательность действий, выполняемая над объектами БД (в первую очередь над таблицами), которая рассматривается как одно целое и поэтому либо должна быть корректно завершена (Commit), либо полностью игнорирована (Rollback).
Основные требования к транзакциям сформулировал Джим Грей. Это свойства Atomicity (Атомарность), Consistency (Согласованность) и Durability (Долговечность). Позднее к ним присоединилось свойство Isolation (Изолированность), образуя четверку свойств ACID.
Транзакция (Transaction) - некоторая последовательность действий, выполняемая над объектами БД (в первую очередь над таблицами), которая рассматривается как одно целое и поэтому либо должна быть корректно завершена (Commit), либо полностью игнорирована (Rollback).
Основные требования к транзакциям сформулировал Джим Грей. Это свойства Atomicity (Атомарность), Consistency (Согласованность) и Durability (Долговечность). Позднее к ним присоединилось свойство Isolation (Изолированность), образуя четверку свойств ACID.
среда, 21 октября 2009 г.
Kharkov Concurrency Group at Twitter now!
You can read our posts at Twitter - http://twitter.com/KhCGroup
воскресенье, 18 октября 2009 г.
Пара в Пн переносится на Вт
Господа, в Понедельник пары не будет.
Предлагаю провести ее во Вторник в 17.00.
Передайте кому возможно.
Предлагаю провести ее во Вторник в 17.00.
Передайте кому возможно.
четверг, 15 октября 2009 г.
ReentrantLock vs synchronized (15 oct lecture)
Brian Goetz, "More flexible, scalable locking in JDK 5.0" (EN, RU).
- timed lock waits
- interruptible lock waits
- non-block-structured-locks
- multiple condition variables
- lock polling
- fair policy
Но учтите, это для Java 5, тут еще не ускорили synchonized (естественно - не ускорили в конктерной JVM - в Sun HotSpot JVM).
А вот для Java 6, уже ускорили synchronized (в HotSpot JVM):
Brian Goetz, "Synchronization optimization in Mustang" (EN, RU)
- lock elision (senks to escape analisys)
- lock coarsening
- adaptive spin lock (не рассказывал)
Про escape-analisys можно кратко почитать тут
Brian Goetz, "Urban performance legends, revisited" [EN, RU]
- timed lock waits
- interruptible lock waits
- non-block-structured-locks
- multiple condition variables
- lock polling
- fair policy
Но учтите, это для Java 5, тут еще не ускорили synchonized (естественно - не ускорили в конктерной JVM - в Sun HotSpot JVM).
А вот для Java 6, уже ускорили synchronized (в HotSpot JVM):
Brian Goetz, "Synchronization optimization in Mustang" (EN, RU)
- lock elision (senks to escape analisys)
- lock coarsening
- adaptive spin lock (не рассказывал)
Про escape-analisys можно кратко почитать тут
Brian Goetz, "Urban performance legends, revisited" [EN, RU]
The Java Memory Model
Вот, нашёл очень полное и детальное описание модели памяти Java (Java Memory Model, JMM) с описанием целей, которые ставились при разработке, и компромиссных решений, которые приходилось принимать:
SPECIAL POPL ISSUE: The Java Memory Model
SPECIAL POPL ISSUE: The Java Memory Model
Testing Race Conditions in Java
Can you spot the bug in the following piece of Java code?
Продолжение:
http://google-opensource.blogspot.com/2009/10/testing-race-conditions-in-java.html
/** Maintains a list of names. */
public class NameManager {
private Listnames = new ArrayList ();
/** Stores a new list of names. This method is threadsafe. */
public void setNames(ListnewNames) {
synchronized (names) {
names = new ArrayList();
for (String name : newNames) {
names.add(name);
}
}
}
Продолжение:
http://google-opensource.blogspot.com/2009/10/testing-race-conditions-in-java.html
JAOO: Data Parallel Haskell
Слайды с презентации Simon Peyton-Jones "Data Parallel Haskell" на JAOO Conference:
http://jaoo.dk/aarhus-2009/file?path=/jaoo-aarhus-2009/slides/SimonPeyton-Jones_DataParallelHaskell.pdf
http://jaoo.dk/aarhus-2009/file?path=/jaoo-aarhus-2009/slides/SimonPeyton-Jones_DataParallelHaskell.pdf
Target audience: Developers who want to know what is just "over the horizon" for parallel programming.
Abstract:
Abstract:
There are many approaches to exploiting multi-cores, but a particularly promising one is the "data-parallel" paradigm, because it combines massive parallelism (on both shared and distributed memory) with a simple, single control-flow programming model. Indeed, I think that data parallelism is the only way we will be able to exploit tens or hundreds of processors effectively.
Alas, data-parallel programming is usually restricted to "flat" data parallelism, which is good for implementers but bad for programmers. Instead, I'll describe the "nested" data parallel programming model, first developed in the 90's by Blelloch and Sabot. It is great for programmers but much harder to implement; as a result, it's virtually unknown in practice. It's really only feasible to support nested data parallelism in a purely functional language, so we are building a high-performance implementation in Haskell.
In this talk you'll learn what nested data parallelism is, why it's important, and how to use it in Haskell. Fear not: I won't assume you know any Haskell. Yet.
JAOO: The Clojure Concurrency Story
Слайды с презентации Rich Hickey "The Clojure Concurrency Story" на JAOO Conference:
http://jaoo.dk/aarhus-2009/file?path=/jaoo-aarhus-2009/slides/RichHickey_TheClojureConcurrencyStory.pdf
http://jaoo.dk/aarhus-2009/file?path=/jaoo-aarhus-2009/slides/RichHickey_TheClojureConcurrencyStory.pdf
Abstract:
All functional programming languages emphasize working with immutable data as much as possible. How can that be efficient, and what benefits does it bring? And what happens when you need state, to manage changing values over time? One method is to use mutable references with concurrency semantics, such as transactions, coupled with persistent data structures. This combination makes for easy, lock-free designs, well within the comfort zone of those used to imperative programming.
This talk discusses how immutability, state and identity are handled in the Clojure language. You'll learn details about Clojure's managed references, agents and STM.
Target audience: Developers interested in alternative approaches to concurrency.
JAOO: Actors, and the Forgotten Art of Modeling Concurrent Systems
Слайды с презентации Kresten Krab Thorup & Dave Thomas "Actors, and the Forgotten Art of Modeling Concurrent Systems" на JAOO Conference:
http://jaoo.dk/aarhus-2009/file?path=/jaoo-aarhus-2009/slides/DaveThomas_and_KrestenKrabThorup_ActorsAndTheForgottenArtOfModelingConcurrentSystems.pdf
http://jaoo.dk/aarhus-2009/file?path=/jaoo-aarhus-2009/slides/DaveThomas_and_KrestenKrabThorup_ActorsAndTheForgottenArtOfModelingConcurrentSystems.pdf
Abstract:
In current talk on programming, programming languages and concurrency (and specifically the intersection of those), much focus is on how to make programs run fast and best utilize the given hardware, multicore computers, and server farms. That is all very good, and understanding how to do that is indeed an important engineering quest. However, ...
It seems that in our haste to be fast, we have forgotten the art of modeling. Some times we need to model a system which is by its very nature concurrent, and we need to express this understanding, so that we - as human beings - can comprehend and reason about its behavior. For these cases we need to intentionally model the concurrency. When the task at hand is not just a matter of parallellizing an otherwise sequential program, but expressing the interactive behaviors of systems that handle many things concurrently.
This is nothing new. In the mid-80's up to the mid-90's there was a lot of active research and development in so-called actor languages; a class of concurrent programming languages that target this problem space. Today, actor programming is starting to be used again, especially in context of the Scala programming language.
In this talk we will review the rationales and thinking behind actor languages, provide examples of actor programming models, languages, and draw the lines up to current programming models.
JAOO: The Concurrency Revolution: The Hardware Story
Слайды с презентации Brian Goetz "The Concurrency Revolution: The Hardware Story" на JAOO Conference:
http://jaoo.dk/aarhus-2009/file?path=/jaoo-aarhus-2009/slides/BrianGoetz_TheConcurrencyRevolutionTheHardwareStory.pdf
Abstract: Everyone is saying we need a revolution in the way we approach concurrency; the availability of cheap multiprocessor systems has brought concurrency, which used to be a topic for experts only, into the foreground. How did we get here? Why are the performance-enhancing techniques that worked for twenty years no longer working, and how did this become such a problem that we have to change our programming models? In this talk, we'll dive under the hood and look at the hardware trends that have forced us to turn away from increasing sequential performance and towards multicore CPUs and chip multi-threading, and look at the implications for software design and performance analysis.
Target audience: Advanced engineers who are interested in performance management and tuning, trends in software design, or anyone who is interesting in understanding the magic under the hood.
http://jaoo.dk/aarhus-2009/file?path=/jaoo-aarhus-2009/slides/BrianGoetz_TheConcurrencyRevolutionTheHardwareStory.pdf
Abstract: Everyone is saying we need a revolution in the way we approach concurrency; the availability of cheap multiprocessor systems has brought concurrency, which used to be a topic for experts only, into the foreground. How did we get here? Why are the performance-enhancing techniques that worked for twenty years no longer working, and how did this become such a problem that we have to change our programming models? In this talk, we'll dive under the hood and look at the hardware trends that have forced us to turn away from increasing sequential performance and towards multicore CPUs and chip multi-threading, and look at the implications for software design and performance analysis.
Target audience: Advanced engineers who are interested in performance management and tuning, trends in software design, or anyone who is interesting in understanding the magic under the hood.
Классическая статья по STM.
Language Support for Lightweight transactions - одна из самых цитируемых статей по STM(Software Transactional Memory).
Если кто заинтересуется, возможно, есть смысл посмотреть и другие статьи от Tim Harris (я их не смотрел):
"Selected work:
* Tim Harris. Language constructs for transactional memory (or: transactional memory and atomic blocks are not the same thing) Invited talk, POPL, January 2009
* Martín Abadi, Tim Harris, Mojtaba Mehrara. Transactional memory with strong atomicity using off-the-shelf memory protection hardware PPoPP, February 2009
* Martín Abadi, Andrew Birrell, Tim Harris, Michael Isard. Semantics of Transactional Memory and Automatic Mutual Exclusion POPL 2008
* Tim Harris, Satnam Singh. Feedback directed implicit parallelism ICFP 2007
* Keir Fraser, Tim Harris. Concurrent programming without locks ACM TOCS, May 2007
* Miguel Castro, Manuel Costa, Tim Harris. Securing software by enforcing data-flow integrity OSDI 2006
* Tim Harris, Mark Plesko, Avraham Shinnar, David Tarditi. Optimizing Memory Transactions PLDI 2006
* Tim Harris, Simon Marlow, Simon Peyton-Jones, Maurice Herlihy. Composable memory transactions PPoPP 2005"
Если кто заинтересуется, возможно, есть смысл посмотреть и другие статьи от Tim Harris (я их не смотрел):
"Selected work:
* Tim Harris. Language constructs for transactional memory (or: transactional memory and atomic blocks are not the same thing) Invited talk, POPL, January 2009
* Martín Abadi, Tim Harris, Mojtaba Mehrara. Transactional memory with strong atomicity using off-the-shelf memory protection hardware PPoPP, February 2009
* Martín Abadi, Andrew Birrell, Tim Harris, Michael Isard. Semantics of Transactional Memory and Automatic Mutual Exclusion POPL 2008
* Tim Harris, Satnam Singh. Feedback directed implicit parallelism ICFP 2007
* Keir Fraser, Tim Harris. Concurrent programming without locks ACM TOCS, May 2007
* Miguel Castro, Manuel Costa, Tim Harris. Securing software by enforcing data-flow integrity OSDI 2006
* Tim Harris, Mark Plesko, Avraham Shinnar, David Tarditi. Optimizing Memory Transactions PLDI 2006
* Tim Harris, Simon Marlow, Simon Peyton-Jones, Maurice Herlihy. Composable memory transactions PPoPP 2005"
Challenges and Directions in Java Virtual Machines
Тут презентация с JavaONE-2008 от Dr.Cliff Click and Brian Goetz.
Рассказывают про будущее многопоточности для JVM и приложений.
Впечатление, что предстоит ОЧЕНЬ МНОГО РАБОТЫ и ВСЕ ОЧЕНЬ ЗАПУТАННО.
Вот типичные цитаты:
"We don't know what the Right Answer is yet"
"Alas, there are very few 'victories' here"
"Doesn't have yet a story for true parallelism"
Рассказывают про будущее многопоточности для JVM и приложений.
Впечатление, что предстоит ОЧЕНЬ МНОГО РАБОТЫ и ВСЕ ОЧЕНЬ ЗАПУТАННО.
Вот типичные цитаты:
"We don't know what the Right Answer is yet"
"Alas, there are very few 'victories' here"
"Doesn't have yet a story for true parallelism"
среда, 14 октября 2009 г.
Наши пацаны(Oracle+SUN) отделали соседских(IBM)!
Помните Oracle+SUN приняли вызов от IBM со 100.000 tps(transactions per second)?
Так вот! Наши пацаны их сделали!
"Конфигурация Oracle-Sun потребляла в 4 раза меньше електроэнергии, чем конфигурация IBM, работая при этом на 26% быстрее.
Тест Oracle-Sun продемонстрировал в 16 раз лучшие показатели времени отклика при проведении транзакции, чем тест IBM."
Так вот! Наши пацаны их сделали!
"Конфигурация Oracle-Sun потребляла в 4 раза меньше електроэнергии, чем конфигурация IBM, работая при этом на 26% быстрее.
Тест Oracle-Sun продемонстрировал в 16 раз лучшие показатели времени отклика при проведении транзакции, чем тест IBM."
понедельник, 12 октября 2009 г.
Уважаемые читатели - несите Благую Весть страждущим!
Господа и Дамы!
Чем большему количеству друзей Вы порекомендуете блог и чем больше у нас станет постоянных подписчиков - тем выше мы будем в рейтинге Гугла, и тем скорее мы завоюем мировое господство!
Чем большему количеству друзей Вы порекомендуете блог и чем больше у нас станет постоянных подписчиков - тем выше мы будем в рейтинге Гугла, и тем скорее мы завоюем мировое господство!
PJP: Spring (Пн, 12окт)
Рекомендую IoC-контейнер Spring.
- ключевая статья Мартина Фаулера "Inversion of Control Containers and the Dependency Injection pattern" обясняющая зачем все это.
- документация по Spring(просмотрите хотя бы *картинки, *примеры, *справа в рамочках замечания из Chapter 3. The IoC container)
P.S. Знание Cпринга - уже гарантирует работу, а понимание того КАК он работает - хорошую:)
- ключевая статья Мартина Фаулера "Inversion of Control Containers and the Dependency Injection pattern" обясняющая зачем все это.
- документация по Spring(просмотрите хотя бы *картинки, *примеры, *справа в рамочках замечания из Chapter 3. The IoC container)
P.S. Знание Cпринга - уже гарантирует работу, а понимание того КАК он работает - хорошую:)
PJP: Р.Мартин. Быстрая разработка программ (Пн, 12окт).
* принцип персональной ответственности
Для использование одной функциональноcти достаточно использования одного класса (хотя реализовываться может с использованием многих, [скажем это класс - Facade]) + у одного класса - одна функциональность (а не больше).
Для использование одной функциональноcти достаточно использования одного класса (хотя реализовываться может с использованием многих, [скажем это класс - Facade]) + у одного класса - одна функциональность (а не больше).
GPU: CPU history, GPU history
Тут в статье(26 страниц) "NVIDIA’s Fermi: The First Complete GPU Computing Architecture" очень доходчиво и внятно рассказывается про историю процессоров от начала времен до Fermi в 2009м. Написано спецом, который отличный блогер. Текст насыщенный, но при этом легкий.
GPU: Top 10 Innovations and Top 3 Next Challenges in Fermi
Тут в статье(8 страниц) "The Top 10 Innovations in the New NVIDIA Fermi Architecture, and the Top 3 Next Challenges" говорят про 10 штук которые есть в Fermi и 3 которые еще докрутят:
Top 10 Innovations in Fermi
- Real Floating Point in Quality and Performance
- Error Correcting Codes on Main Memory and Caches
- 64 bit Virtual Address Space
- Caches
- Fast Context Switching
- Unified Address Space
- Debugging Support
- Faster Atomic Instructions to Support Task Based Parallel Programming
- A Brand New Instruction Set
- Also, Fermi is Faster than G80
Top 3 Next Challenges
- The Relatively Small Size of GPU Memory
- Inability to do I/O directly to GPU Memory
- No Glueless Multisocket Hardware and Software
Top 10 Innovations in Fermi
- Real Floating Point in Quality and Performance
- Error Correcting Codes on Main Memory and Caches
- 64 bit Virtual Address Space
- Caches
- Fast Context Switching
- Unified Address Space
- Debugging Support
- Faster Atomic Instructions to Support Task Based Parallel Programming
- A Brand New Instruction Set
- Also, Fermi is Faster than G80
Top 3 Next Challenges
- The Relatively Small Size of GPU Memory
- Inability to do I/O directly to GPU Memory
- No Glueless Multisocket Hardware and Software
GPU: GT300 GPU on Fermi technology
Ситуация: NVIDIA выпускает чипы
- 2006 - GT80
- 2008 - GT200
- 2009 - GT300
---
GT300 - выпущен по архитектуре Fermi. Пока по этой архитектуре всего один чип.
Его данные:
* 3.000.000.000 транзисторов
* 512 CUDA processing cores that are organized into 16 streaming multiprocessors of 32 cores each
* The memory system can support up to 6GB of memory
* The GPU also supports the IEEE 754-2008 standard (floating point arithmetics)
---
CUDA - это buzzword от NVIDIA, она так, похоже, все свое называет
Тут статья(20 страниц) Looking Beyond Graphics. Выдержки:
- 2006 - GT80
- 2008 - GT200
- 2009 - GT300
---
GT300 - выпущен по архитектуре Fermi. Пока по этой архитектуре всего один чип.
Его данные:
* 3.000.000.000 транзисторов
* 512 CUDA processing cores that are organized into 16 streaming multiprocessors of 32 cores each
* The memory system can support up to 6GB of memory
* The GPU also supports the IEEE 754-2008 standard (floating point arithmetics)
---
CUDA - это buzzword от NVIDIA, она так, похоже, все свое называет
Тут статья(20 страниц) Looking Beyond Graphics. Выдержки:
GPU: main players, NVIDIA vs ATI.
How i can see in high performance GPU market there is two main players - NVIDIA and ATI (owned by AMD).
So in next articles i'll analize differenced between NVIDIA and ATI chips.
There is some important terms: chip, technology, graphic card, programming technology.
Thy have different meaning:
chip(GPU) == name of concrete graphics processor.
technology == tecknology of GPU, many GPUs can be done in one technology
graphic card == GPU + other chips on card
programming technology == API or libs or framework or standart for using capabilities of GPU
So in next articles i'll analize differenced between NVIDIA and ATI chips.
There is some important terms: chip, technology, graphic card, programming technology.
Thy have different meaning:
chip(GPU) == name of concrete graphics processor.
technology == tecknology of GPU, many GPUs can be done in one technology
graphic card == GPU + other chips on card
programming technology == API or libs or framework or standart for using capabilities of GPU
воскресенье, 11 октября 2009 г.
[орг. вопросы] Пн - PJP+дискуссии, Чт - многопоточка
Пока будем работать в таком режиме
Пн - PJP + дискуссии по интересующим вас вопросам (если что накопилось - спрашивайте, обсудим)
Чт - вопросы, связанные с многопоточностью/многоядерностью
P.S. Собственно PJP я читаю для того, что бы было проще анализировать, скажем, архитектуры современных серверов или больших фреймворков.
Пн - PJP + дискуссии по интересующим вас вопросам (если что накопилось - спрашивайте, обсудим)
Чт - вопросы, связанные с многопоточностью/многоядерностью
P.S. Собственно PJP я читаю для того, что бы было проще анализировать, скажем, архитектуры современных серверов или больших фреймворков.
суббота, 10 октября 2009 г.
Реклама удалена
Опыт использования рекламы показал следующее:
- показов 1100
- кликов 13
- заработано 56 евроцентов
Принято решение: для удобства наших читателей и в виду нереальности личного обогащения :) таким вот образом - реклама удалена с Блога.
- показов 1100
- кликов 13
- заработано 56 евроцентов
Принято решение: для удобства наших читателей и в виду нереальности личного обогащения :) таким вот образом - реклама удалена с Блога.
четверг, 8 октября 2009 г.
Дискуссия на RSDN: reordering volatile and non-volatile
Тут обсуждение книги вылилось в нашу с Дмитрием дискуссию о возможности/допустимости reordering volatile and non-volatile. Дмитрий дает интересные данные по C#/C++ Memory Model и интересную ссылку на еще один документ по JMM:
http://rsim.cs.illinois.edu/Pubs/popl05.pdf
P.S. Моя точка зрения там немного радикальна, просто я пляшу от того как МОЖНО программировать, а не от того как НАДО. Т.е. не смоит мои слова воспринимать как руководство к действию. Естественно, ВНЕДРЯТЬ НАМЕРЕННО в свой код data race - дурной тон.
http://rsim.cs.illinois.edu/Pubs/popl05.pdf
P.S. Моя точка зрения там немного радикальна, просто я пляшу от того как МОЖНО программировать, а не от того как НАДО. Т.е. не смоит мои слова воспринимать как руководство к действию. Естественно, ВНЕДРЯТЬ НАМЕРЕННО в свой код data race - дурной тон.
среда, 7 октября 2009 г.
[орг.вопросы] Дополнительная встреча
Мне написали 5 человек (5-й написал вчера в 22.56), анализ показал что все могут в понедельник на 17.00
комментируем.
комментируем.
вторник, 6 октября 2009 г.
Нить, которую разбудит HotSpot
Тут Санкт-Петербургская группа тестирования JVM рассказывает о том, что
- при реализации HotSpot JVM явно делалась возможность не FIFO получения доступа к монитору
- оказывается !!!можно менять политики доступа к монитору!!!
- при реализации HotSpot JVM явно делалась возможность не FIFO получения доступа к монитору
- оказывается !!!можно менять политики доступа к монитору!!!
понедельник, 5 октября 2009 г.
PJP: GRASP Patterns: Pure Fabrication
GRASP(General Responsibility Assignment Software Patterns) patterns described by Craig Larman in his book:
Applying UML and Patterns, 3ed.
Применение UML 2.0 и шаблонов проектирования
Книгу я бы не советовал читать, вода для будущих менеджеров. И паттерны там не кодирования, а распределения ролей:
Applying UML and Patterns, 3ed.
Применение UML 2.0 и шаблонов проектирования
Книгу я бы не советовал читать, вода для будущих менеджеров. И паттерны там не кодирования, а распределения ролей:
- Information Expert
- Creator
- Controller
- Low Coupling
- High Cohesion
- Polymorphism
- Pure Fabrication
- Indirection
- Protected Variations
PJP: словарь: Bean vs Entity
Bean - определяется по форме. Entity - по содержанию.
Java Bean - не путать с EJB и Web beans.
---
Bean(Java Bean): имеет свою страницу на САНе -> тут, скачать спеку можно -> тут, tutorial -> тут.
Если совсем кратко - это класс
- имеющий публичный конструктор без аргументов
- доступ к полям обеспечивается через getter/setter
Entity: класс в той или иной степени соответствующий сущности (не процессу, не роли, не ...) реального мира.
---
Пример Bean and Entity:
Java Bean - не путать с EJB и Web beans.
---
Bean(Java Bean): имеет свою страницу на САНе -> тут, скачать спеку можно -> тут, tutorial -> тут.
Если совсем кратко - это класс
- имеющий публичный конструктор без аргументов
- доступ к полям обеспечивается через getter/setter
Entity: класс в той или иной степени соответствующий сущности (не процессу, не роли, не ...) реального мира.
---
Пример Bean and Entity:
PJP: jcp.org
Абсолютное большинство стандартов Java разрабатывается сообществом JCP (jcp.org, Java Community Process) в виде JSR (Java Specification Requests).
Все JSR-ки в формате pdf можно скачать отсюда.
Пример для JSP:
JavaServer Pages 1.2 (JSR 53)
JavaServer Pages 2.1 (JSR 245)
JSR - это основной источник информации по предмету. Зачастую написаны достаточно легко. Снабжены примерами.
Все JSR-ки в формате pdf можно скачать отсюда.
Пример для JSP:
JavaServer Pages 1.2 (JSR 53)
JavaServer Pages 2.1 (JSR 245)
JSR - это основной источник информации по предмету. Зачастую написаны достаточно легко. Снабжены примерами.
PJP: Code Conventions for the Java Programming Language
Code Conventions for the Java Programming Language
Документ от САНа, соглашение о форматировании, наименовании, оформлениии кода:
- Download HTML (zip, ~62K)
- Download PDF (~127K)
Документ от САНа, соглашение о форматировании, наименовании, оформлениии кода:
- Download HTML (zip, ~62K)
- Download PDF (~127K)
Новые тематики: PJP, Matlab, GPU
Начинаем дополнительные публикации по темам PJP(Professional Java Programming), Matlab, GPU (Graphics Processing Unit)
По PJP буду писать я, Головач Иван.
По Matlab буду писать я, Головач Иван. Подключится(надеюсь) к.т.н. Колупаев Игорь Николаевич, специалист по металлофизике, бооольшой любитель Матлаба.
По GPU пока буду писать я, Головач Иван. Возможно найду спеца по этой тематике.
По PJP буду писать я, Головач Иван.
По Matlab буду писать я, Головач Иван. Подключится(надеюсь) к.т.н. Колупаев Игорь Николаевич, специалист по металлофизике, бооольшой любитель Матлаба.
По GPU пока буду писать я, Головач Иван. Возможно найду спеца по этой тематике.
воскресенье, 4 октября 2009 г.
Concurrency lessons from eBay engineers
On JavaOne Technical Sessions 2009 3 engineers from eBay speek about Java concurrency troubles/lessons that they learned.
- Lazy Initialization patern
- Holder pattern
- correct Double-Checked Locking pattern
- Interesting example: ConcurrentMap of AtomicInteger
- DateFormat, MessageDigest, CharsetEncoder/CharsetDecoder - not thread safe
- ThreadLocal pattern
- potential lock contention on Class.forName(...) when missing class
- SAXParserFactory.newInstance().newSAXParser() - potentially significant lock contention on META-INF
P.S. You MUST be resistered at Sun. Its easy.
P.P.S. And, Yes, eBay, Amazon and part of Google writed in Java:)
- Lazy Initialization patern
- Holder pattern
- correct Double-Checked Locking pattern
- Interesting example: ConcurrentMap of AtomicInteger
- DateFormat, MessageDigest, CharsetEncoder/CharsetDecoder - not thread safe
- ThreadLocal pattern
- potential lock contention on Class.forName(...) when missing class
- SAXParserFactory.newInstance().newSAXParser() - potentially significant lock contention on META-INF
P.S. You MUST be resistered at Sun. Its easy.
P.P.S. And, Yes, eBay, Amazon and part of Google writed in Java:)
Рядом со Стенфордом!!!
По запросу "concurrency group" мы вторые после Стенфорда!!!
Наше дело правое, враг будет разбит, победа будет за нами!
P.S. Ну да в запросах из Украины, знаю ...
Наше дело правое, враг будет разбит, победа будет за нами!
P.S. Ну да в запросах из Украины, знаю ...
Some Concurrency Tips
Some Concurrency Tips:
- Prefer immutable objects/data
- Hold Locks for as short a time as possible
- Prefer executors and tasks to threads
- Prefer Concurrency utilities to wait and notify
- Multithreaded Lazy Initialization is tricky
- Prefer immutable objects/data
- Hold Locks for as short a time as possible
- Prefer executors and tasks to threads
- Prefer Concurrency utilities to wait and notify
- Multithreaded Lazy Initialization is tricky
Spin-wait in HotSpot JVM
Тут Санкт-Петербургская группа тестирования JVM рассказывает про реализацию активного ожидания в Sun HotSpot JVM.
"... HotSpot тоже использует spin locks. В коде есть множество настраиваемых параметров. Перечислим эвристики, которые применяет Hotspot по умолчанию:
"... HotSpot тоже использует spin locks. В коде есть множество настраиваемых параметров. Перечислим эвристики, которые применяет Hotspot по умолчанию:
- Количество нитей, крутящихся в ожидании одной блокировки ограничено количеством процессоров (-XX:SyncKnobs=MaxSpinners=n)
- Если ожидаемая блокировка, захвачена нитью, которая сейчас не выполняется на процессоре, то крутиться не нужно (OState=0|1)
- Если блокировка поменяла хозяина, пока нить крутилась, то дальше крутиться не стоит. То же, если мы заметили освободившуюся блокировку, но ее захватили перед нашим CAS. ..."
четверг, 1 октября 2009 г.
Большой Брат следит за Дмитрием :)
3 базовых вещи относительно параллельныз вычислений - "3 базовых вещи относительно параллельных вычислений, и они же - 3 основные ошибки, которые часто допускают программисты при реализации параллельных алгоритмов. Ошибки в том плане, что они могут серьёзно снижать производительность и приводить не к ожидаемой линейной масштабируемости, а к супер-линейной деградации производительности при увеличении количества процессоров/ядер."
Подписаться на:
Сообщения (Atom)