Правильно ли я понял, что в итоге заброшенный JIT в Zend был сделан на LLVM? (Который не очень хорошо оптимизирован для JIT сценария и добавляет большой overhead...)
Понятно, что первый пуш в апстрим идет долго первый раз (в зависимости от сообщества и его лидера, конечно, в linux-kernel это будет совсем больно, в llvm — одно удовольствие). Но никому и не обещали что это будет легко. Но это только первый раз, со временем, с ростом репутации push в upstream может стать довольно быстрым мероприятием.
Дело тут в политическом решении Если вы строите свой бизнес на наборе open-source продуктов, если вы инвестировали свою экспертизу и сильно развили эти продукты в нужном вам направлении, то вашей платой и благодарностью сообществу и авторам этих продуктов будет время потраченное на проталкивание этих наработок обратно в upstream.
Вне зависимости от того большая вы контора или маленькая, проталкивание своих наработок обратно в продукт, запуск тестовых ботов на своих железках, написание тестов, и любая другая релевантная активность, измеряемая в человеко- и машино-часах — это возврат долга за использование изначально бесплатного продукта.
А объясните мне, пожалуйста, такой простой вопрос — почему при большом количестве проектов JIT для PHP с больших компаниях ни один из них не продвигали upstream?
И почему вы сами не сделали его, раз у вас такая большая ферма серверов и большая зависимость?
И именно по этой причине в проекте DocumentDB на базе движка Cache' (первый видимый результат этого проекта вы можете увидеть уже сейчас в 2016.1 — нативная поддержка JSON в языке, о чем недавно рассказал Штефан Витман на developer community портале), именно по этому схема хранения вложенных коллекций документов будет не простая проекция на иерархический массив, а специализированная структура данных «packed vectors array». О чем мы расскажем при случае.
Да, недостатки такой схемы понятны с самого начала, т.к. аналогичных механизмов хранения документов в иерархических массивах уже было много. На предыдущей итерации похожей дискуссии был приведен интересный XML документ, который бы хотелось попытаться сохранить в предлагаемой схеме трансляции JSON (мы ведь понимаем, что XML и JSON часто эквивалентные способы сериализации иерархии объектов?) https://habrahabr.ru/company/intersystems/blog/264173/#comment_8533249
Подробно не расписывал и не подсчитывал, и думаю в предел subscript-ов не упремся, но было бы интересно посмотреть.
А немного связанный с предыдущим, но отдельный вопрос — базы данных это не только про соединение и сохранение объектов, но и про поиск. Очень важная часть Mongo API это работа с aggregation pipeline. Насколько хорошо это спроецировалось в вашей реализации? (Ну, т.е. я вижу упоминание операций, и делаю вывод, что скорее всего, это так или иначе работает, но есть вопросы) Подхватываются ли индексы при вычислении агрегатов на стороне Caché, как делается сортировка, вот это вот все? Есть замеры?
А кто-нибудь может мне объяснить причину этого наброса оригинального автора?
Я перечитал все комментарии здесь, оригинальное сообщение на pastebin («Дети, запомните, если вы хотите открыть дискуссию, никогда, никогда, это не открывайте на pastebin и gist!»), на редите, перечитал комменты на его оригинальный твит, и все равно не понимаю.
Имеем на входе такой контекст: Миод Валлат, давнишний разработчик OpenBSD (который не про новые архитектуры, и относительную популярность. про это FreeBSD, и который не про пыльные, старые, маленькие железки — про это NetBSD, а который про безопасность и правильную процедуру разработки). И он пишет что он разочаровался и уходит из OpenBSD, потому как никто уже не веселится с маргинальными железками (оставляем за скобками его опосредованный наброс на MIPS и Power, которые очень даже ок во FreeBSD). Если тебе хочется копаться со старьем — иди коммить в NetBSD. Никто слова плохого не скажет. Здесь же читается что-то другое, кроме некорректного наброса про современные архитектуры.
Мне так кажется (ни на чем не настаиваю, полностью мои спекуляции) что Миод просто устал и разочаровался в проекте OpenBSD. (Если даже денег на эксперименты с не x86/arm железками нет). Не удивлюсь увидев его в скорости в более сытном (но не намного) контексте FreeBSD…
С другой стороны, может мне кто-нибудь объяснить, а зачем вообще существует такое большое количество ответвлений BSD — FreeBSD, OpenBSD, NetBSD, Dragonfly? Почему они с такой легкостью плодят форки, и почему не умеют работать вместе? Чего они добились за это время живя по-отдельности? [Вопросы большей частью риторические]
В-целом Вы правы («Без поддержи со стороны ядра вы ни SSE, ни x86-64 использовать не можете»), но в частности — не совсем. Ядро-ядру рознь.
Например, Vmware Workstation давно (начиная с Merom) мог запускать 64-разрядные виртуалки даже на 32-разрядных операционных системах Тут основополагающим фактором наличие аппаратной поддержки vmx и x64. а не помощь Windows или Linux.
То же самое про SSE/AVX — первична поддержка определенных инструкций в железе (заявленная через cpuid). Ядро операционной системы всегда стартует с выключенной поддержкой SSE (CR4.OSFXSR=0) ибо уж больно большой state надо тогда сохранять при переключении контекста. И это проблема разработчиков приложения (например, Adobe) найти дырочку, через какую возвести нужные битики в CR4 (9-ый, 10-ый и 18-ый :)) чтобы FXSAVE/XSAVE стали сохранять состояние SSE*.
И да, чтобы два раза не вставать, Вы не правы что это Intel развел HP на предмет использования Itanium — все было ровно наоборот. Itanum — это HP дизайн, и именно поэтому это HP платит Intel чтобы поддерживать это все и дальше.
Но Вы правы, что не взлетело это (в первую очередь) из-за плохой эмуляции x86. Ну и вовторую очередь из-за плохой/неудачной архитектуры EPIC/VLIW. Для которого всегда нужен очень сильный оптимизатор, которого, почему-то в нужный момент не оказывается для нужной операционной системы.
(Сделаю обобщение еще более дерзкое — все архитектуры VLIW [very-large instruction word] типа Itanium, Transmeta, Elbrus — неэфективные и не жизнеспособные в долговременном плане. Если только у вас нет бесконечно быстрого и бесконечно широкого канала в память. Но это уже совершенно другая история и offtopic)
Хорошо, то есть какие выводы можно сделать? Архитектура с многопроцессным приложением, работающим через одну разделяемую память плохо работает в NUMA? Надо аллоцировать на каждом NUMА узле свою отдельную память с независимым набором процессов?
По поводу предела масштабирования на графике №4 — я бы на вашем месте поигрался бы с affinity (Linux — taskset, AIX — bindprocessor), заставляя планировщик не мигрировать запущенные процессы на другие сокеты. Не уверен что это что-то бы дало, но поиграться стоило.
Это сейчас выглядит как теплое с мягким, когда экосистема разбилась на файловую систему HDFS и парадигму MapReduce. А тогда в 2006 году Google именно что замещал универсальное решение, которым до этого казался mapreduce (GFS в основе, ключи-значения в SSTable как структуре данных, MapReduce как парадигма обработки массивов данных) на другое, более близкое им решение с большой таблицой, хранящей уже строки-колонки-время (в основе которой были все те же самые GFS & SSTable). Решение получалось менее низкоуровневым, и более близким к поисковому бизнесу и задачами решаемыми их фермой машин.
Вся остальная индустрия пройдет этот самый путь с большой задержкой и с другими акцентами. Это сейчас, да, есть HBase как аналог BigTable и звучит странным менять MapReduce на BigTable. Но если, перенеся это в экосистему Hadoop, прочесть это как замена более раннего Hadoop (==MapReduce) на более позднее, компонентизированное, специализированное решение, то все вроде становится логичным.
[И, кстати, Майкл про такое расщепление понятия Hadoop на подпонятия написал.]
Алексей, а Вы тоже присоединяйтесь к разработке, там еще уйма недоделанного github.com/intersystems-ru/CPM/issues, тогда и у Вас CPM будет ассоциироваться с вполне определенным пакетным менеджером. :)
Дело тут в политическом решении Если вы строите свой бизнес на наборе open-source продуктов, если вы инвестировали свою экспертизу и сильно развили эти продукты в нужном вам направлении, то вашей платой и благодарностью сообществу и авторам этих продуктов будет время потраченное на проталкивание этих наработок обратно в upstream.
Вне зависимости от того большая вы контора или маленькая, проталкивание своих наработок обратно в продукт, запуск тестовых ботов на своих железках, написание тестов, и любая другая релевантная активность, измеряемая в человеко- и машино-часах — это возврат долга за использование изначально бесплатного продукта.
Хотя, конечно, вам самим решать.
И почему вы сами не сделали его, раз у вас такая большая ферма серверов и большая зависимость?
https://habrahabr.ru/company/intersystems/blog/264173/#comment_8533249
Подробно не расписывал и не подсчитывал, и думаю в предел subscript-ов не упремся, но было бы интересно посмотреть.
Я перечитал все комментарии здесь, оригинальное сообщение на pastebin («Дети, запомните, если вы хотите открыть дискуссию, никогда, никогда, это не открывайте на pastebin и gist!»), на редите, перечитал комменты на его оригинальный твит, и все равно не понимаю.
Имеем на входе такой контекст: Миод Валлат, давнишний разработчик OpenBSD (который не про новые архитектуры, и относительную популярность. про это FreeBSD, и который не про пыльные, старые, маленькие железки — про это NetBSD, а который про безопасность и правильную процедуру разработки). И он пишет что он разочаровался и уходит из OpenBSD, потому как никто уже не веселится с маргинальными железками (оставляем за скобками его опосредованный наброс на MIPS и Power, которые очень даже ок во FreeBSD). Если тебе хочется копаться со старьем — иди коммить в NetBSD. Никто слова плохого не скажет. Здесь же читается что-то другое, кроме некорректного наброса про современные архитектуры.
Мне так кажется (ни на чем не настаиваю, полностью мои спекуляции) что Миод просто устал и разочаровался в проекте OpenBSD. (Если даже денег на эксперименты с не x86/arm железками нет). Не удивлюсь увидев его в скорости в более сытном (но не намного) контексте FreeBSD…
С другой стороны, может мне кто-нибудь объяснить, а зачем вообще существует такое большое количество ответвлений BSD — FreeBSD, OpenBSD, NetBSD, Dragonfly? Почему они с такой легкостью плодят форки, и почему не умеют работать вместе? Чего они добились за это время живя по-отдельности? [Вопросы большей частью риторические]
Например, Vmware Workstation давно (начиная с Merom) мог запускать 64-разрядные виртуалки даже на 32-разрядных операционных системах Тут основополагающим фактором наличие аппаратной поддержки vmx и x64. а не помощь Windows или Linux.
То же самое про SSE/AVX — первична поддержка определенных инструкций в железе (заявленная через cpuid). Ядро операционной системы всегда стартует с выключенной поддержкой SSE (CR4.OSFXSR=0) ибо уж больно большой state надо тогда сохранять при переключении контекста. И это проблема разработчиков приложения (например, Adobe) найти дырочку, через какую возвести нужные битики в CR4 (9-ый, 10-ый и 18-ый :)) чтобы FXSAVE/XSAVE стали сохранять состояние SSE*.
И да, чтобы два раза не вставать, Вы не правы что это Intel развел HP на предмет использования Itanium — все было ровно наоборот. Itanum — это HP дизайн, и именно поэтому это HP платит Intel чтобы поддерживать это все и дальше.
Но Вы правы, что не взлетело это (в первую очередь) из-за плохой эмуляции x86. Ну и вовторую очередь из-за плохой/неудачной архитектуры EPIC/VLIW. Для которого всегда нужен очень сильный оптимизатор, которого, почему-то в нужный момент не оказывается для нужной операционной системы.
(Сделаю обобщение еще более дерзкое — все архитектуры VLIW [very-large instruction word] типа Itanium, Transmeta, Elbrus — неэфективные и не жизнеспособные в долговременном плане. Если только у вас нет бесконечно быстрого и бесконечно широкого канала в память. Но это уже совершенно другая история и offtopic)
en.cppreference.com/w/cpp/language/string_literal
(ищите utf8 префикс)
Вся остальная индустрия пройдет этот самый путь с большой задержкой и с другими акцентами. Это сейчас, да, есть HBase как аналог BigTable и звучит странным менять MapReduce на BigTable. Но если, перенеся это в экосистему Hadoop, прочесть это как замена более раннего Hadoop (==MapReduce) на более позднее, компонентизированное, специализированное решение, то все вроде становится логичным.
[И, кстати, Майкл про такое расщепление понятия Hadoop на подпонятия написал.]