- 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
type int = 1;
function makeRangeIterator(start = 0, end = 10000, step = 1) {
print("makeRangeIterator.");
let nextIndex = start;
let iterationCount = 0;
const rangeIterator = {
next() {
let result: [value: int, done: boolean];
if (nextIndex < end) {
result = [nextIndex, false];
nextIndex += step;
iterationCount++;
return result;
} else {
result = [iterationCount, true];
}
return result;
},
};
return rangeIterator;
}
function main() {
let it = makeRangeIterator(1, 10, 2);
let result = it.next();
while (!result.done) {
print(result.value); // 1 3 5 7 9
result = it.next();
}
print("done.");
}
Ну вот и все... позвольте мне представить самый сложный кусок когда либо компилированный моей программой. но ввиду того что "трамплины" хрен знает как работают то придется этот код "забанить" до лучших времен. Но он рабочий
Follow us!
А ты читал стандарт?
>И что такого в JS крамольного чего нельзя на крестах сделать?
Не понял этой фразы.
На JS очень много чего нельзя сделать, что можно на крестах.
Если Лолечка пишет на крестах как на JS (без шаблонов, умных указателей, предсказуемых деструкторов, объектов на стеке и пр) то может ему и правда кресты не нужны
> На JS очень много чего нельзя сделать, что можно на крестах
Борманд, переведи. Я тебя обычно хорошо понимаю
2) exists x, not (works_in_js x) /\ works_in_cxx x
С другой стороны, на жс тоже можно написать конпелятор няшной...
https://bellard.org/jslinux/
Предлагаю писать на bat файлах
Сами команды вполне так ascii: 0x31 (write memory) и 0x21 (go). Но дальше вторым байтом надо передать их дополнение. И вот оно уже по определению не ascii т.к. в старшем бите будет единичка.
Ну разве что под какой-нибудь ARM'овский SoC с четырьмя ядрами, чтобы потренироваться в беге с барьерами...
Пиши тогда скорее, а то опопсится всё, и будет как x86, чтобы каждая макака моглда
Все, бегом в машину Тьюринга!
JS - это один большой шаблон. все обьекты - это умные указатели. предсказуемые деструкторы не нужны там нет прямой работы с ресурсами. обьекты на стеке тоже не нужны даже в с++. как в маленький стек можно впихнуть 2гб данных?
Шаблоны это технология метапрограммирования, которая позволяет генерировать классы и функции, которые затем статически диспатчатся, а JS это язык программирования без статической типизации.
Не понятно как одно может быть другим.
> все обьекты - это умные указатели
Умные указатели в C++ бывают нескольких видов: одни гарантируют свою уникальность, другие реализуют reference counting давая программисту предсказуемый вызов деструктора.
Ни то, ни другое объекты JS не делают.
> деструкторы не нужны там нет прямой работы с ресурсами.
В смысле в JS никогда не нужно закрывать файл или сокет?
Но это не так
https://www.geeksforgeeks.org/node-js-fs-close-method/
https://developer.mozilla.org/en-US/docs/Web/API/WebSocket/close
> обьекты на стеке тоже не нужны даже в с++.
Это не правда: нет смысла размещать объект не на стеке, если ты не собираешься использовать его за пределами функции, и если он не слишком большой.
>как в маленький стек можно впихнуть 2гб данных?
C++ поддерживает объекты размером менее двух гигабайт данных.
почему вы решили что доступ к стеку быстрее доступа к heap? вроде чипы памяти одни и теже и время доступа там одна и тажа. или вы не умеете использовать стек в хипе? ну получается мифическая вера в размещении на стеке это "просто боговерования". т.к. не дает преимущества ни в скорости использования ни в способе размещения объектов
Не доступ, а выделение.
Выделение памяти в стеке это просто изменение значения одного регистра, а аллокатор в куче гораздо сложнее.
Доступ к уже выделенной памяти не должен сильно отличаться.
https://publicwork.wordpress.com/2019/06/27/stack-allocation-vs-heap-allocation-performance-benchmark/
точно? чем это он сложнее?
1) *stack = malloc(100000000000)
2) stack++, stack--
все... что тут сложного? new (stack) Class1? что тут еще сложнее?
Разве что отделить стек возвратов от стека данных ради безопасности. И то сомнительно.
З.Ы. А, ну всё, пора спать. Просто чтобы отвязать время жизни объектов в самодельном "стеке" от фреймов функций в реальном стеке.
Я могу еще рассказать про всякие там арены и прочую такую хуйню, но у меня нет сейчас желания устраивать лекцию на эту тему
Именно по такому принципу сделан young gen в «Йаже» и прочей мусоросборной питушне.
Есть джва указателя: на начало и конец стека. Когда он заполняется и приходит время чистить говно, живые объекты просто копируются, а в указатель конца стека присваивается начало.
Такие операции как mov; xor eax,eax; push и pop, просто выпиливаются не доходят до портов исполнения, даже не превращаются в МОПы.
x86 has dedicated stack machine operations. Instructions such as PUSH, POP, as well as CALL, and RET all operate on the stack pointer (ESP). Without any specialized hardware, such operations would would need to be sent to the back-end for execution using the general purpose ALUs, using up some of the bandwidth and utilizing scheduler and execution units resources. Since Pentium M, Intel has been making use of a Stack Engine.
The Stack Engine has a set of three dedicated adders it uses to perform and eliminate the stack-updating µOPs (i.e. capable of handling three additions per cycle).
Instruction such as PUSH are translated into a store and a subtraction of 4 from ESP. The subtraction in this case will be done by the Stack Engine. The Stack Engine sits after the decoders and monitors the µOPs stream as it passes by.
Incoming stack-modifying operations are caught by the Stack Engine. This operation alleviate the burden of the pipeline from stack pointer-modifying µOPs. In other words, it's cheaper and faster to calculate stack pointer targets at the Stack Engine than it is to send those operations down the pipeline to be done by the execution units (i.e., general purpose ALUs).
Какое пафосное название для сумматора.
З.Ы. На RISC'ах автоинкремент вроде тоже через отдельный сумматор?
https://godbolt.org/z/4rzsoqbTf
Его создает OS. Хочешь чтоб я тут лекцию про виртуальную память бесплатно написал? Погугли про эту хуйню, ну там про виртуальную память, как например то же ядро Linux парсит ELF файл, выделяет ему какую-то там память
malloc() это не какая-то первичная сущность, в Linux это обертка над mmap() и возможно что над brk() или еще какой-то такой хуйней, в винде это вообще какая-то лютая поебень. https://govnokod.ru/27497#comment643764 - там эту хуйню вроде обсасывали
Нативный стек ускорен на железячном уровне. Быстрее написать просто нельзя.
Ручной стек (даже предварительной выделенным куском памяти) и всё-равно будет чуть медленее.
Как минимум потому что там ручками нужно двигать аналог ESP и потом ещё лазить в память за данными.
А PUSH и POP это короткие 1-2 байтовые инструкции, которые автоматом и счётчик меняют, и двигают данные между регистрами и стеком.
Куча универсальна, следовательно с ней всегда можно насоздавать патологических случаев, которые озадачат любой аллокатор. Стек максимально ограниченный, тупой и быстрый.
Никаких "современных альтернатив" тут особо не придумать. Все эти т.н. "современные альтернативы" - давно обсосанная в компутер саенсе хуйня.
Да. Вот только потом люди узнают такие слова как: «heap fragmentation» и розовые очки спадают.
А вот стек не фрагментируется. Никогда.
Современные программисты слишком размякли из-за того, что можно когда угодно попросить память, а потом её отдать обратно. Пусть относятся к памяти с уважением, а куча будет быстрой. Освободить её можно и после завершения программы как в PHP.
Никаких тормозов при выделении, никаких тормозов при сборке мусора.
Или алгоритм запатентован и может использоваться только в PHP?
Я наверно понял, почему про PHP распускают всякие слухи. Это всё конкуренты-завистники, которые хотят продать пользователю язык с медленной работой с памятью на фоне более совершенного языка.
Мудрый Царь уже всё объяснил — его тупо заминусовали, затроллили и обсмеяли.
Я недавно смиренно повторил Царское Слово: аллоцируем либо slab.
По сути это отдельные типизированные кучки, с возможностью освободить память где-то в средине.
Т.к. они принимают однотипные объекты, то проблем из-за фрагментации не будет.
Ну либо страницами mmap, тогда и realloc (mremap) бесплатный O(1) вместо O(N).
И фрагментация есть но страничная, и там виртуальной памяти до чёрта потому проблем с выделением куска нужного размера быть не должно.
Там тоже O(N) в общем случае всё-таки. Просто N в 500 раз меньше.
Не, ну в теории можно и за О(1), если оставлять достаточно места и ремапать только целыми поддеревьями.
Начинаем с 4к. Если 4к оказалось мало, ресайзим сразу до 2М и потом до 1Г. А дальше можно гигабайтными кусками двигать.
>А дальше можно гигабайтными кусками двигать.
Так всё-равно O(N) при достаточно больших N.
Я кстати пробовал гигабатные куски, для программы которая выделяла по 8-16 гиг.
У них пирфоманс оказался ХУЖЕ чем у 2М.
Возможно это связано с очень лимитированным TLB для гигабатных страниц или сырой реализацией в Линуксе.
Но оптимальный перфоманс был именно на 2M.
TLB промах будет только при росте на следующую ступень, так что не так уж и страшно выглядит. По сути всего 3 раза TLB кеш дропнется. Ну и дальше каждый гигабат.
Кстати, представь как быстро будут своповаться гигабайтные странички... Это прям игра ва-банк.
> Так всё-равно O(N) при достаточно больших N.
Ну там уже такой делитель, что насрать. На терабайте всего тыщу записей пофиксить.
Шведы смешные) У меня знакомый админ списанную технику прямо на авито и размещает
Но я не советовал бы домой юнитовый сервер брать без надобности: очень много ебли с ним: память он будет хотеть ECC, диски будет не поддерживать неправильных производителей/типов, прошивка у него такая, что надо мануал на тридцать страниц читать, грузится по четыре минуты, гудит как боинг...
У некоторых ноутбуки в таком состоянии.
Да, Vista на 1GB памяти с HDD 5400 и антивирусом
Если у тебя SSD, то скорее всего скорость загрузки не будет твоей проблемой даже на сраных EVO
Если HDD, то тебя ждет ад сломанных бутпланов, xperf xbootmgr и пр
Иными словами, HDD не нужен
Ещё бывает, что скорость загрузки зависит от порядка, в котором стартовала питушня из автозапуска. Иногда помогает назначение какой-нибудь службе отложенного запуска или вообще запуска «вручную», чтобы она стартовала только по явному запросу от других программ.
*****
Кстати, я понял, почему у меня техника в режиме AHCI тормозила, а в режиме эмуляции IDE летала. Я рассказывал о спонтанных зависаниях и о загрузке процессора на 100% в режиме AHCI, даже когда обращения к диску не было.
Причина была в «Intel Rapid Storage Technology». Это говно, как я понял, вообще предназначено для RAID. Почему его пихают на всю технику, включая ноутбуки и нетбуки, я не знаю.
Стёр «Intel Rapid Storage Technology» — с микрософтовским драйвером AHCI в режиме AHCI подвисания прекратились. После этого режимы AHCI и эмуляции IDE стали работать примерно с одной скоростью.
А каким-то конкретным процессом или System?
В ProceXP можно посмотреть Interrupts. Может быть это ебланит драйвер или железка с interrupts storm?
>Иногда помогает назначение какой-нибудь службе отложенного запуска
Ну тогда она тебя в систему пустит, потом будет тупить уже когда ты увидишь рабочий стол. Тоже мало приятного.
Я советую изучить ``xperf`` (Это часть WPT). Там профилируются все стадии загрузки и процессы и доступ к диску и вообще обычно понятно, что происходит.
Но как с любым профилировщиком нужно ебаться пару ночей, чтобы научиться им пользоваться.
На хабре и www.outsidethebox.ms были статьи про него.
> Intel Rapid Storage Technology»
Интелловый контроллер (встроенный в чипсет) умеет в два режима: AHCI и недорейд (полусофтварный рейд типа как винмодем). Ну еще он умеет в эмуляцию IDE, но это не важно.
Так вот выбор драйвера для него это отжельный челленж.
В какой-то момент они перешли на новую версию драйвера (IRST -- Intel Rapid Storage) (вместо одного файла стало миллион) и он стал работать ХУЖЕ
https://www.win-raid.com/t2f23-Intel-RST-RSTe-Drivers-latest-v-WHQL-v-WHQL.html
Disadvantages of the IRST Software installation:
1. extension of the boot time
(вообще советую ссылку почитать, там подробно питушня с этим разбирается)
Вот тут админы виндофайловых паомоек реально тестируют версии драйвера и выбирают его:
https://www.win-raid.com/t25f23-Which-are-the-quot-best-quot-Intel-AHCI-RAID-drivers.html
https://www.win-raid.com/t362f23-Performance-of-the-Intel-RST-RSTe-AHCI-RAID-Drivers.html
Ну вот я на нескольких машинах (родственники иногда просили узнать, из-за чего тормоза) заменил «IRST» на «generic», и стало работать быстрее.
>> полусофтварный рейд типа как винмодем
Возможно, в этом и разгадка.
А зачем нужен режим рейда на портативной технике с одним слотом под накопитель?
>> Вот тут админы виндофайловых паомоек реально тестируют версии драйвера и выбирают его
Я как-то тестировал версии интеловского видеодрайвера: в одной версии одну вещь сломали, в другой — другую. После проверки десятка версий решал, какая из них менее хуёвая. Некоторые версии забывали настройки после перезагрузки.
Чтобы продавать говнище с SSD на 20 гиг и хдд под остальное. В теории, IRST может превратить это в более-менее рабочий конфиг, юзая SSD как кеш. Что там на практике -- хер знает.
Не суть, тут как со свопом главное -- это working set. Если ты активно юзаешь меньше 20 гиг, то будет норм. Это не 20 гигов под систему, это 20 гигов под горячие данные.
Хардварные рейды тоже так умеют, иногда только за деньги)
Никогда не пробовал, кстати. Тока читал, и вечно путал с readyboot (префетчером).
Знаю, что у одного IBMовского рэйда поддержку SSD кеша (тн CacheCade) покупали за бабло
Не помню, как на неё выходил. Кажется, где-то в хелпе вылезло.
Только потом говорит "да хрен тебе, слишком медленная флешка" или "да хрен тебе, и так всё быстро работает". Там наверно нужен тарасокомп или два ядра/два гига от разводилы-продавца с Авито. Или флешка из будущего, которая стоит дороже всего компа вместе взятого.
Мог бы и на старый драйвер Intel откатить, который без SCSI фильтра (это есть в статье).
> А зачем нужен режим рейда на портативной технике с одним слотом под накопитель?
Не знаю, по моему ни за чем не нужен. На десктопе еще как-то можно понять зачем...
Блядь, как всё сложно.
Because of the big structural and functional differences between the "classical" Intel RST driver (just using the iaStor.sys) and the newer Intel RST(e) drivers (using iaStorA.sys and additionally the SCSI driver iaStorF.sys), users should be very restrictive regarding the switch from one driver sort to the other
у меня так прыщи грузятся
и чем больше в пертинентный раздел записано, тем больше глюков и тормозов
Ну формально всё-равно O(N).
Я проверял на Хасвеле, это по-моему первое поколение куда завезли 1G страницы.
Кстати нагуглил сайт с бенчами 7z.
И у них тоже почему-то для Хасвела нету результатов теста 1G
Зато есть для следующих поколений.
Может там какой-то баг был или добавился L2?
По-моему они не свопаются. Ну по крайней мере как я тестировал.
Выделял через механизм hugetlb pool, там оно сразу выделяет нужное количество страниц и отжирает соответствующий объём памяти.
Тут Пи может быть спокоен
Даёт. Верхняя часть стека всегда горячая, она в кеше, она постоянно реюзается, она локальна для треда. Поэтому мелкие локальные объекты на стеке работают очень быстро, они даже за пределы процессорного ядра не выходят. Даже сраная джава старается джитить мелкие объекты так, чтобы не выделять их в куче. Какие-то из них вообще могут в регистры поместиться.
В FreeRTOS есть например https://www.freertos.org/xTaskCreateStatic.html
puxStackBuffer - Must point to a StackType_t array that has at least ulStackDepth indexes (see the ulStackDepth parameter above) - the array will be used as the task's stack, so must be persistent (not declared on the stack of a function).
Во всяких posix-совместимых ОС например есть https://linux.die.net/man/3/pthread_attr_setstack для тредов, ну и естественно ОС как-то там выделяет стек при запуске ELF файла. В виндопараше это надо отдельно уже смотреть, как эти обмудки там в своем винапи это реализовали.
https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createthread - тут вроде нет возможности указать адрес где стеку расти
Нет, не везде. В контроллерах бывает отдельная память под стек.
В x86 есть особая срань чтобы это кешировалось
https://www.agner.org/optimize/microarchitecture.pdf
3.16 Returns (all processors except P1)
...
The P1 has no return stack buffer, but uses the same method for returns as for indirect
jumps. Later processors have a return stack buffer. The size of this buffer is 4 in the PMMX,
8 in Atom, 12 in AMD k8, 16 in PPro, P2, P3, P4, P4E, PM, Core2 and Nehalem, and 24 in
AMD k10. This size may seem rather small, but it is sufficient in most cases because only
the innermost subroutines matter in terms of execution time. The return stack buffer may be
insufficient, though, in the case of a deeply nesting recursive function.
In order to make this mechanism work, you must make sure that all calls are matched with
returns. Never jump out of a subroutine without a return and never use a return as an
indirect jump. It is OK, however, to replace a CALL MYPROC / RET sequence with JMP
MYPROC in 16 and 32 bit mode. In 64 bit mode, obeying the stack alignment standard, you
can replace SUB RSP,8 / CALL MYPROC / ADD RSP,8 / RET with JMP MYPROC.
поэтому я за text/javascript
> Ни то, ни другое объекты JS не делают.
Symbol is a built-in object whose constructor returns a symbol primitive — also called a Symbol value or just a Symbol — that’s guaranteed to be unique.
Опа!
Именно поэтому я за захват локалок по значению, а не по ссылке.
А извращения с захватом локалки по ссылке мало кому нужны, от них только грабли на ровном месте... Хотя жсники эту фишку довольно часто абузят для "модулей". Нормальную инкапсуляцию то не завезли.
Йажа вообще посмотрела на багры C#/js и ввела impicit final.
Всё что хватает замыкание становится неявной константой (final можно не писать, просто при втором присваивании будет ошибка конпеляции).
Полез изучать этот вопрос и ничего не понял. На «x86» эта функция вообще ничего не делает, потому что инструкции INVD и WBINVD можно выполнить только из нулевого кольца защиты (т. е. из драйвера, а не из пользовательской программы). Вроде на каких-то процессорах (на «ARM»?) аналогичную инструкцию можно выполнить из пользовательской программы, но зачем, я пока не понял.
Не программисты, а гавно
В основном энергопотреблением и размером кристалла... По пирфомансу оно вроде норм.
Её где-то можно купить без госзаказа?
> греться особо нечему
Там нет транзисторов? ;)
Не, ну их меньше само собой, раз огромный кусок процессора унесли в конпелятор. Но сопоставимый по пирфомансу х86 тоже не особо греется, наверное?
И правда.
все 4 штуки
И ещё всякими Meltdown. Когда вроде прочищается, а вроде и нет.
Какой царь )))
Это же наш гост
>Какой царь )))
Какой tiny mode ))
http://govnokod.ru/13162#comment180767
Ещё тут было весело:
https://govnokod.ru/13183#comment181849
В «Ideone» царские программы не запускались, потому что в «Ideone» компилятор с защитой стека типа «Stackguard» или «Propolice» (в новых версиях «gcc» вроде уже что-то штатное похожее накрутили).
Царь снизошёл к вам чтобы поделиться своей мудростью. Чем же вы отплатили неблагодарные глупцы? Плевками и завистью.
> В «Ideone» царские программы не запускались
Потому что «Ideone» недостаточно хорош для Царских Программ.
https://govnokod.ru/13183#comment182519
https://govnokod.ru/13183#comment182518