Pull to refresh
khim @khimread⁠-⁠only

User

Send message

Редко кто пользовательский ввод в логи кладет, там могут быть персданные, такие логи потом тяжело у поддержки получать.

Ну вот теперь, наконец-то, понятно, откуда вообще такие уязвимости берутся. Пользовательские данные — это ж только паспортные данные и фото!

А все остальные данные (ну, к примеру, URL запроса или там User-Agent со всякими Content-Encoding) пользователь, паинька из паинек, подменять не будет.

Он же такой лапочка!

Даже если злоумышленник.

P.S. Для тех, кто в танке: под user data тут понимаются любые данные, которые вы получаете от пользователя. Даже если вы их сами формируете, ему отдаёте и обратно получаете. Всякие куки, сессионные ключи и прочая лабуда. И огромный процент разработчиков не аномизирует их прямо в вызове функции логирования, а делает это уже потом, когда они в базе. А для того, чтобы Log4Shell сработал попадания в базу не нужно.

Ну дык для этого асинхронные функции и завезли во все языки, которые рядом с производительностью валялись (C, C++, C#, Java, Rust).

Если не заводить для каждой мелкой задачи поток, то что у вас там будет из накладных расходов? Выделение памяти да пара атомарных обращений к памяти на задачу?

Если раскидать задачи хотя бы по 4м ядрам (а это есть уже даже на самых бюджетных бюджетниках), то уже будет выигрыш, а если ядер будет больше — выигрыш будет больше.

А какая, по-вашему, должна быть парадигма работы софта?

Гибкой. Банально создайте 100500 асинхронных задач, отдайте executor'у (как это по русски?), он либо запустит 100500 потоков (если у вас 100500 ядер), либо будет из по очереди запускать на тех 2-4-8, что у вас есть.

Лично я особых перспектив здесь не вижу на текущем железе: переключение потоков и синхронизация дорого обходятся.

Для этого, собственно, и придумали пресловутый async/await.

Только разработчикам не объяснисли, нафиг они нужны, в результате они всё пихают в одну, типа асинхронную, функцию, а потом удивляются, почему нифига не параллелится.

Но не факт что получится их использовать для универсальных вычислений в ближайшее время.

Совершенно неважно — получится или нет.

Важно, что вы там Windows не запустите. Ну никак.

А это, в сущности, единственная причина по которой мы имеем… то, что имеем. Ну не одна WIndows, конечно, а вот все эти Angular'ы и Vue.js… весь массив накопленного де софта.

Просто почти весь XX век ничего, кроме однопотока, у большинства разработчиков и пользователей, не было.

Соотвественно, когда появилась альтернатива, оказалось, что запускать на ней решительно нечего.

Потому на однопотоке ехали пока была возможность ехать. Выжимая из него всё, что можно и чего нельзя.

По кругу: более тяжёлый софт требует более быстрого однопотока, более быстрый однопоток позволяет не думать о том, чтобы менять парадигму работы софта.

А когда упёрлось, то оказалось, что выбраться из этой колеи не так-то просто: ядра-то в стоядерном процессоре будут куда проще и медленнее, чем в таком же по цене 4-8 ядернике! А софта, по прежнему, нету… потому “оно” и не продаётся.

Переход на аналоговые или, там, квантовые, вычисления — тоже ведь Windows не ускорит, ведь так?

Ну а с нуля можно и под сто ядер написать код и под квантовый компьютер… но там не будет быстрого однопотока. Потому что условный Windows там не запустится, а без запуска Windows вам и однопоток не нужен суперскоростной.

Мне казалось, это как раз и есть примерный размер того, что называют процессом Интел 7.

Нет. Была же статья на Хабре. Со снимками. 7нм отличаются от 90нм, условно, тем, что транзисторы “поставили на попа”. Да, это позволилось их больше напихать в кристалл и немного повысить скорость (проводники короче), но ни о каких 10GHz (не говоря уже о 15-16GHz) речи не идёт.

С чего бы вдруг? 16 ГГц это, ЕМНИМС примерно 9 мм в кремнии, при размерах кристаллика 2.4х2.5 сойдёт.

Сойдёт для чего? Чтобы от одного конца кристалла до другого дошло? Возможно.

Но вы что-то там говорили про всякие Tejas'ы? То есть про суперскаляры? Там для этого сигнал должен пройти далеко не через один транзистор. Вот суммарная их длина и играет роль.

От того, то вы эти транзисторы “на попа” поставили расстояние, проходимое сигналом не сильно уменьшилось. Вы не в курсе, что первый процессор на 5GHz появился больше 10 лет назад? Ну так просветитесь.

Тогда с площади 120 кв мм пытались отвести по ватту с миллиметра.

Я вам умный вещь скажу, только вы не обижайтесь. Отвести со 120 кв. мм пусть даже и 200 ватт куда проще, чем жалкие 20-30 ватт с вашего кристаллика 2.4x2.5

Всё равно придётся - пока не появится "оптимизирующий транслятор" для всех тех слоёв абс(т)ракции.

Нет. Достаточно произойти какой-нибудь заварушке между Тайванем и Китаем — и всё. Весь мир оказывает перед фактом: телефоны теперь будут служить лет по 5, а главное — чипы для них, в наличии, только китайские. Мегагерц на 500, от силы на гигагерц. Получите — распишитесь.

И ведь, что характерно, и получат и распишутся.

Подавляющее большинство современного софта потребляет раз в 100 больше ресурсов чем ему нужно, на самом деле, для решения той бизнес-задачи, для которой оно создано.

Появится необходимость — ужмутся.

Да, будет тормозить. Но это не от процессора зависит. И ваш процессор на 15-16Ghz будет так же прекрасно тормозить, как сегодняший проц на 5GHz, если его удастся сделать

Софт “летал” когда разработку WIndows 95 начинали на 486DX на 66MHz в 1992м, а пользовали её на Pentium II на 200Mhz в 1997м.

То есть когда машина разработчика была тормознее, гораздо тормознее, чем машина пользователя.

Вот так — да. Обеспечьте это (неважно как) — и тормоза исчезнут. Не обеспечите? Будет тормозить.

с реальным, а не маркетинговым размером литографии около 20 нм

А ничего, что там у вас элементы размером меньше одного атомного слоя начнут появляться?

"минимально максимальная" КМК в районе 12-16 ГГц

А тут у нас начинают сигналы распространяться быстрее скорости света…

в качестве прототипа я предполагаю Tejas, который имел 65 нм

Вот только не работал этот Tejas нифига. Когда его отменяли, то было уже понятно, что частоты у него будут ещё более “кукурузными” и что ничего хорошего из этого не выйдет.

такой хотспот, конечно, будет греться как печка, но для определённых целей может оказаться выгодным, особенно, если это чиплет.

В принципе что-то подобное можно сотворить, если перейти в 3D и не ограничиваться одним слоем. В этом случае субатомарные конструкции не нужны. Вот только:

  1. Это тупик. Этот трюк вы можете проделать один раз. 4го измерения у меня для вас нету.

  2. Вы получите этого монстра взамен примерно сотни ядер, подобных современным

Да, возможно для каких-то целей оно и подойдёт. Но тратить все эти ресурсы для компенсации того, что кто-то наворотил 100500 уровней индирекции в JavaScript-библиотеке… глупо.

Надо добавить — на существующих решениях.

Не нужно. 5Ghz — это частота, на которой свет, в вакууме, проходит жалкие 6 сантиметров. Никаких предпосылок ожидать чего-то, движущегося быстрее света в ближайшем будущем ожидать не приходится и в субатомные структуры мы тоже не полезем.

Так что нет, никакие новые решения ничего не изменят. Вот сделать параллельно запускаемыми 100, 1000, 10000 потоков — это мы, теоретически, можем. А радикально ускорить однопоток — нет.

Там где производительность реально нужна они и не засыпали.

Серьёзно? Расскажите это программистам, у которых однострочное изменение по полчаса при использовании C++ и Rust компилируется.

Сапожник без сапог, блин.

А браузерные приложения и ко. так это не про производительность.

А про что это? Про испытание терпения пользователя?

Посмотрел на passmark текущий лидер Intel Core i9-12900KF — 4223, самый быстрый Pentium 4 — 666 (это звоночек!) или в шесть раз.

Там существенная часть ускорения — это не ускорение однопотока, как такового, а SSE и AVX. Да, это дало разовое ускорение (Pentium 4 в SSE2 уже умеет, в AVX ещё нет), но там тоже упёрлись: AVX512, может, к десятилетию с момента презентации, и пойдёт в массы, но уже гипотетический AVX1024 — под вопросом.

При этом разрыв между тем что могло бы быть, если бы программисты не прятали голову в песок и тем, что мы имеем в реальности всё растёт и растёт: количество ALU в GPU уже тысячами измеряется, то есть если бы архитектура приложений позволяла, то можно было бы уже спокойно выпускать CPU с тысячами же [низкосоростных] ядер.

Вместо этого оказывается, что 16 ядер загрузить работой нечем. Вместо этого нужно разгонять 2-4-8 до космических скоростей (так что яичницу жарить можно).

Мой компьютер из 2004-го уделает какая-нибудь raspberry pi первого поколения.

Знаете, это даже не смешно. Может вы в 2004м работали на отцовской Амиге, купленной в 80е, но у меня был Northwood 3.4Ghz тогда.

А Raspberri Pi первого поколения — это 700Mhz ARM. И даже не суперскаляр.

Никакого сравнения, в принципе. Разница в сокрости раз в пять. И не в пользу Raspberri Pi.

Или вы про частоты?

И про частоты и про количество инструкций за такт. И да, я знаю, что у Pentium 4 были “кукурузные мегагерцы”. Но где-то полторы инструкции за такт он выдавал, одну, если сильно не повезёт, а современные процессоры хорошо, если, в устоявшемся режиме, три делают. Обычно меньше.

Так что всё, лафа кончилась, “кина не будет”.

Однопоток достиг, фактически, предела. Не будет он уже ускоряться существенно, как бы этого кому-то ни хотелось.

Это в 2002-ом что ли?

Конец прошлого века. Архтектурно последний “большой рывок” — это Pentium Pro, 1995й, окончание “гонки гигагерц” — это Pentium 4, 2000й.

После этого однопоточная производительность растёт настолько черепашьими темпами, что рассчитаывать на неё не стоит от слова вообще. В три раза за два десятилетия, плюс-минус.

Всё, пора программистам просыпаться. Давно пора.

моя мысль в том что если мне сейчас добавить хоть еще 100 ядер, я не увижу ровно никакой разницы.

А виновника вы можете наблюдать в зеркале, однако.

Однопоточная проиводительность упёрлась в потолок ещё лет 20 назад.

Выпосла с тех пор раза в три и ожидать её повышения, увы, не стоит.

Ну может ещё раза в три за очередные 20 лет ускорят (путём увеличения размера ядра раз в сто).

Так что, эта… всё в ваших руках. Думайте как ускорять всё в существующих условиях.

Это ваша задача теперь, не разработчиков железа.

Физику не обманешь.

Кого и когда это останавливало?

alias mc='source /usr/lib/mc/mc-wrapper.sh'

Работает же?

Что мешает сделать такой же для far2l ?

На счет статьи кстати еще, где-то была инфа о мощности ядерного оружия всего в 0.01 килотонны.

Америций или калифорний? Да, теоретически возможно.

Вот только есть одна проблема: страны, способные нарабатывать вот это вот всё в количествах, достаточных для создания “ядерной пули” уже обладают обычным ядерным оружием, что делает всю затею несколько сомнительной.

Если же вспомнить, что “весовые” количества трансуранов проще всего из породы, в которой взорвали обычный ядерный заряд, получать… вся затея начинает напоминать театр абсурда.

А откуда C₁₄ возьмётся в “промышленных” масштабах?

Ядерный взрыв весьма краткосрочен, там вырабатывается масса самых разных изотопов, но в ничтожном количестве. Короткоживущие обеспечивают дикую радиацию в первые часы и дни, но потом они распадаются. А долгоживущие просто не успевают накопиться в опасном для жизни количестве.

В этом смысле Чернобыль какой-нибудь куда опаснее. Там изотопы копятся годами и после выброса их надолго хватает.

Это же надо столько ошибок понаделать в одной фразе! Талант, не всякий может.

Параллельные прямые у Лобачевского, внезапно, не пересекаются.

И теорема Пифагора там не действует (хотя есть свой аналог).

Почитайте на досуге, если интересно.

P.S. Ошибки грамматики и орфографии спишем на опечатки, это не так принципиально.

Понимаете, если бы в статье было сказано, что Таннебаум устарел и что его изучение больше подходит для того, чтобы ознакомиться с историей вопроса, но современные технологии там не описаны, то никто бы и не спорил — у того же Кнута (всем известного, но никем не читанного) тоже есть эта проблема. Пеереход с MIX на MMIX, скорее всего он осуществить не успеет.

Но рассказывать, что у Танненбаума кучи ошибок, которых у него, в общем-то, нет (да, есть опечатки, но я даже в 20м переиздании задачника по физике их находил в своё время)? Ну зачем же врать-то!

P.S. И да, есть много других книг, более полезных на тему архитектуры компьютеров. С тем, что Танненбаум разрекламирован слишком широко — я согласен. Это вообще другой вопрос.

Но я при этом считаю что делать такое 30 лет спустя для обучения GUI - это маразм. Курс на хинди для меня не авторитет.

Для вас, по-моему, ничто не авторитет. В принципе. С чего вы взяли, что это был “курс обучения GUI” с очередью событий? Ещё раз прочитайте, блин: это был курс обучения C++! Самый начальный. Рассказывалось как циклы работают, что такое арифметика указателей и чем виртуальные функции от невиртуальных отличаются.

Но есть одна проблемка: всё это, формально, никакого UI вообще не требует; но, на практике, ученикам хочется какую-нибудь программу запустить и кнопки потыкать.

И вот так уж получилось, что в начальных курсах по языку это никогда не делается с помощью циклов обработки событий и GUI. Неважно какой язык: C++, Java, или, скажем, Rust — всё равно всё начинается с простейших программ, работающих с консолью (вторая глава учебника Rust 2018, например).

Но если к обычным консольным функциям добавить gotoxy и kbhit, то можно делать слегка более красочные программы — что разработчики этого курса когда-то и проделали.

А потом бац: и из новых компиляторов эти функции исчезли. Что им теперь — курс переделывать? А что — с тех пор арифметика указателей изменилась или виртуальные функции стали работать по другому?

В том-то и дело, что 90% этого курса (если не 99%) акутальны и сегодня, хотя пара функций, на которых все примеры в курсе устроены, больше не используются.

И с Танненбаумом — та же история!

На ТурбоСи вы можете

На Turbo C — да. Но речь ведь про курс C++. Turbo C++ 3.1 1991го года и ANSI C++ 1998го года (на котором современный C++ основан) отличаются, в мелочах, очень и очень заметно.

Этот же код вы можете использовать потом - gcc и llvm проглотит ANSI C 1990 без проблем.

Не проглотит даже простейший пример. На #include <iostream.h> поперхнётся.

Да, для Mic-1, самой простой из его учебных машин, есть симулятор, но вне курса Таненбаума он не существует.

Точно также, как и #include <conio.h> вне учебного курса. Ибо реализовать gotoxy и kbhit поверх современных фреймворков — весьма нетривиальная задача, а главное — неблагодарная. Сегодня UI с помощью символов псевдографики и без цикла событий никто не делает.

Но вот знание языка из курса C++ вынести можно, как и понимание того, как, грубо, устроен процессор из курса Таненбаума.

Так что в сущности отличается.

Существенных отличий — не вижу. Извините.

По-моему вы великолепно подтвердили мой тезис.

Вот страница из Таненбаума. Где такая картинка или куски кода?

В курсе, описывающим структуры данных и алгоритмы, очевидно. Где как раз и объясняется как можно устроить очередь на массиве и после которого вам не нужны будут картинки, которые вам так нравятся. И Танненбаум, резонно, ожидает, что программист, лезущий изучать уже и архитектуру процессора, подобный курс прочитал и все упражнения там проделал.

Для сравнения - вот из Дэвид Харрис и Сара Харрис Цифровая схемотехника и архитектура компьютера.

Отлично. И где в этих описаниях описано, что кеш первого уровня имеет размер в 16-64 килобайта, эксклюзивен для каждого ядра и разделен для кода и данных? L2 - общий для кода и данных и имеет размеры в несколько сотен колобайт, редко в мегабайт, а L3 — уже таки многомебайтный, а главно, в отличие от L1 и L2, с развитием железа растёт. А?

А это — критически важная информация, которая нужна программисту (и не очень нужна разработчику процессора, у него эти константы автоматически появятся, когда он начнёт его разрабатывать).

Зато описаны расчёты всяких странных вещей типа процента попадания в кеш в случае работы конкретной программы на конкретному процессоре.

Уже вот буквально из этих нескольких страничек хорошо видно, что в Харрис и Харрис, как данность, приведены (и никак не объяснены) вещи, которые незнакомы и “не интересны” разработчику железа (но которые нужно учитывать), а в Танненбауме точно так же, как данность, приведены (и никак не объяснены) вещи, которые незнакомы и “не интересны” программисту (но которые нужно учитывать).

Но вы, почему-то, из этого делаете вывод про “вредность” Танненбаума, и “полезность” Харрис и Харрис.

Ну вот в какое место может эти примеры из Харрис и Харрис может программист на JavaScript применить? Как он будет проценты промаха мерить и, главное, пытаься как-то на них влиять?

А вот измерить размеры L1 кеша и L2 кеша — он может. И использовать с пользой это знание — тоже может.

Представим себе учебник по органической химии, в котором отсутствуют молекулярные орбитали и степени окисления, а вместо это нудно расжевывается теория валентности 19 века, но в сочетании с обзором продукции химических предприятий 20 века.

Ну то есть стандартный такой, типичный, школьный, учебник органической химии 20 века, после которого школьники не могут объянить почему у фталиевой кислоты не бывает двух изомеров (через двойную связь и через одинарную в бензольном кольце)? Предствил. Собственно и представлять ничего не нужно: большинство советских учебников органической химии так и были написаны.

Там если и был раздел, объясняющий почему у бензола все связи имеют одинаковую длину, то это была, скорее, врезка, призванная показать что “всё на самом деле несколько сложнее”, но подробности оставить ВУЗу специализированному.

Понятно, что если выучить студентов по такому учебнику, их потом нужно будет переучивать заново, и некоторые вещи из выученного им будут просто мешать, вызывать ложные ассоциации (как после чтения Таненбаума люди спрашивают "Verilog - это микрокод?)

Только тех студентов, которые будут специализироваться в органической химии. Ну, может быть биологов и то только тех, кто возится с этими самыми орбиталями, а не всех подряд.

Для подавляющего большинства школьников даже и такой учебник не особо нужен, как показывает практика, но в качестве чего-то, что может побудить кого-то к чтению уже более серьёзных книг — годится.

Вот такой учебник химии - это таненбаум.

Ну да. Полезная книжка для людей, которые не будет разрабатывать процессоры. И да, слишком поверхностная для тех, кто будет. Может и не самая лучшая, в своём классе, но уж точно неплохая и явно не вредная.

Где вы видите “вред для образования”?

P.S. Вы всё время несёте какую-то чушь про якобы ошибки, вами найденные и показанные, но все примеры относятся к категории “сейчас так не носют, это уже не модно”. Возможно. Но ни одной фактический ошибки вы так и не привели, что для меня — вполне себе показатель качества.

P.P.S. Ну вот чем Танненбаум отличается от учебника, по которому один мой знакомый год назад изучал C++ используя Turbo C++ 3.1 (я не издеваюсь, вот сборка для 64 битной Windows 11 к этому курсу, сам курс, извините, на хинди, так что вряд ли вы его сможете прочитать)? Да ничем, в сущности. Просто вы не понимаете, похоже, что с точки зрения образовательной системы, технологии 30-50 летней давности (и более старые) — это то, что описывается в большинстве учебников, а если где-то речь заходит о технологиях 10-20 летней давности, то это будет, в любом колледже, охарактеризовано как что-то суперноваторское и мегаэкспериментальное.

Это вы бросьте. Все книги в мире написаны для того, чтобы человек смог придти в отдел разработки процессоров и начать работать. И описания языков PHP и Python. И книжки про операционные системы. И, уж конечно, книжки, описывающие архитектуру компьютера. Это же аксиома! Во всяком случае так считает топикстартер, как я понял.

Давно я не видел такого уровня снобизма, если честно. Половина комментаторов говорит автору: “эта книга — не для тебя”, но это замечание даже не удостаивается серьёзного ответа, дискуссия, с упорством, досточным лучшего применения переводится в разрез “выпуска студентов с специализацией "компьютерная архитектура"”.

А кто, блин, вам сказал, что эта книга для них? Или что она будет у них единственной? Это было бы бесконечно глупо, но автору ведь пофиг на то, что подавляющее большинство читателей не будут студентами подобной специализации. Важно же, что то, что он [Таннебаум] пишет, очень слабо связано с тем, как работает группа проектирования процессоров в современной компании. А тот факт, что на каждого человека из группы проектирования процессоров приходится не одна сотня разработчиков софта, которым, внезапно, знание того как в общих чертах устроен компьютер и процессор тоже может оказаться небесполезно.

Я воспринимаю Танненбаума как расширенную версию вот этой вот книжки, но эта книга крайне плоха ведь, с точки зрения группы проектирования процессоров в современной компании…

P.S. Хотя, разумеется, это не означает, то Танненбаум — идеален. Но просто если не ожидать от него того, что он даже не пытался достичь, то будет… ну не будет, по крайней мере, вот этих претензий идиотских.

В частности он пропустил революцию в проектировании с помощью логического синтеза конца 1980-х.

Отлично. Однако предположим, что книжка Танненбаума — это “химия для геологов”. То есть описание железа для программистов. При написании операционок низкоуровневую архитектуру процессоров нужно учитывать, так что наличие такой книжки именно у Танненбаума разумно.

Ну и где, в каком месте, отсутствие “послереволюционного” описания архитектуры помешает программисту? А это, внезапно, 90%, если не 99% потенциальных читателей (почти во всех вузах программистов, которые никогда не будут рарабатывать процессоры тоже обучают архитектуре).

У вас же с точки зрения наиболее вероятного читателя книждка в статье не рассмотрена и даже в опросе такого варинта нет. Только и исключительно взгляд с точки зрения разработчика процессоров. Но разработчкиов процессоров в этом мира — на порядок (два порядка? три порядка?) меньше, чем программистов! Почему вы рассматриваете книжку не с точки зрения её чиьтателя, а исключительно со своей?

Information

Rating
Does not participate
Registered
Activity