#pragma clang loop vectorize(assume_safety)
мне такое очень не желательно, я часто сохраняю инвертированную матрицу поверх исходной.
Я согласен с Вами в том смысле, что можно сделать простой код, который будет хорошо компилироваться специальным компилятором (CLang 11.0.1, но не GCC10.2 например, и не msvc или icc, я до общения с Вами пребывал в уверенности, что лучшая оптимизация- в ICC- как никак, компилятор от производителя процессора! а оно вот оно че оказывается). Вполне себе оправданный подход в определенных условиях (например, когда можно ради упрощения жизни компилеру переломать базовые структуры данных- ведь на эту самую Mat3x3 завязана половина кода, ее тронь- там столько всего полезет!). Но совершенно спокойно можно прямо в родной старючей delphi xe4 (не слезая с кактуса) на старючем SSE4.2 без AVX забить всю ПСП и пережевывать данные быстрее, чем они через нее пролазят. КМК, туториалы для того и нужны, чтобы показывать разные способы решения одних и тех же задач, чтоб можно было выбирать под свои нужды. Лично для меня одной из причин залезть именно в ассемблер было то, что предыдущий опыт использования «ускоряющей» dll был полон мучительной отладки, когда какие-то данные вызвали ошибку в потрохах ДЛЛ, а дебагер не может до них докопаться. А когда залез- то оказалось, что это совсем не страшно. :-)
Я погонял на выходных код, который Вы прислали (ассемблер вставил в дельфи).
Никак не могу заставить делфи класть передаваемый аргумент в RSP. Я не доконца понял, но судя по ассемблерному коду, CLang складывает копию матрицы в стек, а потом из стека забирает их снова- на этом должен быть штраф, но какой конкретно- не могу сейчас оценить. Дельфи упорно передает через регистр адрес первого элемента матрицы, и внутри выдергивает данные напрямую из памяти. Когда я Ваш пример заставил работать с RCX- он стал вполне себе быстрый:
Пока мои выводы такие:
a. (из разряда- удивительное рядом) компилятор делфи на простых математиках неплох.
б. если из ассемблера, сгенерированного делфи, выкинуть лишние операции (он там накидвает каких-то бесполезных пересылок)- то получается еще лучше.
в. ручная оптимизация с SSE- даже на простой математике дает заметный прирост, и получается лучше, чем у компилятора.
г. СLANG- дает вполне компактный и эффективный код, но все равно может пропустить очевидные вещи (как с повторным divsd на одних и тех же данных). между CLang v5.0 и CLang v11.0.1- разница видна невооруженным взглядом.
д. CLang v11.0.1 лучше ICC- то, чего нагенерил ICC- вообще никому показывать нельзя- там 5 divpd/sd вместо 1го!
е. выровненность данных дает небольшой прирост. M3: «M3: Invert.compiler» vs Invert(packed matrix M3x3, compiler)"
Вы неявно используете массу dll из Винды, и для них тоже нет сырцов
потому-что дальний вызов. а я где-то выше написал, что просто за вызов у меня штраф, да, я использую виндовые dll- но где? что-то редкое вывести, поток запустить-остановить, раз в пол-часа- данные на диск скинуть, то есть- очень редкие операции- потрачу я по две лишних секунды раз в пять минут- и не замечу. А векторы я свои делю на матрицы- миллиарды раз во все доступные потоки- и на этих миллиардах каждая мкс задержки- накапливается вполне ощутимо.
Еще потому-что сильно не хочется завязываться на чьи-то лицензии- сейчас нас стали проверять на чистоту всего используемого.
Ну и третье- очень было интересно на личном опыте пощупать: с одной стороны, общее мнение «в интернете»- что компиляторы стали такие умные, что оптимизируют лучше любого программиста, а с другой стороны- периодически выходят скромные статьи с разбором профайлингов и сказками про то, как какие-то одинокие самоучки делают умножение матриц на CUDE лучше, чем отдел разработки NVidia. На хабре было несколько примеров: умножение больших матриц, ракетный велосипед для преобразования FP64.toString.
про время- ниже написал- потратил на все- 2 недели, правда, до этого опыта в ассемблере было около нуля, поэтому кодил параллельно с чтением мануалов и описания архитектуры.
про читабельность на Си- я смотрел всякие портянки из интринсиков- честно- не вижу я там читабельности ни в одном месте.
Поскольку это ваша задача, то давайте вы напишете тестовую программу на Дельфи, а я к ней прикручу сишный вызов. Вам виднее, какие матрицы должны быть, какие примеры данных. Это и как приложение к статье будет полезно.
заметано. за выходные выложу сюда линк на гитхаб для игрища.
чистого времени на все SSE было потрачено около двух недель- это порядка 70-ти различных функций. Но большая часть из них очень похожа (типа, a.i += b.ij*cj and a.i += b.ij*c.j*k)- они копипастились с минимальными правками, и основная возня была именно с матрицей 4*4. Корректность расчетов покрыта unit-тестами, идентичность результатов с fpu- 50/50, где-то побитовая точность, где-то- в пределах погрешности округления, ибо перемена порядка действий влияет на последние знаки результата.
Про подкапотное пространство не скажу- на работе лицензия XE4, там все грустно, llvm еще даже в проектах не было, и современный FPC дает существенно более быстрый код. Что щас в Берлине- не смотрел, на ноуте он стоит, но чисто символически- как запасной аэродром, тестить на нем производительность даже не пробовал (N4200 не для расчетов никак).
библиотеки-то как раз нашлись, сырцов не нашлось.
Предлагать перейти на компиляторы Си- это, простите, моветон, во-первых- это очевидная мысль, а во-вторых- можно, но переписывать проект ради оптимизации десятка-другого мелких функций, когда результат- не гарантирован- плохая затея. Что до M4x4- так тут вообще ситуация патовая- не разложив элементы по регистрам лично я вообще не догадывался, что обращение можно делать не вылезая за пределы исходной матрицы- а без этого- никакая векторизация компилятором не поможет, потому что он отлично векторизует отвратительный алгоритм- с посредственным итоговым результатом.
Они могут генерировать эффективный ассемблер (в т.ч. с векторизацией) даже из самого примитивного кода безо всяких зачатков оптимизации
так в этом-то и соль- примитивный код можно эффективно оптимизировать и векторизовать, но код не всегда примитивный- не зря же Intel придумала свои интринсики software.intel.com/sites/landingpage/IntrinsicsGuide/#
А в случае с обращением матрицы- я в принципе не могу родить код (ни на С, ни на Fortran, ни на Pascal), который можно упаковать в одни регистры- хоть как там будет компилятор оптимизировать его- у меня даже мысли не возникало кидать элементы результата вместо получившихся нулей под диагональю исходной матрицы, чтобы не лезть в стек и минимизировать операции.
Если хотите, можем сравнить реальную скорость
хочу. меня интересует скорость обращения массива из 1млн матриц 4*4*FP64 в 1 поток на 1 ядре Ryzen3900 или любого близкого конкурента- используйте любой компилятор, любой алгоритм обращения, любой язык.
ассемблерный код с gcc.godbolt.org/z/8c4b1G я пока тестирую, и че-то я удивлен- он у меня выдает 490МБ/с, в то время как прямой дельфишный- 3300.
пробежав по коду- у CLANG-а- 63 инструкции, у меня- 64 всего, (это с префетчами + 6 инструкций проверка обусловленности). Но главное- у меня только один divsd, а по Вашей ссылке- два дива, а divsd- очень медленная. просто ужасно медленная- в ней 40 тактов можно потерять как нефиг делать. ну и чтение данных- я использую movupd, а CLANG везде поставил movsd, + невыровненность данных режет скорость чтения с памяти. Вот и получается, что на таком простом коде компилятор сделал простой ассемблер, который, как Вы сказали, «с виду не плохо».
на fp32 расчет деформаций идет с точностью порядка 10-6- а это по уровню- соответствует термическим деформациям от нагрева на 2-5 градусов. если хотим рассчитывать термодеформации- то приходится сидеть на fp64.
если поддерживать сразу две версии- 32 и 64, то проще принудительно обнулять все используемое в полном объеме, но Вы правы, в данном случае это избыточная операция.
Использовать внешние редакторы ассемблера- на мой взгляд дело вкуса. но для tutorial'а- это было бы через чур. Да и для себя я в этом не вижу смысла- IDE, редактор и дебагер меня вполне устраивают.
за инструкцию машина может поменьше- только 2 элемента.
на карте хорошо гонять очень большие матрицы, когда алгоритм можно распараллелить хотя бы на сотню-другую потоков, и особенно- если еще данные из карты не надо забирать на каждом шаге, а когда загрузили, сделали чисто на карте тыщу шагов, и забрали результат.
пробовали. но матрица у меня fp64, видеокарта такое не любит, это раз, а во вторых- я в любом случае на десяти-двенадцати ядрах полностью утилизирую ПСП и еще остается- поэтому карта мне не дает ускорения, она тоже упирается в ПСП. чтобы иметь прирост с карты- мне нужно закинуть в нее пару гигов данных, долго-долго их на ней крутить, и забрать с нее потом конечный результат. а если я постоянно гоняю данные туда-сюда- то профита нет, наоборот- медленнее получается.
считать надо. Замерзающий снаружи лед расширяется (при замерзании вода расширяется!) поэтому объем кубика растет, и растет так же его внутренний объем- то есть, вода внутри кубика должна растягиваться. С другой стороны- кубик зажат в форме для льда, которая может мешать ему расширяться, создавая в нем дополнительное давление, и таким образом- сжимая еще и внутреннюю воду. Будет внутренняя вода в итоге сжиматься, или расширяться- зависит от соотношения жесткости формочки и жесткости ледяной корки (при тонком слое льда- в любом случае сначала будет сжатие, но по мере утолщения льда в какой-то момент может перейти к расширению), кроме того, попытка поднять давление внутри кубика приведет к тому, что лед начнет течь (кто морозил стальные бочки с водой на даче- знает- в центре бочки на поверхности льда вырастает шишка нехилых размеров, а бочку- рвет), течение снимет часть внутреннего давления, если оно там возникнет. В пластиковой формочке предельные давления воды- это единицы атмосфер (при больших- форма треснет), для воды 10 атмосфер давления дают сжатие на 0,5*10-3, что эквивалентно внутренней добавочной энергии в 0,25 мДж/г, дополнительный нагрев от этой энергии эквивалентен примерно 6*10-5 C. слишком малый эффект, чтобы его было хоть как-то можно заметить. если форма будет держать 100 атмосфер (почти как баллон высокого давления- у того 400), то энергия вырастет в 100 раз, и эквивалентный нагрев будет уже 6*10-2 С- что тоже слишком мало для того, чтобы быть заметным. для проявления эффекта нам надо в водичке где-то спрятать хотяб 20 Дж/г.
Я заливал горки холодной водой в -18. успевает растечься и впитаться вся в снег, и довольно долго не застывает- более часа горка оставалась сырой, но точное время не измерял- залил вечером, через час еще была мокрая, а к утру застыла полностью.
Потом к ним с мастер-классом приехал Осборн, Мпемба полез к нему с глупыми вопросами, а тот подофигев с такой заявы поставил эксперимент с нормальными химическими колбами, но сделал это аккуратно- мороженое- так мороженое- будем по 70мл лить. Как готовили? взяли холодную воду, нагрели, вмесили сахару туда с ванилью, залили в стаканчики и пихнули в морозилку? так, нагреваем, (месить не будем, для чистоты эксперимента вредно, да и не похоже на определяющий фактор), разливаем по банкам и в холодос.
ААА, наверно испарение влияет! накроем крышками! опа, эффект остался. Ну ладно, первый и последний африканский физик- эффект есть, объяснения нет, пошли публиковаться- вдруг кто подскажет, что за вуду-магию ты тут заварил, темный маг.
ну, зачем так-то. В статье сказано, что конкретно авторы статьи заметили, что изменение положения датчика в их установке- очень сильно влияет на результаты.
Но суть их критики в том, что когда они наложили на один график все опубликованные зависимости (температура воды / время )- то точки, опубликованные Мпембой с Осборном в 69м легли сильно не так, как точки других авторов. Правда, почему-то умолчали, что их собственный точки, приведенные в этой же статье- тоже очень сильно отличаются от остальных- они вообще остужали воду 2-3 часа, то есть, очень медленно, в то время как «обнаруженцы эффекта» использовали более быстрое охлаждение- в пределах часа (большинство- вообще <30-40 минут).
А теперь смотрите на их описание эксперимента:
All the samples of water were boiled, to remove some of the dissolved gases, and then left to cool for varying amounts of time so that the three samples were at different initial temperatures Ti = {21.8, 57.3, 84.7} °C, respectively. The samples were then placed on a 5 cm thick sheet of expanded polystyrene sitting inside a standard domestic chest-freezer. All three samples were placed inside the freezer at the same time in order to ensure that the samples
Все образцы были прокипячены, потом остыли до разных температур и с этими температурами одновременно были засунуты в морозилку. Судя по описанию- в разное время начали кипятить, как закипело- выключили, и когда вскипела третья порция- первые две уже были подостывшие. дождались, когда последняя порция остынет до 84С и сунули все в морозилку. Теория, предложенная в сабжевой статье как раз и говорит, что при таком способе подготовки воды ничего не будет- мыж все связи растянули изначально, и просто в разных режимах охлаждаем одинаковый кипяток!
затем все это добро поместили в морозилку и стали замораживать в обычном холодильнике в объеме по 400 мл.
Но ведь эффект-то изначально наблюдался на мороженом- то есть, на жидкости, которую брали холодной (молоко горячим не продают даже в Африке), нагревали до какой-то температуры (чтоб сахар туда вмесить и всякие вкусности) и снова замораживали в объемах по 70мл. Совершенно другой режим подготовки жидкости и другой режим охлаждения. Понятно, что Мпемба и Осборн уже не расскажут, че и как они там делали, но с других-то экспериментаторов можно было и поподробнее расспросить про условия и технологию проведения эксперимента и повторить, че они там меряли, а не придумывать свою систему, и потом доказывать, что все остальные- дураки.
Не вода, но они жидкость, эта жидкость часто встречается в быту (мы видим ее в мониторах и в экранах магнитол), и в этой жидкости процессы упорядочивания и разупорядочивания молекул занимают не наносекунды, а миллисекунды- то есть, в миллион раз дольше, а при низкой температуре- секунды-что уже вполне существенное время. Кроме того, процесс упорядочивания в них происходит довольно легко, приводит к формированию структуры, и эта структура достаточно устойчива. Поэтому мне кажется, нельзя так вот просто утверждать, что
в жидкости все процессы заканчиваются за наносекунды
Hogwarts- Свиные Бородавки, Свиные наросты, жмущие наросты. приятное место.
Harry Potter- Гарри Горшков (ясно, что не дворянин)
Griffindor — Дверь грифонов (Только не в грифоновую дверь, только не в грифоновую дверь!)
Hufflepuff — Вдох раздражения
Hanna Abbot — Анька Монашка (скромная девочка, а может и не очень)
Susan Bones — Сьюзи Кости (хотя, не такая уж она и тощая)
Понятно, что имена не переводятся, но как быть с говорящими фамилиями? Не переведешь- и здоровенный кусок смысла, идей, колорита- пропадает вообще. А так- Чанг Солнце проливает свет на сложный вопрос физики. Поэтизм же!
Температуру и давление я могу менять независимо, сам, какие захочу, такие и сделаю- это внешние условия эксперимента, свободные параметры. А вязкость- не могу- какая получится при заданных условиях- такая и будет, она если и параметр- то зависимый, именно в этом их принципиальная разница.
Расчеты! Наш фетиш- расчеты, у нас вся физика висит на тоненьком-тоненьком следе от карандаша на бумаге, который выводит формулы с расчетами (ну, последнее время все больше и больше на гигабайтах флоатов, выплюнутых числодробилкой на винт- но карандаш тоже остается). Где расчеты конвекции? они совпадают с экспериментом?
мне такое очень не желательно, я часто сохраняю инвертированную матрицу поверх исходной.
Я согласен с Вами в том смысле, что можно сделать простой код, который будет хорошо компилироваться специальным компилятором (CLang 11.0.1, но не GCC10.2 например, и не msvc или icc, я до общения с Вами пребывал в уверенности, что лучшая оптимизация- в ICC- как никак, компилятор от производителя процессора! а оно вот оно че оказывается). Вполне себе оправданный подход в определенных условиях (например, когда можно ради упрощения жизни компилеру переломать базовые структуры данных- ведь на эту самую Mat3x3 завязана половина кода, ее тронь- там столько всего полезет!). Но совершенно спокойно можно прямо в родной старючей delphi xe4 (не слезая с кактуса) на старючем SSE4.2 без AVX забить всю ПСП и пережевывать данные быстрее, чем они через нее пролазят. КМК, туториалы для того и нужны, чтобы показывать разные способы решения одних и тех же задач, чтоб можно было выбирать под свои нужды. Лично для меня одной из причин залезть именно в ассемблер было то, что предыдущий опыт использования «ускоряющей» dll был полон мучительной отладки, когда какие-то данные вызвали ошибку в потрохах ДЛЛ, а дебагер не может до них докопаться. А когда залез- то оказалось, что это совсем не страшно. :-)
github.com/RCherepanov/SSE_bench_habr
Никак не могу заставить делфи класть передаваемый аргумент в RSP. Я не доконца понял, но судя по ассемблерному коду, CLang складывает копию матрицы в стек, а потом из стека забирает их снова- на этом должен быть штраф, но какой конкретно- не могу сейчас оценить. Дельфи упорно передает через регистр адрес первого элемента матрицы, и внутри выдергивает данные напрямую из памяти. Когда я Ваш пример заставил работать с RCX- он стал вполне себе быстрый:
«M3: Invert.compiler»: CalcTime =227263 mks; throutput 3543,5 MB/s
«M3: Invert_delphi_assembler_cleared»: CalcTime =196167 mks; throutput 4105,2 MB/s
«M3: Invert_gauss»: CalcTime =240986 mks; throutput 3341,7 MB/s
«M3: T_SSE.Invert_gauss»: CalcTime =182678 mks; throutput 4408,3 MB/s
«M3: T_SSE.Invert.direct»: CalcTime =135077 mks; throutput 5961,8 MB/s
«M3: T_SSE.Invert(N)»: CalcTime =145853 mks; throutput 5521,4 MB/s
«M3: Invert(packed matrix M3x3, compiler)»: CalcTime =195586 mks; throutput 3088,1 MB/s
«M3: T_SSE.Invert_CLANG»: CalcTime =161272 mks; throutput 3745,1 MB/s
Пока мои выводы такие:
a. (из разряда- удивительное рядом) компилятор делфи на простых математиках неплох.
б. если из ассемблера, сгенерированного делфи, выкинуть лишние операции (он там накидвает каких-то бесполезных пересылок)- то получается еще лучше.
в. ручная оптимизация с SSE- даже на простой математике дает заметный прирост, и получается лучше, чем у компилятора.
г. СLANG- дает вполне компактный и эффективный код, но все равно может пропустить очевидные вещи (как с повторным divsd на одних и тех же данных). между CLang v5.0 и CLang v11.0.1- разница видна невооруженным взглядом.
д. CLang v11.0.1 лучше ICC- то, чего нагенерил ICC- вообще никому показывать нельзя- там 5 divpd/sd вместо 1го!
е. выровненность данных дает небольшой прирост. M3: «M3: Invert.compiler» vs Invert(packed matrix M3x3, compiler)"
потому-что дальний вызов. а я где-то выше написал, что просто за вызов у меня штраф, да, я использую виндовые dll- но где? что-то редкое вывести, поток запустить-остановить, раз в пол-часа- данные на диск скинуть, то есть- очень редкие операции- потрачу я по две лишних секунды раз в пять минут- и не замечу. А векторы я свои делю на матрицы- миллиарды раз во все доступные потоки- и на этих миллиардах каждая мкс задержки- накапливается вполне ощутимо.
Еще потому-что сильно не хочется завязываться на чьи-то лицензии- сейчас нас стали проверять на чистоту всего используемого.
Ну и третье- очень было интересно на личном опыте пощупать: с одной стороны, общее мнение «в интернете»- что компиляторы стали такие умные, что оптимизируют лучше любого программиста, а с другой стороны- периодически выходят скромные статьи с разбором профайлингов и сказками про то, как какие-то одинокие самоучки делают умножение матриц на CUDE лучше, чем отдел разработки NVidia. На хабре было несколько примеров: умножение больших матриц, ракетный велосипед для преобразования FP64.toString.
про время- ниже написал- потратил на все- 2 недели, правда, до этого опыта в ассемблере было около нуля, поэтому кодил параллельно с чтением мануалов и описания архитектуры.
про читабельность на Си- я смотрел всякие портянки из интринсиков- честно- не вижу я там читабельности ни в одном месте.
заметано. за выходные выложу сюда линк на гитхаб для игрища.
Про подкапотное пространство не скажу- на работе лицензия XE4, там все грустно, llvm еще даже в проектах не было, и современный FPC дает существенно более быстрый код. Что щас в Берлине- не смотрел, на ноуте он стоит, но чисто символически- как запасной аэродром, тестить на нем производительность даже не пробовал (N4200 не для расчетов никак).
Предлагать перейти на компиляторы Си- это, простите, моветон, во-первых- это очевидная мысль, а во-вторых- можно, но переписывать проект ради оптимизации десятка-другого мелких функций, когда результат- не гарантирован- плохая затея. Что до M4x4- так тут вообще ситуация патовая- не разложив элементы по регистрам лично я вообще не догадывался, что обращение можно делать не вылезая за пределы исходной матрицы- а без этого- никакая векторизация компилятором не поможет, потому что он отлично векторизует отвратительный алгоритм- с посредственным итоговым результатом.
так в этом-то и соль- примитивный код можно эффективно оптимизировать и векторизовать, но код не всегда примитивный- не зря же Intel придумала свои интринсики software.intel.com/sites/landingpage/IntrinsicsGuide/#
А в случае с обращением матрицы- я в принципе не могу родить код (ни на С, ни на Fortran, ни на Pascal), который можно упаковать в одни регистры- хоть как там будет компилятор оптимизировать его- у меня даже мысли не возникало кидать элементы результата вместо получившихся нулей под диагональю исходной матрицы, чтобы не лезть в стек и минимизировать операции.
хочу. меня интересует скорость обращения массива из 1млн матриц 4*4*FP64 в 1 поток на 1 ядре Ryzen3900 или любого близкого конкурента- используйте любой компилятор, любой алгоритм обращения, любой язык.
ассемблерный код с gcc.godbolt.org/z/8c4b1G я пока тестирую, и че-то я удивлен- он у меня выдает 490МБ/с, в то время как прямой дельфишный- 3300.
пробежав по коду- у CLANG-а- 63 инструкции, у меня- 64 всего, (это с префетчами + 6 инструкций проверка обусловленности). Но главное- у меня только один divsd, а по Вашей ссылке- два дива, а divsd- очень медленная. просто ужасно медленная- в ней 40 тактов можно потерять как нефиг делать. ну и чтение данных- я использую movupd, а CLANG везде поставил movsd, + невыровненность данных режет скорость чтения с памяти. Вот и получается, что на таком простом коде компилятор сделал простой ассемблер, который, как Вы сказали, «с виду не плохо».
Использовать внешние редакторы ассемблера- на мой взгляд дело вкуса. но для tutorial'а- это было бы через чур. Да и для себя я в этом не вижу смысла- IDE, редактор и дебагер меня вполне устраивают.
на карте хорошо гонять очень большие матрицы, когда алгоритм можно распараллелить хотя бы на сотню-другую потоков, и особенно- если еще данные из карты не надо забирать на каждом шаге, а когда загрузили, сделали чисто на карте тыщу шагов, и забрали результат.
ААА, наверно испарение влияет! накроем крышками! опа, эффект остался. Ну ладно, первый и последний африканский физик- эффект есть, объяснения нет, пошли публиковаться- вдруг кто подскажет, что за вуду-магию ты тут заварил, темный маг.
Но суть их критики в том, что когда они наложили на один график все опубликованные зависимости (температура воды / время )- то точки, опубликованные Мпембой с Осборном в 69м легли сильно не так, как точки других авторов. Правда, почему-то умолчали, что их собственный точки, приведенные в этой же статье- тоже очень сильно отличаются от остальных- они вообще остужали воду 2-3 часа, то есть, очень медленно, в то время как «обнаруженцы эффекта» использовали более быстрое охлаждение- в пределах часа (большинство- вообще <30-40 минут).
А теперь смотрите на их описание эксперимента:
All the samples of water were boiled, to remove some of the dissolved gases, and then left to cool for varying amounts of time so that the three samples were at different initial temperatures Ti = {21.8, 57.3, 84.7} °C, respectively. The samples were then placed on a 5 cm thick sheet of expanded polystyrene sitting inside a standard domestic chest-freezer. All three samples were placed inside the freezer at the same time in order to ensure that the samples
Все образцы были прокипячены, потом остыли до разных температур и с этими температурами одновременно были засунуты в морозилку. Судя по описанию- в разное время начали кипятить, как закипело- выключили, и когда вскипела третья порция- первые две уже были подостывшие. дождались, когда последняя порция остынет до 84С и сунули все в морозилку. Теория, предложенная в сабжевой статье как раз и говорит, что при таком способе подготовки воды ничего не будет- мыж все связи растянули изначально, и просто в разных режимах охлаждаем одинаковый кипяток!
затем все это добро поместили в морозилку и стали замораживать в обычном холодильнике в объеме по 400 мл.
Но ведь эффект-то изначально наблюдался на мороженом- то есть, на жидкости, которую брали холодной (молоко горячим не продают даже в Африке), нагревали до какой-то температуры (чтоб сахар туда вмесить и всякие вкусности) и снова замораживали в объемах по 70мл. Совершенно другой режим подготовки жидкости и другой режим охлаждения. Понятно, что Мпемба и Осборн уже не расскажут, че и как они там делали, но с других-то экспериментаторов можно было и поподробнее расспросить про условия и технологию проведения эксперимента и повторить, че они там меряли, а не придумывать свою систему, и потом доказывать, что все остальные- дураки.
Harry Potter- Гарри Горшков (ясно, что не дворянин)
Griffindor — Дверь грифонов (Только не в грифоновую дверь, только не в грифоновую дверь!)
Hufflepuff — Вдох раздражения
Hanna Abbot — Анька Монашка (скромная девочка, а может и не очень)
Susan Bones — Сьюзи Кости (хотя, не такая уж она и тощая)
Понятно, что имена не переводятся, но как быть с говорящими фамилиями? Не переведешь- и здоровенный кусок смысла, идей, колорита- пропадает вообще. А так- Чанг Солнце проливает свет на сложный вопрос физики. Поэтизм же!