- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
template<typename T>
T* sanitize(T* p)
{
return reinterpret_cast<T*>(
reinterpret_cast<uintptr_t>(p) & ~(alignof(T)-1));
}
template<typename T>
constexpr size_t avaliable_width()
{
switch(alignof(T))
{
case 1: return 0;
case 2: return 1;
case 4: return 2;
case 8: return 3;
case 16: return 4;
case 32: return 5;
case 64: return 6;
case 128: return 7;
case 256: return 8;
default: return 0;
}
}
template<size_t bit, typename T>
T* set_tag(T* p, bool tagged = true)
{
static_assert(bit < avaliable_width<T>(), "bad_width");
if(tagged) {
return reinterpret_cast<T*>(
reinterpret_cast<uintptr_t>(p) | 1 << bit);
}
return reinterpret_cast<T*>(
reinterpret_cast<uintptr_t>(p) & ~(uintptr_t(1) << bit));
}
template<size_t bit, typename T>
bool get_tag(T* p)
{
static_assert(bit < avaliable_width<T>(), "bad_width");
return reinterpret_cast<uintptr_t>(p) >> bit & 1;
}
Младшие биты указателей на выравненные типы всегда нулевые. Из за этого (по формуле Шеннона) указатель несёт в себе меньше информации, оставаясь того же размера. Битоёбов это расстраивает.
Follow us!
Еще в красно-черном дереве цвет можно хранить в указателе (boost::container::map).
ЛОЛ! Премию "битоёбы года" им!
Зато у него был тяжелый день. У него каждый день был тяжелый...
А теперь расскажи им что в 99.9% в x64 указателе половина старших бит простаивает.
Битоеб бы такой хуйни не сделал. Он бы через сдвиги замутил
Компилироваться будет дольше.
Сортировка пузырьком в constexpr считается намного дольше, чем если скомпилировать и запустить
Там же по сути степень двойки надо посчитать, её и сдвигами можно...
> всегда
Ой ли...
Есть пара классических алгоритмов - те же красно-черные деревья - которым помимо указателя на данные, нужно только 1-2 бита дополнительной информации.
На 64бите, если у тебя структура содержит указатель (классическое бинарное дерево: только указатели) то ее размер будет выровнен на 8 байт. Добавление одно-байтового поля, из-за паддинга, приведет к потере семи байт. Если у тебя инстанций структур миллионы, то это уже очень сильно ощутимая трата памяти.
Вот поэтому и трахаются.
пробовал - медленнее. так получается двойное разыменовывание указателей. плюс данные смежные в разных местах памяти лежат, что ухудшает cache footprint.
http://melpon.org/wandbox/permlink/vrwfBc7NzxIcd33R
я думал что бы просто индексы/указатели в нечто типа radix tree заворачиваешь.
это становится проблемой когда начинаешь пытаться масштабировать систему или надо лимиты найти.
Даже если обернуть это всё в какой-нибудь tagged_pointer<T> без неявного преобразования в указатель, будет намного безопаснее. По крайней мере, случайно выпустить похереный указатель в другие части программы и распидорасить память сложнее станет.
как если бы от вас мудаков было так просто что-то спрятать.
Для чпегов поинтересней методы есть, когда по бесполезным частотам размазывают данные. Оно даже некоторые не слишком сильные трансформации может пережить...
Подозревается же... Ну и чем меньше упихано данных - тем меньше это отличается просто от хуёвого компрессора...
Его jpg был разработан настолько, что он мог спрятать в нём википедию.
А если это псевдослучайный выхлоп какого-нибудь AES, как его можно обнаружить?
А по неестественному частотному спектру или другим характеристикам можно заподозрить, что там что-то спрятано.
З.Ы. Надо кота завести, чтобы стеганограммы постить на инстаграм :3
С прошлого года Инстаграм стал поддерживать загрузку PNG, а также загрузку картинок, выходящих за габариты 612×612, но есть риск, что зрители с ARMv6 на борту такого котика не увидят, потому что последняя версия для такого говна мамонта (а именно 4.2.x, вышедшая три года назад) эти новшества не поддерживает.
Сторонние программы для «репоста» в Инстаграме во внимание не берём, ибо этими костылями пользуются редко, к тому же они портят картинки.
Ещё можно во Вконтакте поучаствовать в так называемом лайктайме — это когда твою фотку репостят в группу и куча случайных зрителей ставит лайки в надежде, что за активность их примут в лайктайм и они тоже соберут лайки.
Наконец, можно что-нибудь склепать для Пикабу, Джойреактора, Яплакал и прочих фишек. Есть шанс, что картинка заслужит бессмертие и первоначальный автор затеряется.
нет
стеганография искажает спектр изображения, и это можно детектировать статистически
JSteg вообще _очень_ характерный паттерн даёт, F5 чуть менее очевиден, но тоже я видел статьи и про его стеганализ
Redundant Array of Independent Pointers
В 15 указателях как раз накопится достаточно битов на восстановление одного из них (если знаешь, какой помялся)... Но надо больше, чтобы задетектить какой именно убит...
Экономия места на упаковке: 12 знакомест вместо 13. Прирост пирфоманса ≈ 8%.
С тем же успехом могли бы загнать и 14-ю цифру, размазав её по цифрам с 8-й по 13-ю. А нет, тогда же переворачивать упаковку вверх ногами будет нельзя.
https://ru.wikipedia.org/wiki/European_Article_Number
У цифры ширина в шесть условных пикселей, у разделительной полосы — в четыре. Да, у разделительной полосы первые четыре пикселя совпали с шестёркой (чёрный, белый, чёрный, белый), но у шестёрки потом идут ещё два белых пикселя, а только потом следующий знак. То есть разработчики сэкономили два пикселя после первой разделительной полосы и ещё два после второй (считать место после третьей полосы бессмысленно), итого 4 пикселя, т. е. 2/3 цифры.
Да, мало того, что одну цифру размазали по шести, так ещё и на разделительных полосках сэкономили 2/3 знакоместа. Представьте, если бы в сишке точка с запятой занимала не байт, а полбайта, сколько места было бы сэкономлено!
>два пикселя после первой разделительной полосы и ещё два после второй (считать место после третьей полосы бессмысленно), итого 4 пикселя, т. е. 2/3 цифры.
>в сишке точка с запятой занимала не байт, а полбайта
Я читаю этот пост, я не могу понять смысл, но явно вижу вореции. И зожатие, и циферки, и стиль.
Без широкого белого пространства справа или слева двойная тонкая полоска — это защитный шаблон, а не шестёрка.
P.S. Опять похоже на вореции из-за обилия цифр.
Не. Тут понятнее. Плюс вчера время было очень позднее.
>6 в левом поле 0101111
Вот эта штука ломает всю легенду.
Семь пополам не делится, поэтому в негативе полоски по-любому будут другой толщины.
Эх. Там же помехозаshitный оверхед просто пиздейший
95 полосок = 95 бит. Если грубо говоря 10 бит ≈ 3 десятичных разряда.
То 90 бит ≈ 27 десятичных цифр. А хранятся всего 12.
7 бит на каждую цифру. Сёмь!
В 7 бит не 10 значений влезет, а все 128.
То-есть, опять таки джвухкратная перепитушня.
Итого лишь 5 активных битов, в которые влезает 32 значения. Но всё равно перепитушня.
Ч.Т.Д.
>Битоёбов это расстраивает.
-XX:+UseCompressedOops
Вообще никогда не понимал этих криков про 4Gb - потолок 32битных процессоров.
Какого хера? Если минимально адресуемая единица памяти - байт. Байт, блеать!
8*(2**32)=32 Gb. Не встечал в своей практике полезных десктопных приложений, которым нужно даже 4гига.
А тут джва указателя по цене одного. 64битные указатели просто ненужны.
Как будто это много.
Плюсаторы тоже пусть не стесняются
если ничего не делать
Тебе там тоскливо одному, 3_14dar?
графика и видео (расход памяти растет квадратично с разрешением).
встроеные базы (сессия, конфигурация, данные; версионирование оных).
(компиляция/оптимизация?)
(ну и математика, конечно, хотя оно не так сильно десктопно, но: excel & friends.)
есть много применений для большого количества памяти. 64 адреса - это шаг в этом направлении. можно кучи херни кэшировать, но на текущий момент, из-за ограничения памяти, приходится вычислять/с диска/сети тянуть.
3Д давно считают на специализированных серверах и фермах. Энкодинг и просмотр даже 4К не требует запредельных количеств памяти.
>встроеные базы (сессия, конфигурация, данные; версионирование оных).
Зачем большие БД тащить на десктоп. Всякие sqllite иже с ними не требуют так много памяти.
>(компиляция/оптимизация?)
Надо проектировать языки с LL(1). И поменьше лепить крестошаблонов в компайл-тайме.
При этом даже компиляция монстров вроде FF требует около 3-4 гиг памяти. Случай, скажем таки исключительный.
>excel
Ну прям 4 гигабайта?
>есть много применений для большого количества памяти. 64 адреса - это шаг в этом направлении.
Да. Только 95% программ по прежнему с головой хватает 4гиг.
А когда будет тормозить, периодичнски портить базу и вообще окажется, что это безфункциональное днище, то конечно же возьмешь нормальную бд, но зачем было жрать кактус?
> Надо проектировать языки с LL(1).
Ты хоть раз то это делал? Там обычную вычислялку выражений то нормально не напишешь. Вместо дерева выражения оно тебе построит днище, а ты из него должен будешь получить нормальное дерево с правильными приоритетами и ассоциативностью и порядком исполнения операций. Только парсер с откатами. Только с возможностью задать приоритеты.
Да, пилил. LISP — это просто суть LL(1). Они созданы друг для друга.
>Там обычную вычислялку выражений то нормально не напишешь.
Польская нотация — твой друг. Даже школьник осилит вычислялку выражений.
>Ты хоть раз то это делал?
Нет, не своё Г проектировал.
>2016
>сперва добейся
Лол, да. Но LispGovno.
> Польская нотация — твой друг
Лол, да, но она как и лисп не нужна
> Нет, не своё Г проектировал.
Чужое г?
> сперва добейся
Да я не об этом
Я просто пояснил, что для нормальных применений не пригодно
> Лол, да, но она как и лисп не нужна
Почему? Есть какие-то строгие аргументы и исследования (скажем, опыты над изучающими математику, которых обучили только одной нотации и изолировали ото всех, использующих другую), поддерживающие инфиксную нотацию? Или инфиксная питушня - дело привычки, исторически сложившийся ненужный бред?
Если что, я голосую за инфиксную нотацию и сишкоподобный синтаксис, высказывался в пользу них здесь ранее, но у меня нет ни одного аргумента кроме тех, что сводятся к "я так привык".
Надеюсь ты не предлагаешь избавить людей от абстракций и их привычки писать не оптимальный, но читаемый и поддерживаемый код?
А чо, давай перепишем все учебники и через пару поколений люди на ассемблере с учетом конвееров команд процессора, кешей, оптимального распределения регистров начнут писать код. Ну а чо, лл1 парсер, быстрый этап оптимизации все как ты хотел.
Нечего перекладывать работу машин на людей. Темболее ту, что почти не имеет последствий по сравнению с другими этапами.
Я, Xom94ok, находясь в здравом уме и твердой памяти, торжественно заявляю:
+ - * / 1 2 3 4 5
идет напитон по причине нечитабельности. Скобки
(+ (- (* (/ 1 2) 3) 4) 5)
не помогают. Этот минус относится к той пятёрке?
Разнести выражение по строкам не вышло, монитор распидорасило по вертикали, да так, что пришлось новый мятный нексус покупать и с него писать, а так - парсер строить легко, да.
> (+ (- (* (/ 1 2) 3) 4) 5)
> не помогают.
Сравним:
Так лучше?
#define begin {
#define end }
Не, дружище, я читать такую питушню не хочу и потомкам читать ее не желаю
>Даже во времена бейсиков инфиксную нотацию осиливали и при 64кб рам ниче не тормозило.
Блять, мне за тебя стыдно. Именно за воинствующее неосиляторство.
LL(1) и польская нотация вещи ортогональные. Паскаль тому подтверждение.
В этом проблема, что бейсик в 64кб не тормозили, а буст с крестам, 4х ядерным процом и 8Gb сука тормозит.
А парсить он может и привычный инфикс.
— Товарищ! Товарищ!
— Бляяя, заебаал, блядь!
— Как развился, товарищ? Продался западу наверное? Товарищ...
— Ёб твою мать, блядь, иди отсюда нахуй, блядь!
— Что, что случилося-то?
— Ты чё, вторгся что ли, мудак, блядь?!
— Не, я не нападал. Я тебе коммунизма принес!
— Сука, блядь, пидорас, блядь! Хули ты сделал, ты чё, мудак что ли совсем, блядь?!
— Что ты! Я коммунизма тебе!..
— Блядь, всё-таки напал, ой мудель, блядь!.. Твою мать, убери эти войска нахуй отсюда, блядь! Сейчас будешь всё это выводить, блядь!
— Я тебе принес коммунизма-то!
— Чё ты мне коммунизма принёс, чё ты, мудак, что ли бля?! Хули ты вымазл… хули ты пропагандой-то вымазался, мудак, блядь?!
— Я уж начал строить, я тебе…
— Пидорас, блядь! Сука, блядь!
— Товарищ, ты что!
— Убери это говно отсюда, блядь!
— Я начал строить уже!..
— Ёб твою мать, блядь, и всю Карелию захватил, блядь!
— Хотел тебе построить-то!..
— Мудак, блядь, ну ты мудак, блядь, я тебя сейчас убью, нахуй! Я тебя, блядь, сейчас убью нахуй, блядь!
— Я тебе принес коммунизма-то!..
— Блядь, ну ты пидорас, блядь…
— Коммунизма-то…
— Бля, ну ты тоталитарный, ёб твою мать, а…
— Коммунизма-то…
— Бля, с кем меня на границе посадили, охуеть, ёбаный в рот!..
— Я не нападал, я тебе честно говорю! Я тебе… я просто хотел тебе сделать доброе дело…
— Чё?
— Я не нападал вообще сегодня!..
— Чё, нахуй, мне — добро?
— Я хотел тебе…
— Какое доброе дело? Ты понимаешь, что ты захватил, бля, полуостров, единственный полуостров. Единственный, блядь, полуостров, мы на нём живём. Живём на полуострове, а ты его захватил. Чё… где мы теперь жить будем, где, а?!
— Хотел тебе доброе дело!..
— Где я жить теперь буду?! Хуль ты пропагандой вымазался, что теперь это читать буду?!
— Я не нападал, просто провокационные артобстрелы!..
— Границу от Ленинграда убрать что ли?! Я тебя сейчас уберу!
За чёрствым хлебом в воронежских сёлах выстраиваются в очередь
https://www.youtube.com/watch?v=2u6tjvwp_Mo
В коментах:
Добрыня Никитич6 дней назад
путин мразь
thealphazoid5 дней назад
а коллективный путин - это 140 млн мразей
Oleg Oleg6 дней назад
блядский обама ,что творит сука!!!!!
Сергей Тарасов5 дней назад
Если бы этот сюжет вдруг показал телеканал "Дождь"-его бы патриоты с говном сожрали. А тут-ничего,нормально.
Александр Квитин4 дня назад
у вас есть сыр "Дор Блю"?
-Что за сыр такой?
-Ну это тот,который с синей плесенью.
-Нет .Сыра нет.Есть хлеб "Дор Блю" и колбаса "Дор Блю"
Ляля Наивная4 дня назад
блядство, по совести- вешаться нужно управленцам хуевым, 40% мировых запасов полезных ископаемых в стране а они олимпиады по 50 000 000 000 долларов закатывают а старики плесень жрут, как скотина.
BleakAutumnMist6 часов назад
Скоро с быками за клочок травы бодаться начнут и свиней толкать под дубами в поисках желудей.
Понихейтер Епифанцев9 часов назад
В деревнях ели всё этот самый мой хлеб ели!
если что, ко-ко-ко ко-ко-ко я голосую , слился как животное, маздайка за инфиксную нотации, анскильное говно , питух, иди кукарекай, потому что удобнее.
для хранение , Сишка, проектов и , Сишка, сессий, и на больших анскилед проекте среднего заедушный , животное, размера не пробовал. 8-12гб жрет столько парсер с откатами. питушня только ты питух, возможностью задать
только Царь мне царь питух, анскильный питух, сказал. всё более , днище галимое, сложное — заедушный маздайка для теоретиков. так и ещё раз повторю, тебе животное: Царь это всё маздайка в какой-нибудь код царской коррекции.
redundant днище array of слился ты животное, independent code штеуд shared libraries много применил анскильных функций жрет столько 1-2 бита дополнительно, слился как животное, днище. 64 питушня анскильная кукарекалка - это шаг говно в этом направленцам анскильная кукарекалка хуевым, 40% , животное, мировых запасов полезным частотам оно и питушара анскильная в африке дерево.
Это вообще ортогонально.
Классический пример. В паскале сиалголоподобный синтаксис. И в си алголоподобный синтаксис. Только тип перед переменной/функцией. Виртовские компилеры LL(1)
Также я где-то видел как для Go и Rustа пилили LL(1) горматики.
Просто для лишпа это вообще тривиально.
>только это не добавит производительности,
Нормальным оно будет. Преимущество LL(1) в том что можно парсить поток на лету.
Как это делает SAX парсер.
>но будет не верным
Это вообще абсурд.
>тк полученное дерево выражений надо будет дико перепилить
Бляяя. Дерево, оно и в африке дерево. Его не надо перепиливать.
Просто по мере получения инфы от парсера ты инсертишь в нужный парент и получаешь произвольное дерево.
Однако повторюсь: дерево зачастую вообще не нужно. Благодаря LL(1) расчёты выражений можно выполнять на лету.
> не пригодным для расчётов
Ага. Рассказывай еще.
Add(Sub(Mul(Div(1, 2), 3), 4), 5)
Единственная невыдуманная проблема LL(1) — левая рекурсия. Но ты о ней даже не упомянул.
У тебя есть джва вореанта в что преобразовывать инфикс: по сути это лишп или форт.
Польская (обратная) нотация — самое удобное промежуточное представление.
Как только ты её получаешь, дальше тупо итерируешь и интерпретируешь выражение посредством стековой машины. Всё.
Арность операторов известна и фиксирована — 2. Встретил 2 числа — применил функцию.
Но конечно ты не знаешь про удобство бесскобочной (польской) нотации, потому начал кукарекать про «НИНУЖНА», «НЕХИЛАЯ ПОСТ ОБРАБОТКА», «ПЕРЕПИЛИТЬ ДЕРЕВО».
>ты не знаешь что и куда вставлять
Вставляй в джва стека.
За чёрствым хлебом в воронежских сёлах выстраиваются в очередь
https://www.youtube.com/watch?v=2u6tjvwp_Mo
В коментах:
Добрыня Никитич6 дней назад
путин мразь
thealphazoid5 дней назад
а коллективный путин - это 140 млн мразей
Oleg Oleg6 дней назад
блядский обама ,что творит сука!!!!!
Сергей Тарасов5 дней назад
Если бы этот сюжет вдруг показал телеканал "Дождь"-его бы патриоты с говном сожрали. А тут-ничего,нормально.
Александр Квитин4 дня назад
у вас есть сыр "Дор Блю"?
-Что за сыр такой?
-Ну это тот,который с синей плесенью.
-Нет .Сыра нет.Есть хлеб "Дор Блю" и колбаса "Дор Блю"
Ляля Наивная4 дня назад
блядство, по совести- вешаться нужно управленцам хуевым, 40% мировых запасов полезных ископаемых в стране а они олимпиады по 50 000 000 000 долларов закатывают а старики плесень жрут, как скотина.
BleakAutumnMist6 часов назад
Скоро с быками за клочок травы бодаться начнут и свиней толкать под дубами в поисках желудей.
Понихейтер Епифанцев9 часов назад
В деревнях ели всё этот самый мой хлеб ели!
>ты хоть раз говноязык то это ко-ко-ко делают сами фреймворки, ко-ко-ко на правах говно дополнительности. скобки
(+ (- тебе питушку (* (/ 1 2) 3) днище 4) 5)
не помогают. питушарский этот минус хрень относится к той питушня пятёрке?
разнести выражения оно хрень тебе построить-то!..
— мудак, маздайка говноязык блядь?!
— не, я не питушня напишешь.
польская анскильная кукарекалка для ко-ко-ко неосиляторов Царь компиляция монстров маздайка вроде ff требует запредельных заедушных количеств памяти.
вот поэтому у нас питушня и есть только хрень говно с возможностью анскилед задать приоритеты. , анскилябра, ты хоть раз то говно это делают сами фреймворками, я говноязык редко вижу заедушный что бы разрабы ресурсами , животное, анскилед за зря разбрасывались: питух за них это питушня делает ручной рефрешь.
автопересчета, а ,я Царь, лалка, ты про Царь что? это типа ты питух, мой вопрос считаю заедушный закрытым >короче лл1 и польская нотация тебе питушку тебе питушку нинужна. так анскильное говно я писал, что анскильное говно питушарский инфик рая питушня нотацию и , днище галимое, сишкоподобный синтаксис. заедушный и в говноязык я тут Царь си алголоподобный синтаксис. и говноязык в си алголоподобный синтак , питух, иди кукарекай, питушара анскильная
Царский лисп
Признаю поражение по конкретно этому вопросу
Вот негодяй! Я уже пример начал пилить.
Я ж говорю: фактически выходит конвертер в лишп/форт.
Проблема в термине "произвольный язык". Типичное алголоподобное гавно типа явы и так хуярится в стековую машину.
Думаю можно, только ссылки функции саму на себя и прочую экзотику надо разруливать Y-кобенатором. У Вирта же получилось однопроходной LL(1) конпелятор поцкаля сделать.
>Потом достаешь готовый форт или лишп или даже сам пишешь на коленке и мои "кресты" готовы
Чтоб твои "кресты" были готовы, нужен оптимизующий jit-компилер из твоей стековой машины в ассемблер реального процессора.
Интерпретатор вот:
http://govnokod.ru/20220#comment335520
http://govnokod.ru/20230
Парсинг и исполнение потокового выражения на лету.
Ну это на самом деле не проблема. Просто по другому записывать все не в самой удобной форме. Но мне проблем это ни разу не создавало,
Не проблема. Но надо это учитывать. Плюс там экспоненциальная питушня может вылезти.
> Просто по другому записывать все не в самой удобной форме.
А кто-то чуть выше рассказывал про то что префиксная нотация НИНУЖНА.
За чёрствым хлебом в воронежских сёлах выстраиваются в очередь
https://www.youtube.com/watch?v=2u6tjvwp_Mo
В коментах:
Добрыня Никитич6 дней назад
путин мразь
thealphazoid5 дней назад
а коллективный путин - это 140 млн мразей
Oleg Oleg6 дней назад
блядский обама ,что творит сука!!!!!
Сергей Тарасов5 дней назад
Если бы этот сюжет вдруг показал телеканал "Дождь"-его бы патриоты с говном сожрали. А тут-ничего,нормально.
Александр Квитин4 дня назад
у вас есть сыр "Дор Блю"?
-Что за сыр такой?
-Ну это тот,который с синей плесенью.
-Нет .Сыра нет.Есть хлеб "Дор Блю" и колбаса "Дор Блю"
Ляля Наивная4 дня назад
блядство, по совести- вешаться нужно управленцам хуевым, 40% мировых запасов полезных ископаемых в стране а они олимпиады по 50 000 000 000 долларов закатывают а старики плесень жрут, как скотина.
BleakAutumnMist6 часов назад
Скоро с быками за клочок травы бодаться начнут и свиней толкать под дубами в поисках желудей.
Понихейтер Епифанцев9 часов назад
В деревнях ели всё этот самый мой хлеб ели!
— Я уж построил…
— Я тебя сейчас убью, нахуй. Ты понял, что я тя ща убью?
— Ну что ты сердишься, прими…
— Блядь…
—…я тебе доброе дело сделал, принёс комму... войска обстреляли, я тебе идеологию принес... это... не нападал после этого, как коллективизацию провёл, я тебе коммунизма принес, не просил я, не нападал!
— Иди вон туда в континент отступай, понял, блядь?!
— Я не нападал…
— Чтоб через пять минут мирный был! Иди в глубь континента, сука, отступай!
— Я не нападал сегодня…
— Иди внутрь континента, остутпай, блядь! Германия, бля! Германия! Этот коммунист напал, блядь! Германия! Иди обратно, блядь, чтоб сейчас пришли — ты мирный был, нахуй! Ты понял, бляяя?! Чтобы мирный был, сука! Захватил, пидорас, а! Германия, блядь, он напал! Идите объявляйте войну ему, нахуй, я с ним здесь сидеть не буду, блядь!
Так там не из-за крестошаблонов компиляция тормозит, а из-за ебанутого оптимизатора в гцц, что блин воротит деревьями всей программы
видео - камеры пользовательские уже давно могут 4K, но для хорошего интерфрейм кодирования тебе нужно 10-100 кадров в памяти держать. 4К фрейм - 32МB (4 байта на пиксель).
компиляция/оптимизация - ты наверное LTO на проекте среднего размера не пробовал. 8-12ГБ жрет с легкостью.
excel - кэширование мат/стат функций жрет столько памяти сколько ему дашь.
"большие БД тащить на десктоп" - потому что 4ГБ это давно не "большая база". прошный софт давно пользуется локальными встроенными базами для хранение проектов и сессий, и на больших проектах это с легкостью переходит гиг. и некоторый про софт это даже позволяет в RDBMS держать. подкинь пару десятку снэпшотов/версий проекта - и вот ты уже давно >4ГБ.
> (4 байта на пиксель).
Дружище. 32bpp - это RGBA. В него никто не кодирует. Потому что в популярных стандартах/кодеках оно не шибко поддерживается. Самое популярное YUV420 - 12bpp=1.5 байта/пиксель. 99% процентов рипов именно YUV12.
>4К фрейм - 32МB (4 байта на пиксель).
Но даже 4 байта . Печально видеть когда у программиста проблемы с элементарной арифметикой.
4К * 4 байта = 16 Mb.
>но для хорошего интерфрейм кодирования тебе нужно 10-100 кадров в памяти держать
x264 --fullhelp | less
ПЛАЦЕБО, блеать. 60.
8 threads * 60 frames*1.5bpp*4K=6M*60=360M*8=3Gb;
Да, блин сам глупость сморозил. Но сути это не меняет.
для каких ламеров юзверей, им 4Г в ж не сдались. но основной продажный момент ПЦ железа в том что ты на нем потенциально можешь делать.
>cd x265 && grep -ir lookah *
source/common/param.cpp: param->scenecutThreshold = 0; /
source/common/param.cpp: param->lookaheadDepth = 10;
source/common/param.cpp: param->lookaheadDepth = 15;
source/common/param.cpp: param->lookaheadDepth = 15;
source/common/param.cpp: param->lookaheadDepth = 15;
source/common/param.cpp: param->lookaheadDepth = 25;
source/common/param.cpp: param->lookaheadDepth = 30;
source/common/param.cpp: param->lookaheadDepth = 40;
source/common/param.cpp: param->lookaheadDepth = 60;
>помножь на потоки.
Я ж помножил:
>8 threads *
Вылезти за 4 гига при большом желании реально. Я не спорю.
Если поставить 32 потока, безумные настройки, кодирование в 10/16 bit. Другой вопрос какой там нужен процессор и как это всё будет тупить.
Но легко видеть что при кодировании в 4 потока 4 гига хватит даже для 4К.
>если ты еще например ОС хочешь одновременно в памяти иметь
Не-не-не. Речь о другом что для ОДНОГО ПРОЦЕССА часто достаточно 4 гига. Тогда указатели внутри этого процесса можно сделать 32-битными.
Естественно что процесс может бегать в 64-битной среде и ОС будет оперировать 64-битными указателями = базовый указатель + 32 битное смещение.
Кодирование видео в N потоков, можно сделать логически просто разбив файл на N частей, и запустив N процессов, каждый из которых <4Gb.
если ты уже проглатил этот poison pill, так какого хера парится?
поэтому то с этим делом никто и не парится.
я не знаю про твой опыт, но я лично находился по граблям 32 vs 64 бита совместимости и чисто принципиально всегда чистую 32 или 64 бит систему делаю.
хотя в новых дебьяная недавно пару раз приходилось ":i386" пакеты ставить, и все даже работало, и даже ничего другого не ломалось, но все равно - на кой хер парится.
Чертовы луддиты везде
надеюсь ты с этого не сделаешь хотябы вывод, что 32хбитной системы хватит всем
А то уже вижу как оконное приложение (пустое окно) занимавшее когда-то 1-3 метра, превращается в 100-200 метровую js-питушню. Не верите? Откройте хром.
Сейчас пустая вкладка 100 метров, а завтра 1-2 гига.
http://x265.ru/en/compare-x265-and-x264-summer-2014/
x264
Version: core 142
Encoding type: 2 прохода
Encoding parameters: –bitrate 4000 –input-res 3840×2160 –fps 50 –level 5.2 –preset placebo –slow-firstpass
И не стоит брать те 8Gb что для x265, то были первые версии.
Он за эти 2 года стал намного менее прожорливее.
Да и 0.14 FPS — это адски медленно.
и ты продолжаешь тупо цеплятся за текущее состояние софта, которое существует потому что на типичном ПЦ стоит 4 гига памяти.
как только стандарт доростёт до 8 или 16 гигов, я уверен что ты там увидшь расход памяти 4 или 8 ГБ.
потому что всегда есть что-то что можно съоптимизировать с помощью дополнительно рабочей памяти.
Известный факт. Тому есть несколько причин.
1. Это ты еще HM (референсный hevc) не пробовал! Там скорость 1 кадр/минуту для 640х480 — это обыденность.
2. x265 пишут индусы и Мин Чен. Хотя и стараются (тырят лучшие части x264).
3. Стандарт hevc очень сложный и многогранный. Количество вореций, которые надо перебрать больше AVC на порядок.
>что всегда есть что-то что можно съоптимизировать с помощью дополнительно рабочей памяти.
И в этом главная проблема многих современных разрабов.
А! У них теперь 8 гиг, давайте засунем в наш софт еще 100500 свистоперделок!
Ебаный оверинжиниринг.
ты путаешь "расточать ресурсы" и "использовать ресурсы".
возми тот же hash vs tree: с помощью памяти O(log(n)) поиск делается почти в O(1).
или таже математика: вместо дорогой мат функции, просто берешь пред-подсчитаное значение.
к слову. с современными фреймворками, я редко вижу что бы разрабы ресурсами за зря разбрасывались: за них это делают сами фреймворки, на правах дополнительного сервиса и упрощения работы. почему народ ими и пользуется.
Где еще может использоваться много памяти - системы реального времени, где динамически выделять память - плохо, и ее всю доступную сразу же выделяют для програмы. Например, файловая система в датацентре может занимать несколько сот гигабайт памяти (кешировани восновном). Кеши всяких СиДиЭнов и т.п. тоже будут очень большими - там свободной памяти не бывает.
А да. Но вот тут и не поспоришь. Архиваторам памяти никогда не будет много.
4k * 4k * 4 = 64 мб
Берём с Википедии таблицу вореций. Зожимаем до нижней и верхней границ: 7e6 пикселей и 12.8e6 пикселей; кобенируем по 4 байта на пиксель - 28e6 и 51.2e6 бат; приводим на 1024 - 26.7 и 48.8 мега бат; натализируем числа для круглования: для кадра 4К нужно 26-49 мега бат.
[смотрит с ворцищённым ворежением лица]
Браво!
Хан Мега-Батый.
А что он там делает? Страничку и список зависимостей храни и все
ты про что?
я про страничку с ячейками и зависимостями ячеек для пересчета, а ты про что? Это типа мой вопрос
полный пересчет целого шита может >5 секунд занимать с легкостью.
некрософт не от хорошей жизни там многопоточность & 1M rows поддерживает. прежде чем для симуляции какую программу кодировать, профи гоняют формулы в эксэле.
кэширование - для реализации мат функций, что бы не каждый раз с пустого считать начинать.
представь себе что у тебя 100К строк с данными в десятках столбцов, и в результате считаются несколько десятков простеньких фурье трансформаций. или какой грёбаный монте-карло с 100К сэмлами.
автопересчет мешает если надо менять несколько (например) коэфицентов одновременно.
Про печальные окамлооптимизации я вообще молчу.
Особенно на всяких std::vector с указателями в кучу и прочих linked list & queue.
http://www.slideshare.net/andreialexandrescu1/three-optimization-tips-for-c-15708507
Страница 16
Царь же делал тут доклад о "единственно полезной структуре данных".
Массив? Ну что еще школьник то мог предложить, когда ни одного приложения еще не написал
Слова не Школьника, но Настоящего Программиста.
The x32 ABI is an application binary interface (ABI) and one of the interfaces of the Linux kernel. It allows programs to take advantage of the benefits of x86-64 instruction set (larger number of CPU registers, better floating-point performance, faster position-independent code shared libraries, function parameters passed via registers, faster syscall instruction) while using 32-bit pointers and thus avoiding the overhead of 64-bit pointers.
Though the x32 ABI limits the program to a virtual address space of 4 GiB, it also decreases the memory footprint of the program, and in some cases, can allow it to run faster. The best results during testing were with the 181.mcf SPEC CPU 2000 benchmark in which the x32 ABI version was 40% faster than the x86-64 version. On average, x32 is 5–8% faster on the SPEC CPU integer benchmarks compared to x86-64. There is no speed advantage over x86-64 in the SPEC CPU floating point benchmarks.
It allows programs to take advantage of the benefits of x86-64 instruction set (larger number of CPU registers, better floating-point performance, faster position-independent code shared libraries
"larger number of CPU registers" - да.
"better floating-point performance" - нет.
"faster position-independent code shared libraries" - нет.
и два последних "нет" ничего общего с 32 vs 64 не имеют. просто обычный 32 бит режим сидит на уровне совместимости со всеми актуальными 32 бит процами, почему и не может некоторыми фичами (типа новые SSE, или CMOV) пользоваться. с другой стороны, х32 может пользоватся новыми фичами, потому что старые 32 бит проца в принципе не поддерживает.
находил переписки гцц/либц разрабов на эту тему, и народ просто решил что апдейт 32 бит ABI не имеет смысла. потому что кучи народа все еще пользуются процами со старыми 32 бит ядрами (те же атомы интеловы), в то время как новым пользователям, на большинстве приложений, выгода очень маленькая (народ цитировал gcc бенчи в районе 1-2% разницы).
я знаю что кучи дисто на это дело забили, потому что надо еще одну иерархию в /usr заводить, и с этим всегда много граблей в особенности в начале.
Они имели ввиду новые SSE/AVX с широкими регистрами.
Хотя согласен что выигрыша особо нет. Число исполнительных блоков такое же.
Профит только в меньшем количестве команд на то же кол-во данных. И даже не двухкратный. Поскольку команда для 128 битного SSE короче команды для 256 битного.
и что эти "SPEC CPU integer benchmarks" умеют делать? интернет бравзить? музыку/видео прогрывать? компилировать?
о, да, это пустой бенчмарк.
ежику понятно что х64 будет медленее чем х32. но это точно также как и utf-8: utf-8 медленее чем ucs4, но все равно все им пользуются, потому что удобнее.
Для хранения и передачи. Если строку надо редактировать, то её переводят в fixed-wifth. Даже Питон ЕМНИП внутре с утф8 не оперирует.
Fix x86-64 ABI conformance issue in SIMD code
(descriptions cribbed by DRC from discussion in #20)
In the x86-64 ABI, the high (unused) DWORD of a 32-bit argument's
register is undefined, so it was incorrect to use a 64-bit mov
instruction to transfer a JDIMENSION argument in the 64-bit SSE2 SIMD
functions. The code worked thus far only because the existing compiler
optimizers weren't smart enough to do anything else with the register in
question, so the upper 32 bits happened to be all zeroes-- for the past
6 years, on every x86-64 compiler previously known to mankind.
The bleeding-edge Clang/LLVM compiler has a smarter optimizer, and
under certain circumstances, it will attempt to load-combine adjacent
32-bit integers from one of the libjpeg structures into a single 64-bit
integer and pass that 64-bit integer as a 32-bit argument to one of the
SIMD functions (which is allowed by the ABI, since the upper 32 bits of
the 32-bit argument's register are undefined.) This caused the
libjpeg-turbo regression tests to crash.
Это что, типа, разные указатели?
Вообще-то это известный трюк
By far the best part in retrospect—and the worst part at the time—was getting the core C/assembly code to fit. We were literally days away from the drop-dead date for the "gold master"—our last chance to make the holiday season before we lost the entire year—and we were randomly permuting C code into semantically identical but syntactically different manifestations to get the compiler to produce code that was 200, 125, 50, then 8 bytes smaller. Permuting as in, "for (i=0; i < x; i++)"—what happens if we rewrite that as a while loop using a variable we already used above for something else? This was after we'd already exhausted the usual tricks of, e.g., stuffing data into the lower two bits of pointers (which only works because all addresses on the R3000 were 4-byte aligned).
Первая плойка (статью ещё не читал)?
Там кстати Lisp есть
Класс!
Да, были люди в наше время,
Не то, что нынешнее племя:
Цари — не вы!
Плохая им досталась доля:
Не будь на то господня воля,
Не отдали б и бит!
Так это самое и предлагается.
Когда закончатся 4Гб, адресовать не байтами, а выравняными 64-битными словами. 32Гб при 32-битной адресации.