Вы пользуетесь SQL или XPath? Теоретически, код на SQL, можно было бы заменить императивным кодом, который бы обращался к индексам базы данных, просматривал записи, итп, но в реальности никто этим практически не занимается (есть правда berkeley db, где можно все это сделать руками), тк SQL намного короче и понятней из-за близости к предметной области. Аналогичная ситуация с XPath.
Осмысленных тестов я не проводил, пробовал писать несложные примеры, и изучал как это реализовано. К тому же, написать осмысленный тест это большая работа. Вообще, понятно, что транзакционная память будет работать медленнее чем блокировки, поскольку накладные расходы намного выше. Главное преимущество тут от того, что не нужно постоянно думать о политике синхронизации, и то, что не нужно бояться того, что кто нибудь случайно сделает ошибку, и в программе появится дедлок, или рейс кондишин.
Часто транзакционную память для написания параллельных программ сравнивают со сборщиком мусора и задачей явного освобождения памяти. Основное преимущество, это упрощение разработки.
Вообще, есть такая штука как lock free data structures, про них можно начать например отсюда: en.wikipedia.org/wiki/Non-blocking_synchronization Они позволяют достичь большего, чем просто структуры с блокировками, но сложность того, как все это работает, конечно, возрастает на порядок.
Это будет зависеть от того, в каком месте программы он используется и от реализации транзакционной памяти. При простой синхронизации, через synchronized, не может быть двух параллельных чтений, что может не позволить нам на 100% использовать процессор. При синхронизации через хорошо реализованную транзакционную память, с этим все будет хорошо, тк может быть много паралельных чтений.
Все это особенности реализации бывают на уровне софта, бывает хардверная реализация памяти. Например, multiverse реализует транзакционную память при помощи инструментирования байт код, фактически все чтения/записи транзакционных полей перехватываются.
То, насколько это будет замедлять работу будет зависеть от приложения. Естественно, если есть только один поток, то стоить это будет дороже, чем если бы транзакций не было. Если есть много потоков, которые меняют один и теже данные, выигрыша особого не будет. Если же есть приложения, когда в основном потоки работают с разными объектами, иногда немного пересекаясь выигрыш будет хороший.
Вообще, для дальнейшего изучения рекомендую библиография по транзакционной памяти: www.cs.wisc.edu/trans-memory/biblio/index.html и изучение документации/исходников существующих библиотек.
В комментарии к багу написано, что существует верхний предел, после которого течь перестает. Возможно, у CMS этот предел меньше. К сожалению, мне эти опции не помогли.
Да, неплохое введение, но вот способ борьбы там, не работающий. Использование Concurrent Mark & Sweep вместо стандартного сборщика мусора на серверной виртуальной машине ситуацию не исправляет. Это я лично пробовал. Мы в MPS очень активно используем перегрузку классов. Единстевнное, что помогало это -client.
Мне кажется, ничего плохого в этом нет. На visual basic, на синтаксис которого simple похож, успешно пишут небольшие программы огромное количество не профессиональных программистов.
Нечто большое и сложное, на таком языке лучше, конечно, не писать, но простенькие мешапы в виде нативных приложений, запросто.
Да, доки это проблема. Но во первых, ситуация существенно лучше, чем год назад. Над улучшением документации мы работаем.
А во вторых, есть способы узнать, что и как работает и без доков. В этом случае можно было бы сделать вот что:
1. Открыть декларацию концепта ячейки (в editor popup).
2. Найти инстансы этого концепта.
3. Увидев инстансы, понять как эта конструкция используется.
Туториал, конечно, большой, но он позволяет получить знания, которые будут достаточны для того, что создавать языки/расширения. Еще у нас есть user's guide: www.jetbrains.net/confluence/display/MPS/MPS+User's+Guide
Ну нафига это понятно зачем, многие люди используют continous integration. Мы сами его тоже используем, но для удобства, конечно, нужна интеграция с maven/ant итп.
Рантайм MPS-а можно запустить и без MPS. В MPS 1.1, который выйдет в октябре будет ant таска, позволяющая запускать генерацию оттуда. Поддержки maven-а у нас не планируется, но вобщем-то MPS опен сорс проект, и если есть желание, то можно сделать контрибьюшин.
Почему будет сложно? Наш опыт показывает, что это не соответствует действительности. Изучить язык, соответствующий API проще, чем тот же самый API. Вы ведь не создаете новую парадигму программирования, а просто расширяете существующий язык новыми конструкциями.
Вообще, есть такая штука как lock free data structures, про них можно начать например отсюда: en.wikipedia.org/wiki/Non-blocking_synchronization Они позволяют достичь большего, чем просто структуры с блокировками, но сложность того, как все это работает, конечно, возрастает на порядок.
Я лично экспериментировал с Fortress и multiverse.
То, насколько это будет замедлять работу будет зависеть от приложения. Естественно, если есть только один поток, то стоить это будет дороже, чем если бы транзакций не было. Если есть много потоков, которые меняют один и теже данные, выигрыша особого не будет. Если же есть приложения, когда в основном потоки работают с разными объектами, иногда немного пересекаясь выигрыш будет хороший.
Вообще, для дальнейшего изучения рекомендую библиография по транзакционной памяти: www.cs.wisc.edu/trans-memory/biblio/index.html и изучение документации/исходников существующих библиотек.
Нечто большое и сложное, на таком языке лучше, конечно, не писать, но простенькие мешапы в виде нативных приложений, запросто.
А во вторых, есть способы узнать, что и как работает и без доков. В этом случае можно было бы сделать вот что:
1. Открыть декларацию концепта ячейки (в editor popup).
2. Найти инстансы этого концепта.
3. Увидев инстансы, понять как эта конструкция используется.