Нет, воспроизвести не удалось нигде больше (я об этом писал)... Да, скрипт есть конечно (см. статью, самый первый снипет)... можно улучшить немного, типа стоп если t больше 1650e6 ну или date из shell... Накидаю как доберусь до компьютера, мобильный хабр это боль.
И влияет исключительно на питон, причем только третий. Хмм... Ну и ASLR должно как то проявляться тогда, нет? Я имею ввиду запустив тест много раз, процессы будут стучаться по разным адресам. А результат стабильно кривой... Да и кривой только на математике в pytime и т.д.
Ну а дата в номере то для кого? Не ну я ещё могу представить как 8 стала 9... Но как явно круглая цифра в конце (9) стала 1, я не представляю... Как и то, что 10 окт. 1901 г (по юлианскому календарю среда) вдруг могло стать воскресеньем.
Гимназистом он скорее всего тоже не являлся, ибо он тогда бы (в 1901 году) врядли написал бы про себя "(Ростовский) мещанин", а гимназистом бы и назвался... В случае же учащегося (например мещанского училища) это тоже был бы тогда какой-нибудь "сын мещанина".
Курили (да и пили) они тогда почем зря, т.е. "показушной взрослостью" это можно оценивать только с колокольни современного общества. И да, в начале XX века в России не курили лишь священники да староверы какие-нибудь.
По поводу "девятого года" - с правой стороны газеты чётко видна дата:
Где довольно ясно читается "Воскресенье, 10 октября 1899 г.". Ну а 1809-м (что тоже было бы воскресеньем) это не может быть по многим причинам (да и первый номер газеты вышел 1 сентября 1891 года).
Т.е. номеру газеты полтора года... Зачем человек её столько хранил (и именно её закопал)?
Белоручка - soft-handed; Чистоплюй - squeaky-clean (в смысле помыслов, характера и т.п.), fastidious или squeamish (в смысле щепетильности, педантичности или аккуратности)... Возможно cissy подойдет (но то такое, местечковое да и сильно устаревшее). Если имелся в виду "Чистюля", то кроме Mr.Freaky-Clean или Mrs./Ms.Cleanliness ивозможно wicked hygienic ничего на ум не приходит.
Т.е. действительно никакой разницы не видим, да?..
Одно (создании токсичной среды, игнорирование жалоб и собственно домогательства) - пока какие-то лишь обвинения (сомнительные или нет, не важно), но, снова пока, ничем не подтвержденные вообще. Ну и возможно некрасивый, но притянутый за уши, "скандал" с фото с "номером Косби". Другое (собственно массовая травля) - в наличии прямо сейчас.
Меня всегда удивляют желание смешать в кучу мухи и котлеты... Как собственно и все эти игры в полит-корректность и попытки любым способом "защитить" от всего и вся многоуважаемый слабый пол, различные меньшинства и т.д., доходящие при этом до полного абсурда.
Я не про то, что проблем с харассментом нет, я про то, что пытаясь насадить весь этот спектр "новых" идеологий, тот театр абсурда иногда напоминает сошедший с рельсов паровоз, который не замечая ничего вокруг, сносит абсолютно всё на своём пути.
А потом удивительные вещи наблюдаем, как в той же Европе, где вдруг цыган и цыганами назвать нельзя... Притом, что нередко это происходит и вовсе за спинами тех "меньшинств". Вот вы где-нибудь демонстрирующих цыган видели с плакатами наперевес, что мы дескать теперь "Sinti und Roma"? Я вам больше скажу - они даже сами возмущены, почему за них, да без них решили.
И так у них во всем - соринку в глазу у всех найдем, бревно же в собственном глазу - никак нет.
Это так только в контексте презумпции невиновности, которая действует далеко не везде.
Я вам не про суд, а про общее представление о principiumdisputabilis так сказать. Да и работодатель вполне имеет право оправдывать свои действия здравым смыслом (если они не в конфликте с действующим законодательством).
Ну то есть почему в случае с обвинениями в клевете такое может быть "улажено" работодателем, а в случае с обинениями в приставаниях не может?
Хотя бы потому, что с обвинениями в приставаниях (2600 человек?!) ни один не пришел к работодателю в своё время, а на официальный ответ (с вполне обоснованными сомнениями в актуальности и правдоподобности обвинений), который вдруг не устроил сотрудников компании, они тупо начали травлю (с протестными акциями, организацией протестов на форумах и т.д.). Ну и корпоративная культура и этика должна как бы работать в обе стороны, вы не находите?
Ну да, а скажем в странах ударенных в мужской шовинизм работодатель не будет разбираться с обвинениями в сексуальных домогательствах
Ну это вот тут в каком контексте? Мы сейчас как бы о "цивилизованных" странах, и существование другой крайности где-то, вовсе не оправдывает всей этой вакханалии вокруг современного "харассмента". А то так можно много чего оправдать: ну типа где-то вообще камнями могут закидать, да... Т. е. у нас вроде и неплохо ещё всё.
Остальное комментировать большого желания нет, ибо вы как минимум передергиваете... Травля же толпой одного человека, вне зависимости от степени его "виновности", недопустима в принципе и уж точно не имеет (ни сейчас, ни 10, ни 30 лет назад) ничего общего с нормальной корпоративной этикой и здоровой общественной нравственностью и моралью.
Потому что в нормальном обществе бремя доказательства за сказанное как правило лежит на высказавшемся. Вы же вряд ли начнёте оправдываться, если кто-то вдруг вас назовет пи... нехорошим словом. В суд конечно можно и подать, но вообще то такое вполне себе может быть "улажено" и работодателем. Другое дело что, в ударенных толерастией странах, он (работодатель) на это вряд ли пойдёт, особенно находясь под давлением общества. Поэтому и имеем то, что имеем, например из недавнего - RMS и FSF, тоже кстати очень даже выглядевшее как травля.
Потому что mobbing в нормальных странах точно так же недопустим, как и те же домогательства и т.д. И да, внезапно это повод для увольнения, даже в вашей стране проживания. Я уж не говорю про такой Massen-Mobbing.
Суд и следствие по какому поводу? Для увольнения замешанных в массовой травле, клевещущих сотрудников? Вы серьёзно?
Я знаю что [Symbol.iterator] у объектов нет, просто когда (в proposal ES2018 если не ошибаюсь) речь велась про object literals, это определялось как "pass all key:value pairs from an object", что и подтверждает пример вроде:
Иначе бы такая merge конструкция не очень работала, по крайней мере с assign такое нельзя (там только два аргумента - target и source)... И я готов был поклясться, что assign не работал для неитерируемых... Что они уже после ES2018 накрутили, чтобы даже скалярный объект воспринимался как валидный, мне не очень понятно (как и для чего это собственно есть нужно и хорошо). Для меня это выглядит как жуткий баг/хак (UB на худой конец), но то такое... JS, слава богу, не мой язык - я его пользую (вынужден) только поскольку без оного в браузерах никуда (к моему большому сожалению). Во всех же других языках "Object" (aka keyed collections, dictionaries, maps или associative arrays) вполне себе iterable (или как минимум enumerable) и никакого ментального диссонанса при использовании spreading / expanding операторов не возникает, даже если по умолчанию оно за бортом и реализовано с помощью тех же assign-подобных конструкций (чтобы, производительности ради, не разворачивать списки от дефолтных "итераторов" в стек).
Посыпаю голову пеплом и выражаю глубочайшие извинения ув. @JSmitty
Только что написал в консоль {...10} и оно создало мне пустой объект... Хотя я мог бы поклясться, что уже делал такое как-то и оно вылетало с ошибкой. Возможно Object.assign переделали с той поры... или это просто старость.
Еще раз прошу прощения если кого ввел в заблуждение.
Только человек мне ниже написал, что можно вызвать spread для неитерируемого. Из чего был сделан вывод, что понимания как spread работает в принципе - нет.
Нет! Обязан (ибо он работает не так как вы себе представляете). Попробуйте передать туда неитерируемый объект, или переопределите его iterator, чтобы он выкидывал исключение. Я вас уверяю вы его (исключение) обязательно поймаете.
ПОЧТИ ВСЕ думают, что ... spread operator копирует объекты в глубину.
Ну spread operator как бы вообще ничего не копирует (ни в глубину, ни на плоскости), это тупо expand arguments сахар (разворачавающий итерируемое и подменяющий apply и т.п.), вовсе не обязательно создающий shadow копию или новый список ссылок, если можно просто iterate & yield.
Или вы про это вот?
let clone_of_O = { ...O };
let clone_of_A = [ ...A ];
Неужели действительно находятся те кто думает, что результат будет "глубже" чем у того же assign или slice?!
Т. е. понимания что на самом деле делает spread нет в принципе? Мой следующий вопрос был бы, а что в этом примере содержит b:
a = [[1, 2, 3]]
b = [a[0], a[0], a[0]]
c = [...a, ...a, ...a]
И если ответ будет 3 references of a[0], то что вдруг меняется для c, когда aтам просто тупо развернуто.
8080 был первым настоящим микропроцессором, подходящим для повседневных компьютеров, и именно им Intel заложил базу для всего 80x-поколения, от 8085 до 8088.
4004 же был процессор для калькулятора (а Busicom, заказавший его, производили именно калькуляторы), и с ним Intel возможно стала настоящим производителем чипов, но к x86 его даже посредственно не притянуть, начиная от разрядности, архитектуры и всего-того и заканчивая собственно набором инструкций. Даже 8008, который номинально является официальным предшественником для 8088, и соответственно x86, формально тяжело притянуть в качестве прародителя x86-архитектуры.
Ну попробуйте не CPU bound сделать - жажду увидеть 4 потока медленнее одного, продемонстрируйте...
Любой код где исполнение касается GIL-защищенных объектов будет сваливаться в бесконечный lock. Если вы говорите про "абстрактный" C-модуль, где всё вычисление происходит исключительно в С (без дерганья GIL-related primitives), и только результат помещается в питоний объект, то вы ошиблись статьей - здесь про архитектуру python, а не про вызов "сторонних" библиотек из питона. И overhead будет тем больше, чем больше обвязанных GIL объектов ваш код затронет (т.е. чем короче длинна той стрелки в связке python --> C --> python, и чем короче исполнение собственно в C-модуле).
в текущей архитектере CPU bound вычисления выполняются однопроцессно или мультипроцессно...
Зная это писать такой код и говорить какой питон плохой - странно.
У вас простите причинно-следственная связь нарушена. От слова совсем.
При этом критику конкретного недостатка дизайна архитектуры СPython, совершенно заслуженную кстати, вы почему то пытаетесь оправдать наличием в документации сносок, собственно и возникших в результате нахождения тех концептуальных недостатков GIL и иже с ним (заметьте не python, а конкретной реализации). При том что та же критика слышна и из рядов разработчиков языка, причем этот вопрос на моей памяти поднимался неоднократно.
Ну и простейший пример (на подумать) - если добавить флаг состояния объекта типа IsThreadShared, и исключить блокировку GIL-ом на объектах, у которых оно false(а еще лучше у всего bytecode и части evaluation stack, которая затронута тем кодом), то тот пример будет выполнен в 3 раза быстрее однопоточно и 15 раз быстрее в 4 потока. Тоже самое будет если просто тупо "выключить" GIL (просто в качестве теста), т.е. на стадии компиляции python переопределив stable ABI PyGILState_Ensure, PyGILState_Release, PyGILState_Checkи иже с ними.
Тема же multiprocessing vs. multithreaded совершенна ортогональна тут и у меня простите здесь обсуждать это с вами нет ни малейшего желания.
CPU-bound вычисления в питоне выполняются однопроцессно
Нет! Это издержки GIL. Если лень смотреть в исходники, просто см. результат для многопоточного исполнения (натяжение "ручника" зависит от количества потоков, что при N threads < M CPU core однозначно указывает на overhead от "чрезмерной" блокировки).
Странный пример...
Пример как пример... Можно попробовать что-нибудь другое (не "CPU-bound"), результат не изменится. А можно попробовать что-нибудь без GIL (Iron, PyPy STM, хоть тот же PoC Сэма) и узреть разницу.
только в данном случае переключать поток
Никакой поток тут нигде не переключается (напрямую)... каждый поток исполняет собственный изолированный код (с собственным циклом и своими переменными - с полностью независымыми объектами PyObjectи PyVarObject) и context-switch если и происходит, то исключительно на lock-ах в GIL (совершенно не нужном здесь, т.к. пересечений и shared references нет совсем). Пример собственно это и показывает.
Так то да... Но он пробовал его переустанавливать
Нет, воспроизвести не удалось нигде больше (я об этом писал)... Да, скрипт есть конечно (см. статью, самый первый снипет)... можно улучшить немного, типа стоп если
tбольше 1650e6 ну или date из shell... Накидаю как доберусь до компьютера, мобильный хабр это боль.А разве apt при скачивании (или распаковке пакета) не будет ругаться на `hash sum mismatch`? Насколько знаю - должен.
Совершенно верно, время кривое исключительно в питоне. Syscalls, date в shell и т.п. абсолютно не затронуты и никакого дрифта нет, от слова совсем.
И влияет исключительно на питон, причем только третий. Хмм... Ну и ASLR должно как то проявляться тогда, нет? Я имею ввиду запустив тест много раз, процессы будут стучаться по разным адресам. А результат стабильно кривой... Да и кривой только на математике в pytime и т.д.
Ну а дата в номере то для кого? Не ну я ещё могу представить как 8 стала 9... Но как явно круглая цифра в конце (9) стала 1, я не представляю... Как и то, что 10 окт. 1901 г (по юлианскому календарю среда) вдруг могло стать воскресеньем.
Гимназистом он скорее всего тоже не являлся, ибо он тогда бы (в 1901 году) врядли написал бы про себя "(Ростовский) мещанин", а гимназистом бы и назвался... В случае же учащегося (например мещанского училища) это тоже был бы тогда какой-нибудь "сын мещанина".
Курили (да и пили) они тогда почем зря, т.е. "показушной взрослостью" это можно оценивать только с колокольни современного общества. И да, в начале XX века в России не курили лишь священники да староверы какие-нибудь.
По поводу "девятого года" - с правой стороны газеты чётко видна дата:
Где довольно ясно читается "Воскресенье, 10 октября 1899 г.". Ну а 1809-м (что тоже было бы воскресеньем) это не может быть по многим причинам (да и первый номер газеты вышел 1 сентября 1891 года).
Т.е. номеру газеты полтора года... Зачем человек её столько хранил (и именно её закопал)?
Белоручка - soft-handed;
Чистоплюй - squeaky-clean (в смысле помыслов, характера и т.п.), fastidious или squeamish (в смысле щепетильности, педантичности или аккуратности)... Возможно cissy подойдет (но то такое, местечковое да и сильно устаревшее).
Если имелся в виду "Чистюля", то кроме Mr. Freaky-Clean или Mrs./Ms. Cleanliness и возможно wicked hygienic ничего на ум не приходит.
Т.е. действительно никакой разницы не видим, да?..
Одно (создании токсичной среды, игнорирование жалоб и собственно домогательства) - пока какие-то лишь обвинения (сомнительные или нет, не важно), но, снова пока, ничем не подтвержденные вообще. Ну и возможно некрасивый, но притянутый за уши, "скандал" с фото с "номером Косби".
Другое (собственно массовая травля) - в наличии прямо сейчас.
Меня всегда удивляют желание смешать в кучу мухи и котлеты... Как собственно и все эти игры в полит-корректность и попытки любым способом "защитить" от всего и вся многоуважаемый слабый пол, различные меньшинства и т.д., доходящие при этом до полного абсурда.
Я не про то, что проблем с харассментом нет, я про то, что пытаясь насадить весь этот спектр "новых" идеологий, тот театр абсурда иногда напоминает сошедший с рельсов паровоз, который не замечая ничего вокруг, сносит абсолютно всё на своём пути.
А потом удивительные вещи наблюдаем, как в той же Европе, где вдруг цыган и цыганами назвать нельзя... Притом, что нередко это происходит и вовсе за спинами тех "меньшинств". Вот вы где-нибудь демонстрирующих цыган видели с плакатами наперевес, что мы дескать теперь "Sinti und Roma"? Я вам больше скажу - они даже сами возмущены, почему за них, да без них решили.
И так у них во всем - соринку в глазу у всех найдем, бревно же в собственном глазу - никак нет.
Я вам не про суд, а про общее представление о principium disputabilis так сказать. Да и работодатель вполне имеет право оправдывать свои действия здравым смыслом (если они не в конфликте с действующим законодательством).
Хотя бы потому, что с обвинениями в приставаниях (2600 человек?!) ни один не пришел к работодателю в своё время, а на официальный ответ (с вполне обоснованными сомнениями в актуальности и правдоподобности обвинений), который вдруг не устроил сотрудников компании, они тупо начали травлю (с протестными акциями, организацией протестов на форумах и т.д.).
Ну и корпоративная культура и этика должна как бы работать в обе стороны, вы не находите?
Ну это вот тут в каком контексте? Мы сейчас как бы о "цивилизованных" странах, и существование другой крайности где-то, вовсе не оправдывает всей этой вакханалии вокруг современного "харассмента". А то так можно много чего оправдать: ну типа где-то вообще камнями могут закидать, да... Т. е. у нас вроде и неплохо ещё всё.
Остальное комментировать большого желания нет, ибо вы как минимум передергиваете... Травля же толпой одного человека, вне зависимости от степени его "виновности", недопустима в принципе и уж точно не имеет (ни сейчас, ни 10, ни 30 лет назад) ничего общего с нормальной корпоративной этикой и здоровой общественной нравственностью и моралью.
Потому что в нормальном обществе бремя доказательства за сказанное как правило лежит на высказавшемся. Вы же вряд ли начнёте оправдываться, если кто-то вдруг вас назовет
пи...нехорошим словом. В суд конечно можно и подать, но вообще то такое вполне себе может быть "улажено" и работодателем. Другое дело что, в ударенных толерастией странах, он (работодатель) на это вряд ли пойдёт, особенно находясь под давлением общества. Поэтому и имеем то, что имеем, например из недавнего - RMS и FSF, тоже кстати очень даже выглядевшее как травля.Потому что mobbing в нормальных странах точно так же недопустим, как и те же домогательства и т.д. И да, внезапно это повод для увольнения, даже в вашей стране проживания. Я уж не говорю про такой Massen-Mobbing.
Суд и следствие по какому поводу? Для увольнения замешанных в массовой травле, клевещущих сотрудников? Вы серьёзно?
Я знаю что
[Symbol.iterator]у объектов нет, просто когда (в proposal ES2018 если не ошибаюсь) речь велась про object literals, это определялось как "pass all key:value pairs from an object", что и подтверждает пример вроде:Иначе бы такая merge конструкция не очень работала, по крайней мере с assign такое нельзя (там только два аргумента - target и source)... И я готов был поклясться, что assign не работал для неитерируемых... Что они уже после ES2018 накрутили, чтобы даже скалярный объект воспринимался как валидный, мне не очень понятно (как и для чего это собственно есть нужно и хорошо). Для меня это выглядит как жуткий баг/хак (UB на худой конец), но то такое...
JS, слава богу, не мой язык - я его пользую (вынужден) только поскольку без оного в браузерах никуда (к моему большому сожалению). Во всех же других языках "Object" (aka keyed collections, dictionaries, maps или associative arrays) вполне себе iterable (или как минимум enumerable) и никакого ментального диссонанса при использовании spreading / expanding операторов не возникает, даже если по умолчанию оно за бортом и реализовано с помощью тех же assign-подобных конструкций (чтобы, производительности ради, не разворачивать списки от дефолтных "итераторов" в стек).
Посыпаю голову пеплом и выражаю глубочайшие извинения ув. @JSmitty
Только что написал в консоль
{...10}и оно создало мне пустой объект... Хотя я мог бы поклясться, что уже делал такое как-то и оно вылетало с ошибкой. Возможно Object.assign переделали с той поры... или это просто старость.Еще раз прошу прощения если кого ввел в заблуждение.
Только человек мне ниже написал, что можно вызвать spread для неитерируемого. Из чего был сделан вывод, что понимания как spread работает в принципе - нет.
Нет! Обязан (ибо он работает не так как вы себе представляете).
Попробуйте передать туда неитерируемый объект, или переопределите его iterator, чтобы он выкидывал исключение. Я вас уверяю вы его (исключение) обязательно поймаете.
Ну вот первый кандидат на "учить мат-часть"...
Нет, не делает... Она создает новый объект, и передает в него spreaded итератор в виде "списка" object literal аргументов aka key-value pairs...
Т.е. вот эти вот выражения практически эквивалентны в плане нативного исполнения (и последнее не создает никакой копии напрямую):
Т.е. такой flat clone (без
prototype) просто короткая альтернативаObject.assign(). И его же и вызывает кстати, а не то, что вы себе там придумали...PoC на коленке:
Ну spread operator как бы вообще ничего не копирует (ни в глубину, ни на плоскости), это тупо expand arguments сахар (разворачавающий итерируемое и подменяющий
applyи т.п.), вовсе не обязательно создающий shadow копию или новый список ссылок, если можно просто iterate & yield.Или вы про это вот?
Неужели действительно находятся те кто думает, что результат будет "глубже" чем у того же
assignилиslice?!Т. е. понимания что на самом деле делает spread нет в принципе? Мой следующий вопрос был бы, а что в этом примере содержит
b:И если ответ будет 3 references of
a[0], то что вдруг меняется дляc, когдаaтам просто тупо развернуто.А он действительно не имеет...
8080 был первым настоящим микропроцессором, подходящим для повседневных компьютеров, и именно им Intel заложил базу для всего 80x-поколения, от 8085 до 8088.
4004 же был процессор для калькулятора (а Busicom, заказавший его, производили именно калькуляторы), и с ним Intel возможно стала настоящим производителем чипов, но к x86 его даже посредственно не притянуть, начиная от разрядности, архитектуры и всего-того и заканчивая собственно набором инструкций.
Даже 8008, который номинально является официальным предшественником для 8088, и соответственно x86, формально тяжело притянуть в качестве прародителя x86-архитектуры.
Любой код где исполнение касается GIL-защищенных объектов будет сваливаться в бесконечный lock. Если вы говорите про "абстрактный" C-модуль, где всё вычисление происходит исключительно в С (без дерганья GIL-related primitives), и только результат помещается в питоний объект, то вы ошиблись статьей - здесь про архитектуру python, а не про вызов "сторонних" библиотек из питона. И overhead будет тем больше, чем больше обвязанных GIL объектов ваш код затронет (т.е. чем короче длинна той стрелки в связке
python --> C --> python, и чем короче исполнение собственно в C-модуле).У вас простите причинно-следственная связь нарушена. От слова совсем.
При этом критику конкретного недостатка дизайна архитектуры СPython, совершенно заслуженную кстати, вы почему то пытаетесь оправдать наличием в документации сносок, собственно и возникших в результате нахождения тех концептуальных недостатков GIL и иже с ним (заметьте не python, а конкретной реализации). При том что та же критика слышна и из рядов разработчиков языка, причем этот вопрос на моей памяти поднимался неоднократно.
Ну и простейший пример (на подумать) - если добавить флаг состояния объекта типа
IsThreadShared, и исключить блокировку GIL-ом на объектах, у которых оноfalse(а еще лучше у всего bytecode и части evaluation stack, которая затронута тем кодом), то тот пример будет выполнен в 3 раза быстрее однопоточно и 15 раз быстрее в 4 потока. Тоже самое будет если просто тупо "выключить" GIL (просто в качестве теста), т.е. на стадии компиляции python переопределив stable ABIPyGILState_Ensure,PyGILState_Release,PyGILState_Checkи иже с ними.Тема же multiprocessing vs. multithreaded совершенна ортогональна тут и у меня простите здесь обсуждать это с вами нет ни малейшего желания.
Что, простите?!
Нет! Это издержки GIL. Если лень смотреть в исходники, просто см. результат для многопоточного исполнения (натяжение "ручника" зависит от количества потоков, что при N threads < M CPU core однозначно указывает на overhead от "чрезмерной" блокировки).
Пример как пример... Можно попробовать что-нибудь другое (не "CPU-bound"), результат не изменится. А можно попробовать что-нибудь без GIL (Iron, PyPy STM, хоть тот же PoC Сэма) и узреть разницу.
Никакой поток тут нигде не переключается (напрямую)... каждый поток исполняет собственный изолированный код (с собственным циклом и своими переменными - с полностью независымыми объектами
PyObjectиPyVarObject) и context-switch если и происходит, то исключительно на lock-ах в GIL (совершенно не нужном здесь, т.к. пересечений и shared references нет совсем).Пример собственно это и показывает.