Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы		[ Отслеживать ]

Проект LLVM развивает средства для безопасной работы с буферами в C++, opennews (?), 06-Окт-22, (0) [смотреть все] Это ещё зачем, глупых растоманов наслушались vector и так кидает экспешон при в, Аноним (2), 11:07 , 06-Окт-22, (2) –1 // На этапе компиляции , Аноним (3), 11:08 , 06-Окт-22, (3) +12 // И после таких вот заявлений растоманы хотят кого-то уверить что у них код быстре, bOOster (ok), 13:05 , 06-Окт-22, (46) // Так проверки в дебаге Код может быть местми быстрее из-за большего скоупа для а, анонимус (??), 13:40 , 06-Окт-22, (59) Когда индекс массива зависит от внешних данных а это чуть менее, чем всегда , п, Аноним (129), 19:15 , 06-Окт-22, (129) –3 Comdiv, предлагает такое решение этой проблемы для будущих языков http safe-pr, Tita_M (ok), 19:59 , 06-Окт-22, (135) +2 Костыль на костыле, костылем погоняет А по факту - опыт и чуть больше вниматель, bOOster (ok), 08:10 , 07-Окт-22, (175) –2 Понятно Ответить нечего Правда, там его вариант Оберона по скорости почти не п, Брат Анон (ok), 08:34 , 07-Окт-22, (181) +5 Где это в повседневной эксплуатации Кнут тоже аналитику алгоритмов проводил - т, bOOster (ok), 09:23 , 07-Окт-22, (188) –2 У тебя с логическим мышлением явные проблемы Причём здесь алгоритмы, до ошибок , Прохожий (??), 08:29 , 08-Окт-22, (227) +3 Кстати, С в силу своей специфики конструктор деструктор много безопаснее чем ч, bOOster (ok), 09:40 , 07-Окт-22, (189) –4 Программист вообще не должен думать, когда бы ему память получить, а когда освоб, Брат Анон (ok), 08:24 , 10-Окт-22, (255) +3 Вот это бреднятина, если ты работаешь в 1C, и всяким фронтендом тогда да, но это, bOOster (ok), 09:32 , 10-Окт-22, (256) –2 И ножи запретить, ими же порезаться можно , Аноним (-), 12:47 , 12-Окт-22, (262) –2 Лучше постоянные проверки в рантайме, чем крвх или взлом , YetAnotherOnanym (ok), 15:03 , 06-Окт-22, (80) +4 Насмешил - имхо rust будут ломать чаще , bOOster (ok), 15:55 , 06-Окт-22, (88) Он для этого и создан если кто не понял Притянул из интернета пару гигабайт зав, Аноним (123), 17:47 , 06-Окт-22, (123) +2 Можно притянуть локально Кто мешает А мне кажется, что у вас приступ НИНУЖНА ,, Аноним (130), 19:19 , 06-Окт-22, (130) +4 Ты давно из исходников собирал что-то, изучая перед этим код - дабы быть уверенн, bOOster (ok), 08:23 , 07-Окт-22, (180) Даже если это так, то какая претензия тогда к расту Скачав библиотеку для крест, Аноним (212), 16:32 , 07-Окт-22, (212) +1 Да дело в том что раст ремесленники сродни 1С программистам - зачастую не знают , bOOster (ok), 16:57 , 07-Окт-22, (215) –1 Исходя из чего это следует, о Великий воин супротив Раста , Прохожий (??), 08:33 , 08-Окт-22, (229) –1 На основе чего ты пришёл к такому туповатому выводу , Прохожий (??), 08:30 , 08-Окт-22, (228) К большому сожалению будут постоянные ошибки в алгоримах, которые точно также пр, eganru (?), 19:52 , 06-Окт-22, (133) А можно какие-нибудь цифры или исследования Просто анализ от Майкрософта показа, Аноним (130), 20:17 , 06-Окт-22, (138) +2 Майкрософт это не про программирование - это про бизнес И применять эти сведени, bOOster (ok), 08:12 , 07-Окт-22, (176) А в open source какие-то особенные люди, которые не допускают ошибок с памятью и, Аноним (212), 16:35 , 07-Окт-22, (213) А серое вещество включить Или на Майкрософт работаешь Open source - майнтейнер, bOOster (ok), 16:49 , 07-Окт-22, (214) –1 Тебе бы самому не помешало включать серое вещество Что МС, что другие корпораци, Прохожий (??), 08:26 , 08-Окт-22, (226) –2 А ещё лучше -- железо спроектированное под эти проверки, и язык, который на 146 , Брат Анон (ok), 08:38 , 07-Окт-22, (183) +2 Осталось придумать где его такое взять Интел вообще пытался, но - не зашло Rust, Аноним (-), 14:20 , 12-Окт-22, (263) –2 Нет, Интел даже не пытался За тебя уже всё придумали Просто бери и пользуйся Н, Брат Анон (ok), 08:28 , 14-Окт-22, (278) +1 Железо такое есть, эльбрус называется Там есть специальный режим, в котором про, alexhz (?), 00:38 , 26-Дек-22, (279) Хотя чаще до 20 Ну и ещё проблема, код с хаками не работает В итоге, только с, alexhz (?), 00:43 , 26-Дек-22, (280) std vector T,Allocator atReturns a reference to the element at specified loca, anonimous (?), 22:18 , 07-Окт-22, (221) –1 Только по at i , и этой функцией мало кто пользуется , topin89 (ok), 11:10 , 06-Окт-22, (4) +4 // а вы берете указатель от data и дальше используете арифметику с указателем , null (??), 11:14 , 06-Окт-22, (6) +1 // operator вам о чем-нибудь говорит , anonymous (??), 11:20 , 06-Окт-22, (8) +12 зачем, если есть at , null (??), 11:24 , 06-Окт-22, (12) +2 зачем нужен ты, если есть GPT-3 , Аноним (19), 11:38 , 06-Окт-22, (19) +13 Согласен Null не нужен, столько багов из-за него , trolleybus (?), 12:41 , 06-Окт-22, (41) Давайте разыминуем анона выше , Аноним (84), 15:41 , 06-Окт-22, (84) +1 Зачем тебе разыменованный троллейбус И что это делает , Аноним (-), 14:41 , 12-Окт-22, (264) Gfortran -fcheck all, pashev.ru (?), 11:13 , 06-Окт-22, (5) –1 // Собственно, уже давно есть GLIBCXX_HARDENED, по умолчанию включенный в Федоре и , qetuo (?), 18:55 , 06-Окт-22, (128) +2 Одна небольшая доработка, а целый ЯП, придуманный только для безопасной работы с, Бывалый смузихлёб (?), 11:14 , 06-Окт-22, (7) –2 // А что, LLVM в кресты встраивают борроу чекер Проблем с лайфтаймами больше не бу, гость (?), 11:22 , 06-Окт-22, (9) +6 // Если тебе нужен боров в чекере ты его можешь сам присобачить в любой момент htt, Аноним (18), 11:37 , 06-Окт-22, (18) // Ща начнется визг, что ваш 6Ч, не тот бЧ , анон (?), 14:56 , 06-Окт-22, (74) +1 Давно есть, std unique_ptr называется , Аноним (40), 12:38 , 06-Окт-22, (40) +4 Закатывай губу назад , Шарп (ok), 11:23 , 06-Окт-22, (11) // В том языке аналогичная проверка тоже происходит во время выполнения, Man11300 (?), 12:14 , 06-Окт-22, (30) Будет короче тормозить еще больше из за постоянных проверок Голые указатели при, Аноним (10), 11:23 , 06-Окт-22, (10) +7   // сиплюсплюсовцы же, Анусимус (?), 11:37 , 06-Окт-22, (16)   // А еще ассерты есть И вообще работать с буфферами неявного размера, как это прин, Аноним (10), 11:49 , 06-Окт-22, (21)   // C и C это разные языки , Аноним (23), 11:54 , 06-Окт-22, (23) +3   Не может быть , Аноним (129), 19:20 , 06-Окт-22, (131) +1   Си разный бывает В каком-нибудь MISRA например много чего НЕ принято И это как, Аноним (265), 14:52 , 12-Окт-22, (265)   Проверка диапазона не ресурсоёмкая, и на некоторых платформах даже аппаратная Во, _kp (ok), 12:03 , 06-Окт-22, (25) +3   // Не бывает бесплатных проверок, даже за защищённый режим процессора с его виртуал, none7 (ok), 14:30 , 06-Окт-22, (67) +1   // Столько нового и интересного узнаёшь на Опеннете То есть виртуальная память ино, n00by (ok), 14:52 , 06-Окт-22, (73) –3   Нет, процессору же приходится гонять виртуальные адреса через таблицу страниц дл, none7 (ok), 15:03 , 06-Окт-22, (79) +2   Исключение потому так и называется, что генерируется в исключительных случаях Т, n00by (ok), 16:21 , 06-Окт-22, (95)   Вот кстати в голодные времена провайдеры вместо Cisco использовали ПК с Linuxи о, Аноним (102), 16:34 , 06-Окт-22, (102)   Осталось написать дату тех времён и характеристики железа - что бы можно было пр, n00by (ok), 16:01 , 08-Окт-22, (241)   А если посмотреть талмуд, то она делает совсем другое - генерирует исключение B, n00by (ok), 15:00 , 06-Окт-22, (78)   Она даёт исключение при выходе за границы проверки, а не всегда , none7 (ok), 15:06 , 06-Окт-22, (81) +1   Что бы 171 естественно времени она занимает столько же как и пара cmp j ab 1, n00by (ok), 16:14 , 06-Окт-22, (93) –1   Естественно ситуация выхода за пределы массива является серьёзной ошибкой и не т, Аноним (102), 16:25 , 06-Окт-22, (96) +1   Так для этого надо найти старый тадмуд, где указано время исполнения BOUND Я см, n00by (ok), 16:33 , 06-Окт-22, (101) –1   Этот талмуд идёт в комплекте с masm32 и он у меня под рукойbound - 7 тактов на 4, Аноним (102), 16:42 , 06-Окт-22, (105) +2   Сейчас какой год идёт Не, не так Какой сейчас век , Аноним (129), 02:37 , 07-Окт-22, (164) +1   Да без разницы какой год Основа вычислительного блока в процессорах Intel не ме, none7 (ok), 04:18 , 07-Окт-22, (170)   Откат будет, внезапно, в случае ошибки в программе Что Вы там собрались оптимиз, n00by (ok), 16:05 , 08-Окт-22, (242)   Ага, конечно Интел не настолько дно в разработках , Аноним (-), 15:46 , 12-Окт-22, (269)   У них есть специальная инструкция rdtsc которой можно узнать, сколько тактов зан, none7 (ok), 16:32 , 12-Окт-22, (274)   В действительности rdtsc читает time stamp counter, и есть нюанс The RDTSC instr, n00by (ok), 10:27 , 13-Окт-22, (275)   Да даже для того времени утверждение 171 времени она занимает столько же 187 , n00by (ok), 16:23 , 08-Окт-22, (243)   Данные по cmp и Jxx неактуальны для современного железа У cmp латентность 1, а , n00by (ok), 15:51 , 08-Окт-22, (240)   В защищенном режиме много всякой мути, которая в теории должна жутко тормозить , Аноним (89), 15:56 , 06-Окт-22, (89)   Так чтож, теперь отказаться от защищённого режима Привет, эпоха DOS Сторонние , Аноним (98), 16:29 , 06-Окт-22, (98)   И правда, быстрее же , n00by (ok), 16:35 , 06-Окт-22, (103) –1   Существует архитектура Mill в которой нет виртуальной памяти и много чего другог, Tita_M (ok), 20:08 , 06-Окт-22, (136) +1   Но в реальном мире, кроме FOSS, ещё браузер загружает страницы с тоннами сторонн, Аноним (218), 18:11 , 07-Окт-22, (218) +1   И при всем этом там приколы типа ROWHAMMER могут работать Даже оттуда Который , Аноним (-), 16:10 , 12-Окт-22, (272)   А ещё есть компьютер Спектрум Самый быстрый там вариант - самомодифицирующийся , n00by (ok), 16:33 , 08-Окт-22, (244)   В реальном мире вооон те игроделы бьют рекорды по скорости декомпресии vs плотно, Аноним (-), 15:47 , 12-Окт-22, (270)   Можно было, конечно, осталось посчитать, сколько играли в тот 171 Дум 187 на, n00by (ok), 10:54 , 13-Окт-22, (276)   На счёт жутко тормозить это уже слишком безграмотно Если писать эмулятор 386 ,, _kp (ok), 11:00 , 07-Окт-22, (192)   Ну про 90 Вы загнули LDIR - 21 такт на 1 байт LDI - 16 Серия последних немно, n00by (ok), 16:40 , 08-Окт-22, (245) +1   Верно Вдвое быстрее, плюс издержки, это и есть примерно на 90 быстрее Прирост, _kp (ok), 00:23 , 09-Окт-22, (252)   Действительно Как обычно, я налажал с арифметикой Довелось когда-то покодить дл, n00by (ok), 15:58 , 09-Окт-22, (254) +1   Благодарю Взял в коллекцию Смотрю А на Гитхабе меня уже забанили, поэтому ссыл, _kp (ok), 10:46 , 10-Окт-22, (257)   Как забанили Это надо в новости Тут публика любит, когда кого-то банят Ну и в, n00by (ok), 16:34 , 10-Окт-22, (258)   Уже писали про это Хотя, банили якобы сотрудничавших с подсанкционными организа, _kp (ok), 10:34 , 11-Окт-22, (259)   Если забанили на основании решения властей США - тогда им ничего не стоит указат, n00by (ok), 14:41 , 11-Окт-22, (261)   Вообще в компилтайм они условно бесплатные В том плане что это время потратит к, Аноним (-), 15:05 , 12-Окт-22, (266)   Звон-то конечно слышали, но откуда он, не разобрались Заканчивайте уже тащить сл, yet another anonymous (?), 11:12 , 07-Окт-22, (195) +1   что за буфера такие массивы имелись ввиду , Аноним (24), 12:02 , 06-Окт-22, (24) +3 // https ru wikipedia org wiki Буфер, Аноним (98), 12:12 , 06-Окт-22, (29) В заголовке LLVM, а новость про clang Непорядок , Аноним (31), 12:16 , 06-Окт-22, (31) –1 почему бы сразу не писать на чистом Си , darkshvein (ok), 12:24 , 06-Окт-22, (35) +2 // есть же чистый углерод, Аноним (37), 12:29 , 06-Окт-22, (37) +3 // Он невкусный , Аноним (-), 15:06 , 12-Окт-22, (267) Зачем Если например от C можно использовать только классы структуры - и код п, bOOster (ok), 13:02 , 06-Окт-22, (45) +2 // Вся мощь в шаблонах, а ты их не осилил , Аноним (37), 13:05 , 06-Окт-22, (47) // Я их просто не использую Если в большинстве случаев профессионалу хватает обычн, bOOster (ok), 13:08 , 06-Окт-22, (48) –2 Сразу и видно, какой ты профессионал, раз шаблоны не осилил, Аноним (61), 13:43 , 06-Окт-22, (61) –1 Есть знакомые, которые пишут довольно небольшое ПО, ну скажем под встраиваемые у, _kp (ok), 11:13 , 07-Окт-22, (196) Зато я много видел таких профессионалов любителей шаблонов, ваявших такую хрень,, Neon (??), 18:26 , 08-Окт-22, (248) Любители шаблонов обычно пишут совершенно неподдерживаемый код, который трудно о, Neon (??), 18:28 , 08-Окт-22, (249) Как раз таки классы самое ненужное в цпп Когнитивная нагрузка раза в 1 5 снижае, Аноним (40), 13:15 , 06-Окт-22, (51) –5 // Классы позволяют перегружать операторы например и писать vec1 vec2 vec3 вмес, Аноним (61), 13:44 , 06-Окт-22, (62) +2 В нормальных языках пишут vec1 add vec2 add vec3 И редактор кода сможет указать, Аноним (-), 14:08 , 06-Окт-22, (63) +4 У вас синтаксис подразумевает vec1 vec2 vec3 или vec1 vec2 vec3 , ndshu (?), 22:56 , 06-Окт-22, (154) А у вас сложение не коммутативное чтоли Когда оно именно так - это всяко отдель, Аноним (-), 16:12 , 12-Окт-22, (273) Перегрузка операторов как раз самая отвратительная вещь в плюсах , Аноним (70), 14:41 , 06-Окт-22, (70) +2 А ничё, что эта вещь не только в Плюсах имеется Значит, востребована , Аноним (98), 14:51 , 06-Окт-22, (72) Это если применять куда попало, что бы было А бывает, что и необходимо, и при эт, _kp (ok), 11:17 , 07-Окт-22, (197) –1 Типичный ответ приплюснутой макаки Ровный пацан для математики оптимизированный, Аноним (40), 14:56 , 06-Окт-22, (76) –3 Зато потом ровного пацана забивают лопатой, когда код нужно будет перенести на д, Neon (??), 18:30 , 08-Окт-22, (250) Я бы, наоборот, хотел бы найти утилитку, которая анализирует плоскосишный код и , Аноним (98), 14:49 , 06-Окт-22, (71) +1 А как-же конструкторы деструкторы - которые, заставляя программиста возвращаться, bOOster (ok), 10:28 , 07-Окт-22, (190) Классы очень полезны, когда они изолированы и не связаны с остальным кодом как , Аноним (253), 04:05 , 09-Окт-22, (253) Ну напиши, скажем, игровой движок на чистом Си Кармак не просто так к третьему , Аноним (69), 14:37 , 06-Окт-22, (69) +1 // Ваще-то просто так , Аноним (75), 14:56 , 06-Окт-22, (75) просто так и кармак живой пример что на си можно творить чудеса досихпор фиг к, Аноним (-), 15:45 , 06-Окт-22, (85) +2 // Просто так, по доброй воле, на плюсы не переходят Про быстрый обратный корень , Аноним (69), 16:28 , 06-Окт-22, (97) +3 Ага, Кармак изобрёл разложение функции в ряд Тейлора , Аноним (98), 16:39 , 06-Окт-22, (104) Ну тут немного другая математика, но весьма тривиальная Но дело не в этом, а в , Аноним (69), 16:49 , 06-Окт-22, (108) Не важно Поговаривают что комментанрий кстати не его это про тот что рядом со , Аноним (-), 17:43 , 06-Окт-22, (122) А вообще, Анон, приятно видет что есть еще интересующиеся вопросом Заходи на оф, Аноним (125), 18:06 , 06-Окт-22, (125) Увы, нет, фан кодинга в прошлом Да и в прошлом гораздо интереснее был реверсинг,, Аноним (69), 21:11 , 06-Окт-22, (144) Если речь про т н 171 аппаратный алгоритм 187 , то описал его Джон Фон Нейма, n00by (ok), 17:10 , 08-Окт-22, (246) Кармак сказал что квадратичную функцию списал из какого то журнала по программир, Онанистмус (?), 13:11 , 08-Окт-22, (230) Держи - https www youtube com watch v LR3THwlv_r4 Не закончено еще, но процес, Владимир (??), 17:57 , 06-Окт-22, (124) –1 // И прямо в первом кадре видео 8212 файлы cpp Ну ок , Аноним (69), 18:54 , 06-Окт-22, (127) Какой еще срр Там фильм про любовь должен быть Или не та ссылка , Владимир (??), 17:29 , 07-Окт-22, (217) По моему опыту на С быстрее писать , eganru (?), 19:55 , 06-Окт-22, (134) –1 // на С быстрее писать ошибки , Аноним (129), 20:33 , 06-Окт-22, (139) +2 Можно увидеть вашу реализацию быстрой сортировки на чистом Си , Cooler (??), 21:51 , 06-Окт-22, (150) –1 // Все есть на github, Аноним (160), 01:51 , 07-Окт-22, (160) Современные программисты не могут в Си Они способны максимум верстать медленные, Аноним (238), 15:23 , 08-Окт-22, (238) Кому надо - тот давно их использует , Аноним (39), 12:35 , 06-Окт-22, (39) Тормозной C компилятор будет ещё тормознее , Skullnet (ok), 13:11 , 06-Окт-22, (49) +6 // Ах, тормознутая сборка на крестах всегда вызывет боль , Аноним (-), 15:47 , 06-Окт-22, (86) +2 // Какой молоток - такой и Qt , Аноним (129), 19:43 , 06-Окт-22, (132) –2 вы не понимаете, это другое111шланг всё исправит, и можно будет использовать мно, darkshvein (ok), 21:33 , 06-Окт-22, (147) Интересно, чего все так наяривают на скорость компиляции Это вы так черезжoпно к, Аноним (198), 11:21 , 07-Окт-22, (198) –2 // Как бе дааа 8230 Если ли бы ты написал хоть одну строчку кода в жизни, то знал, Аноним (203), 12:05 , 07-Окт-22, (203) +1 // Ну так ты пишешь все что нужно проверить - функцию, класс, модуль, хз на чем ты , Аноним (198), 12:58 , 07-Окт-22, (206) –2 Проблема в компетенции тут у тебя Просто ты манякодер, который не делал никогда, Аноним (260), 10:56 , 11-Окт-22, (260) Это абсолютно несвязанные задачи Любой код должен решать поставленную задачу и , Аноним (198), 13:03 , 07-Окт-22, (207) –1 Вот так выберешь быструю сортировку вместо сортировки пузырьком, а потом окажетс, Аноним (203), 13:32 , 07-Окт-22, (208) +1 Легче оставить дебаг сборку, Аноним (61), 13:42 , 06-Окт-22, (60) // Чтобы тормозило, как в расте , Аноним (129), 20:39 , 06-Окт-22, (141) –2 // Всего лишь как в спарке , Аноним (168), 02:59 , 07-Окт-22, (168) Как только этого плешивого старичка не вытаскивают И один тул напишут к нему И, Alexey Torgashin (?), 14:25 , 06-Окт-22, (65) –9 // А зачем нужен keyword для функции После пистоновских отступов теряетесь в коде , Аноним (70), 14:36 , 06-Окт-22, (68) +2 // Как минимум это позволяет упростить компилятор Н Вирт не зря использовал proce, Tita_M (ok), 20:17 , 06-Окт-22, (137) // Про вместо Function пишут PROCEDURE Функции остались - , U202204161753 (?), 20:38 , 06-Окт-22, (140) Про пишут procedure вместо view А на функции даже смотреть нет смысла , Аноним (168), 03:01 , 07-Окт-22, (169) Так они же ненавидят паскаль и Вирта , Аноним (247), 17:58 , 08-Окт-22, (247) В результате творения Вирта используют лишь для обучения Для реальной работы ег, Neon (??), 18:32 , 08-Окт-22, (251) 1 Для выхватывания глазом функций 2 для парсеров у всяких редакторов кода Та, Alexey Torgashin (?), 22:18 , 06-Окт-22, (151) –1 // Вам гнутые подогнали целый компилятор, а вас парсеры не работают , Аноним (168), 02:57 , 07-Окт-22, (167) +1 Настолько сложно что компилер с сделали в 4 функицях, C4 называется , Аноним (-), 16:06 , 12-Окт-22, (271) Ну вот, сложно же Для простых языков хватает одной , n00by (ok), 10:59 , 13-Окт-22, (277) Так в расте он еще отвратительней раза в 2 , ХрюХрю (?), 14:59 , 06-Окт-22, (77) +7 Шикарно я считаю Даже судя по тутошнему вою медленно, медленно прогеры стану, хрю (?), 15:33 , 06-Окт-22, (82) // А где Если разработчикам надо знать все тонкости вроде не вызываем at - там , Аноним (-), 15:50 , 06-Окт-22, (87) +2 Скрыто модератором, РастаГангста (?), 16:07 , 06-Окт-22, (90) –3 // Скрыто модератором, Аноним (98), 16:58 , 06-Окт-22, (112) Скрыто модератором, Аноним (98), 17:26 , 06-Окт-22, (119) Десятое правило Гринспена вас пожрёт , Аноним (92), 16:12 , 06-Окт-22, (92) Зачем оно нужно когда есть нативные компиляторы под любую платформу , Чел на 939 сокете (?), 17:11 , 06-Окт-22, (116) +5 // Всегда так делаю Исходный код тот же Сборку делаю под конкретную платформу на , Аноним (186), 09:14 , 07-Окт-22, (186) Любой настоящий программист понимает что оно на самом деле бесполезно, Аноним (238), 15:15 , 08-Окт-22, (237) Совсем деградировали современные погромисты Помню как в своё время на ассемблер, Чел на 939 сокете (?), 20:47 , 06-Окт-22, (142) +6 // Никто не мешает вам и сейчас этим заниматься Думаю, с руками такого специалиста, Аноним (69), 21:09 , 06-Окт-22, (143) +2 // Ага, а в Вилабаджио просто поставят 32-битный микроконтроллер и будут праздноват, Аноним (98), 21:12 , 06-Окт-22, (145) // очередную дыру в проекте , Аноним (129), 02:29 , 07-Окт-22, (163) +2 Я уже старый, мне 78, и давно на пенсии, все мои знания устарели, в мире бизнес, Чел на 939 сокете (?), 21:31 , 06-Окт-22, (146) +2 // А какой самый большой проект вы тогда писали Не знаю какую метрику предложить, , Анонн (?), 11:11 , 07-Окт-22, (194) Надо было делать микроядро Тогда бы это был не один монолитный bloat на 30000000, Аноним (160), 11:35 , 07-Окт-22, (200) –1 Лукавит дедуля, Аноним (218), 12:00 , 07-Окт-22, (202) –1 Так может он на 939 только в зуму и солитер играет , Аноним (198), 12:07 , 07-Окт-22, (204) –1 Тут недавно информация прошла Одна команда что-то там изучала и упростила задач, Аноним (186), 09:17 , 07-Окт-22, (187) +1 // Современным программистам не понять что такое оптимизировать каждый байт и кажды, Аноним (160), 11:37 , 07-Окт-22, (201) Любой каприз за ваши деньги , Аноним (69), 14:25 , 07-Окт-22, (211) Любой настоящий программист в первую очередь думает об оптимизации, Аноним (238), 15:13 , 08-Окт-22, (236) Они 8212 нет, а оптимизатор байта 8212 да , Аноним (69), 17:15 , 07-Окт-22, (216) Раньше время работы компьютера было дороже, чем время работы программиста, да и , Аноним (152), 22:20 , 06-Окт-22, (152) +1 // Л - Логика, сынок а ты не думаешь что программы были меньше именно потому что вс, Дональд Кнут (?), 22:54 , 06-Окт-22, (153) +3 // Л - Лениво думать , Аноним (157), 23:10 , 06-Окт-22, (157) +1 Описание современных так называемых программистов, Аноним (160), 02:16 , 07-Окт-22, (161) Ну дык некогда думать, смузи ждёт , Аноним (168), 02:55 , 07-Окт-22, (166) +3 любители смузи совсем разучились думать думать могут только нелюбитили смузи с о, Аноним (173), 07:51 , 07-Окт-22, (173) –1 Программы были не только меньше, они были ПРОЩЕ Не все современные программы ог, Аноним (69), 12:57 , 07-Окт-22, (205) –2 Простота залог надёжности Гуманитарии, палитесь же, сразу видно человек написав, Аноним (223), 04:46 , 08-Окт-22, (223) +3 Что ещё ожидать от растоманов, Аноним (238), 15:11 , 08-Окт-22, (235) Что еще ожидать от современных диградирующих погромистов Наизобретали всяких та, Аноним (173), 07:49 , 07-Окт-22, (172) –2 Ввести массивы на уровне языка Нееее, мы всё в рантайме проверять будем , Аноним (148), 21:36 , 06-Окт-22, (148) –1 // Уточните пожалуйста что это за конструкция языка С int notArray 1, 2, 3 , Аноним (158), 23:17 , 06-Окт-22, (158) –7 // Не поверишь Это указатель с гранулярностью размера int , Аноним (129), 02:27 , 07-Окт-22, (162) +4 // code include iostream using namespace std int main int notArray 1,, Аноним (173), 07:37 , 07-Окт-22, (171) –1 code include iostream using namespace std int main auto pointerAtNotArr, Аноним (173), 08:13 , 07-Окт-22, (177) –1 И это при том что размер массива сохраняется для оператора delete, Аноним (173), 08:16 , 07-Окт-22, (178) delete , учитель, 0x04070407 (?), 11:09 , 07-Окт-22, (193) +7 int notArray 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 int pointer notArray std c, ХрюХрю (?), 08:52 , 07-Окт-22, (184) +33 int notArray 1, 2, 3 - это статический массив std vector - разновидность, minonA (?), 14:12 , 07-Окт-22, (209) // Опеннет эксперт утверждает что в Си нет массивов На опеннет настоящие програм, Аноним (232), 13:46 , 08-Окт-22, (232) –1 Не будут Анон сказал же что это указатель с гранулярностью в int про гранулярн, Аноним (-), 15:25 , 08-Окт-22, (239) Настоящим экспертам-программистам с опеннет проверки не нужны , Аноним (158), 23:04 , 06-Окт-22, (155) // Причем тут эксперты, зачем перекладывать на ресурсы процессора то что ты можешь , Интеллект (?), 23:06 , 06-Окт-22, (156) +6 // Интеллект с опеннет тут же подтвердил это утверждение Настоящие программисты ост, Аноним (158), 23:26 , 06-Окт-22, (159) Ахаха, мы все прекрасно видим как эти головы работают , Аноним (198), 10:40 , 07-Окт-22, (191) +1 Судя по ситуации на опеннет думать головой здесь умеют 3-4 человека, Аноним (160), 11:26 , 07-Окт-22, (199) –1 // Шиз, как ты этих 3-4 чела вычислил на анонимной борде, Аноним (223), 04:49 , 08-Окт-22, (224) +3 Дурачку, тут регистрация есть и они зарегистрированы, Аноним (232), 13:31 , 08-Окт-22, (231) –1 Зашёл CVE на сайт, на котором постят часто новости про CVE, чтобы напомнить, что, CVE (?), 18:26 , 07-Окт-22, (219) // Растоманы и прочие считающие себя программистами персонажи этого не понимают, Аноним (238), 15:10 , 08-Окт-22, (234) Сто лет в обед работает Но да, тем кто не читает про обновление в стандартах л, истина в последней инстанции (?), 18:33 , 07-Окт-22, (220) –1 Зачем добавлять в компилятор лишние проверки замедляющие сбору программ если нас, Аноним (238), 15:08 , 08-Окт-22, (233) 2,5,7,10,24,31,35,39,49,60,65,82,92,116,142,148,155,220,233

Сообщения

[Сортировка по времени | RSS]

10. "Проект LLVM развивает средства для безопасной работы с буфер..."	+7 +/–
Сообщение от Аноним (10), 06-Окт-22, 11:23
Будет короче тормозить еще больше из за постоянных проверок. Голые указатели придумали не просто так. А потому, что проги на асме работали в 10 раз быстрее, чем всякие проги на басике, но хотелось же писать на ЯВУ, а не убивать мозг проблемами аллокешена регистров. Есть простая и тупая вещь. В других языках типа Delphi/Lazarus можно включить проверку границ в отладочном режиме. Есть так же клевые менеджеры памяти типа FastMM, которые в FullDebugMode отслеживают все возможные проблемы с утечками памяти и use-after-free. Это просто Сишники привыкли страдать. А еще говорят, что их язык лучший в мире, ога.
Ответить | Правка | Наверх | Cообщить модератору

	16. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от Анусимус (?), 06-Окт-22, 11:37
	сиплюсплюсовцы же
	Ответить | Правка | Наверх | Cообщить модератору

	21. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от Аноним (10), 06-Окт-22, 11:49
	А еще ассерты есть. И вообще работать с буфферами неявного размера, как это принято в Сях - это плохая идея. Короче это называется культура программирования. Если нанимать индусов на аутсорсе за копейки, то никакие ухищрения не помогут. А в итоге ради так называемой безопасности производительность нативного кода опустят до уровня скряптов. Ну и зачем тогда вообще нужен нативный код? Давайте всех посадим на питон.
	Ответить | Правка | Наверх | Cообщить модератору

	23. "Проект LLVM развивает средства для безопасной работы с буфер..."	+3 +/–
	Сообщение от Аноним (23), 06-Окт-22, 11:54
	C и C++ это разные языки.
	Ответить | Правка | Наверх | Cообщить модератору

	131. "Проект LLVM развивает средства для безопасной работы с буфер..."	+1 +/–
	Сообщение от Аноним (129), 06-Окт-22, 19:20
	Не может быть!
	Ответить | Правка | Наверх | Cообщить модератору

	265. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от Аноним (265), 12-Окт-22, 14:52
	> А еще ассерты есть. И вообще работать с буфферами неявного размера, как > это принято в Сях - это плохая идея. Си разный бывает. В каком-нибудь MISRA например много чего НЕ принято. И это как бы си но как бы здорово другой по надежности если на эти правила не забивать. Всякие void* - ой, вы не указали намерения, как это проверять? Статический анализ в пролете. Туда же массивы неизвестного размера и прочий хлам, где намерения не декларированы. Математика над указателями это вообще зло. Реально легитимных причин это делать есть минимум, типа реализации своего memcpy() или декомпрессора какого. В более приземленном коде это намекает что кодер занимается чем-то не тем. Особенно если в выражение входят разные указатели, нормальные анализаторы на это жутко воют и правильно делают. А если все типизировать нормально - вообще и на сях нормально можно. Чертова куча этого летает в космос, рулит критичными процессами, и в целом факапов можно избежать. Если задаться такой целью. Нет там никаких серебряных пуль, для этого надо всю методологию разработки софта с прицелом под это делать, комплексно. Это назойливо, но вполне эффективно. Если раздолбаить, никакой раст не спасет. И для него эти методологии вообще пока толком не написаны, только-только появляется первое понимание его проблем вообще.
	Ответить | Правка | К родителю #21 | Наверх | Cообщить модератору

	25. "Проект LLVM развивает средства для безопасной работы с буфер..."	+3 +/–
	Сообщение от _kp (ok), 06-Окт-22, 12:03
	Проверка диапазона не ресурсоёмкая, и на некоторых платформах даже аппаратная. Возможность писать особо быстрый код ни куда не исчезает. Но и у системных программистов не во всяком месте нужен особо быстрый код, в ущерб безопасности или времени его написания. Просто по умолчанию предлагается чуть более безопасный подход.
	Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

	67. "Проект LLVM развивает средства для безопасной работы с буфер..."	+1 +/–
	Сообщение от none7 (ok), 06-Окт-22, 14:30
	Не бывает бесплатных проверок, даже за защищённый режим процессора с его виртуальной памятью приходится платить свою цену, реальный режим реально быстрее. У x86 так же есть инструкция bound для проверки соответствия указателя определённому диапазону, но естественно времени она занимает столько же как и пара cmp+j[ab], хотя реализована аппаратнее некуда. Проверки данных по одной границе при изменении оказались дешевле и инструкцию выбросили на свалку истории. Дешевле одной проверки только отсутствие проверки во время выполнения, например мы можем быть уверены, что в результате операции i & 255, i не выйдет за пределы массива длиной 256 байт. Компиляторы Rust и Ada вроде как специализируются на обеспечении таких гарантий и должны бы быть быстрее компиляторов Си... должны бы быть. Проверки это вещь столь бесплатная, что у gcc даже есть флаг -funroll-loops, который разворачивает циклы так, чтобы уменьшить число проверок.
	Ответить | Правка | Наверх | Cообщить модератору

	73. "Проект LLVM развивает средства для безопасной работы с буфер..."	–3 +/–
	Сообщение от n00by (ok), 06-Окт-22, 14:52
	> даже за защищённый режим процессора с его виртуальной > памятью приходится платить свою цену, реальный режим реально быстрее. Столько нового и интересного узнаёшь на Опеннете. То есть виртуальная память иногда медленнее, поскольку её размер больше физической и страницы иногда гоняются на медленный накопитель и обратно? На самом деле, в этом случае система работает быстрее - потому что в реальном режиме она бы вообще не работала из-за нехватки памяти.
	Ответить | Правка | Наверх | Cообщить модератору

	79. "Проект LLVM развивает средства для безопасной работы с буфер..."	+2 +/–
	Сообщение от none7 (ok), 06-Окт-22, 15:03
	> Столько нового и интересного узнаёшь на Опеннете. То есть виртуальная память иногда > медленнее, поскольку её размер меньше физической и страницы иногда гоняются на > медленный накопитель и обратно? На самом деле, в этом случая система > работает быстрее - потому что в реальном режиме она бы вообще > не работала из-за нехватки памяти. Нет, процессору же приходится гонять виртуальные адреса через таблицу страниц для превращения их в реальные адреса. Или для броска исключения при выходе за пределы зарегистрированных ядром ОС страниц или при неправомерном доступе к ним. Теоретически в процессоре есть блок предназначенный для параллельного сравнения адреса с адресами страниц, только вот блок этот не безразмерный. В нём лежат только страницы к которым обращались недавно. В случае остальных, процессору приходится копаться в огромной таблице в оперативной памяти, а это ой как не быстро.
	Ответить | Правка | Наверх | Cообщить модератору

	95. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от n00by (ok), 06-Окт-22, 16:21
	Исключение потому так и называется, что генерируется в исключительных случаях. Так то да, если запретить ещё и прерывания, то система будет работать «быстрее», не прерываясь на чтение с накопителя и приём пакетов. А если обрабатывать только 64 байта, то не придётся читать из медленного ОЗУ, поскольку хватит линейки кеша. Только почему-то мало кому приходит в голову «оптимизировать» всё это.
	Ответить | Правка | Наверх | Cообщить модератору

	102. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от Аноним (102), 06-Окт-22, 16:34
	> Так то да, если запретить ещё и прерывания, то система будет работать «быстрее», > не прерываясь на чтение с накопителя и приём пакетов. Вот кстати в голодные времена провайдеры вместо Cisco использовали ПК с Linux и отключали прерывания, чтобы увеличить число пакетов перевариваемых роутером за секунду. > А если обрабатывать только 64 байта, то не придётся читать из медленного ОЗУ, > поскольку хватит линейки кеша. Только почему-то мало кому приходит в голову > «оптимизировать» всё это. Те кто воюют за оптимизацию работы процессорного кеша в природе водятся это факт. К сожалению немногим программистам вообще в голову приходит мысль хоть как-то оптимизировать свои программы. Компилятор сам по их мнению справится, а код они пишут для людей, а не машин.
	Ответить | Правка | Наверх | Cообщить модератору

	241. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от n00by (ok), 08-Окт-22, 16:01
	>> Так то да, если запретить ещё и прерывания, то система будет работать «быстрее», >> не прерываясь на чтение с накопителя и приём пакетов. > Вот кстати в голодные времена провайдеры вместо Cisco использовали ПК с Linux > и отключали прерывания, чтобы увеличить число пакетов перевариваемых роутером за секунду. Осталось написать дату тех времён и характеристики железа - что бы можно было прикинуть, насколько сейчас сократились потери. >> А если обрабатывать только 64 байта, то не придётся читать из медленного ОЗУ, >> поскольку хватит линейки кеша. Только почему-то мало кому приходит в голову >> «оптимизировать» всё это. > Те кто воюют за оптимизацию работы процессорного кеша в природе водятся это > факт. Вот пусть такой человек со мной и спорит. Пока господа теоретики даже не смогли обнаружить, что у меня на гатхабе опубликованы результаты таких оптимизаций, как раз из-за чуть более оптимального использования кеша мой интерпретатор обгоняет скомпилированный код: Интерпретация:     $ time echo 5 | refal lambda.ref     Enter a number:     120     real    2m47,046s     user    2m46,415s     sys     0m0,014s Скомпилировано Рефал-05     $ time echo 5 | ./lambda-05     Enter a number:     120     real    3m32,260s     user    3m30,360s     sys     0m1,193s Это на исходнике, который не я писал. На моём и в 5 раз быстрее получилось. > К сожалению немногим программистам вообще в голову приходит мысль хоть как-то оптимизировать > свои программы. Компилятор сам по их мнению справится, а код они пишут > для людей, а не машин. Как раз быстрый код пишется для людей, Кнут вон несколько талмудов написал.
	Ответить | Правка | Наверх | Cообщить модератору

	78. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от n00by (ok), 06-Окт-22, 15:00
	> У x86 > так же есть инструкция bound для проверки соответствия указателя определённому диапазону, > но естественно времени она занимает столько же как и пара cmp+j[ab], > хотя реализована аппаратнее некуда. А если посмотреть талмуд, то она делает совсем другое - генерирует исключение #BR — BOUND Range Exceeded. Время её выполнения, надо полагать, Вы дадите в ответе на моё сообщение?
	Ответить | Правка | К родителю #67 | Наверх | Cообщить модератору

	81. "Проект LLVM развивает средства для безопасной работы с буфер..."	+1 +/–
	Сообщение от none7 (ok), 06-Окт-22, 15:06
	> А если посмотреть талмуд, то она делает совсем другое - генерирует исключение > #BR — BOUND Range Exceeded. Время её выполнения, надо полагать, Вы > дадите в ответе на моё сообщение? Она даёт исключение при выходе за границы проверки, а не всегда.
	Ответить | Правка | Наверх | Cообщить модератору

	93. "Проект LLVM развивает средства для безопасной работы с буфер..."	–1 +/–
	Сообщение от n00by (ok), 06-Окт-22, 16:14
	Что бы «естественно времени она занимает столько же как и пара cmp+j[ab]» имело силу, хорошо бы написать времена для обоих случаев. А эти команды даже делают разное.
	Ответить | Правка | Наверх | Cообщить модератору

	96. "Проект LLVM развивает средства для безопасной работы с буфер..."	+1 +/–
	Сообщение от Аноним (102), 06-Окт-22, 16:25
	> Что бы «естественно времени она занимает столько же как и пара cmp+j[ab]» > имело силу, хорошо бы написать времена для обоих случаев. А эти > команды даже делают разное. Естественно ситуация выхода за пределы массива является серьёзной ошибкой и не так уж и важно сколько времени уйдёт на её обработку. В худшем случае она даже может привести к завершению программы. Так, что сравнивать нужно ситуации когда выхода за пределы массива нет.
	Ответить | Правка | Наверх | Cообщить модератору

	101. "Проект LLVM развивает средства для безопасной работы с буфер..."	–1 +/–
	Сообщение от n00by (ok), 06-Окт-22, 16:33
	> Так, что сравнивать > нужно ситуации когда выхода за пределы массива нет. Так для этого надо найти старый тадмуд, где указано время исполнения BOUND. Я смутно припоминаю, что она дико медленная, как и все сложные инструкции. Но не я делал заявление на тему «естественно столько же», так что тут есть кому искать тот талмуд. :)
	Ответить | Правка | Наверх | Cообщить модератору

	105. "Проект LLVM развивает средства для безопасной работы с буфер..."	+2 +/–
	Сообщение от Аноним (102), 06-Окт-22, 16:42
	> Но не я делал заявление на тему «естественно столько же», > так что тут есть кому искать тот талмуд. :) Этот талмуд идёт в комплекте с masm32 и он у меня под рукой bound - 7 тактов на 486 cmp reg, mem - 2 такта Jxx при пропуске прыжка - 1 такт Ой, bound даже немного медленнее.
	Ответить | Правка | Наверх | Cообщить модератору

	164. "Проект LLVM развивает средства для безопасной работы с буфер..."	+1 +/–
	Сообщение от Аноним (129), 07-Окт-22, 02:37
	> на 486 Сейчас какой год идёт? Не, не так... Какой сейчас век?
	Ответить | Правка | Наверх | Cообщить модератору

	170. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от none7 (ok), 07-Окт-22, 04:18
	> Сейчас какой год идёт? Не, не так... Какой сейчас век? Да без разницы какой год. Основа вычислительного блока в процессорах Intel не меняется. Просто самих блоков стало больше и в местах где можно параллелить инструкции, процессор параллелит. Хотя да, цепочку cmp, ja, cmp, jb можно за счёт спекулятивного выполнения ужать до тактов cmp, ja, если перехода по Jxx не будет. Но вот если будет, то процессор неизвестное количество тактов потратит на откат состояния.
	Ответить | Правка | Наверх | Cообщить модератору

	242. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от n00by (ok), 08-Окт-22, 16:05
	>> Сейчас какой год идёт? Не, не так... Какой сейчас век? > Да без разницы какой год. Основа вычислительного блока в процессорах Intel не > меняется. Просто самих блоков стало больше и в местах где можно > параллелить инструкции, процессор параллелит. Хотя да, цепочку cmp, ja, cmp, jb > можно за счёт спекулятивного выполнения ужать до тактов cmp, ja, если > перехода по Jxx не будет. Но вот если будет, то процессор > неизвестное количество тактов потратит на откат состояния. Откат будет, внезапно, в случае ошибки в программе! Что Вы там собрались оптимизировать при выходе за пределы буфера?
	Ответить | Правка | Наверх | Cообщить модератору

	269. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от Аноним (-), 12-Окт-22, 15:46
	> Да без разницы какой год. Основа вычислительного блока в процессорах Intel не меняется. Ага, конечно. Интел не настолько дно в разработках.
	Ответить | Правка | К родителю #170 | Наверх | Cообщить модератору

	274. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от none7 (ok), 12-Окт-22, 16:32
	> Ага, конечно. Интел не настолько дно в разработках. У них есть специальная инструкция rdtsc которой можно узнать, сколько тактов занимает та или иная инструкция или блок инструкций. Если работать только с регистрами или с кешем первого уровня, то число тактов на инструкцию совпадает с 486 процессором. Просто кеш стал больше, число ALU стало больше, а конвееры стали хитрее. Наоборот Intel создала RISC процессор под своим CISC процессором, чтобы разбить сложные инструкции на несколько маленьких и примитивных, что позволяет им чуть лучше гнать частоты, так как на нынешнем уровне скорость распространения электрического тока от тактового генератора и до конца каждой используемой инструкции, уже имеет значение. Хотя да, это можно считать за изменение, но число тактов не уменьшилось уж точно.
	Ответить | Правка | Наверх | Cообщить модератору

	275. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от n00by (ok), 13-Окт-22, 10:27
	>> Ага, конечно. Интел не настолько дно в разработках. > У них есть специальная инструкция rdtsc которой можно узнать, сколько тактов занимает > та или иная инструкция или блок инструкций. В действительности rdtsc читает time stamp counter, и есть нюанс: The RDTSC instruction is not a serializing instruction. It does not necessarily wait until all previous instructions have been executed before reading the counter. Similarly, subsequent instructions may begin execution before the read operation is performed. Время одной инструкции измерить невозможно. В лучшем случае была симуляции конвейера в AMD Code Analyst, но в актуальной uProf такой функциональности нет, как и в инструментах Intel. > Если работать только с > регистрами или с кешем первого уровня, то число тактов на инструкцию > совпадает с 486 процессором. Потрудитесь подтвердить цитатой официальной документации, или прекратите генерировать удивительные гипотезы.
	Ответить | Правка | К родителю #274 | Наверх | Cообщить модератору

	243. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от n00by (ok), 08-Окт-22, 16:23
	>> на 486 > Сейчас какой год идёт? Не, не так... Какой сейчас век? Да даже для того времени утверждение «времени она занимает столько же» -- неверно, сложите такты. :) А кто скажет «2+1 + 2+1 это почти 7» - тот пусть идёт читает Генри Уоррена младшего, главу 4.1.
	Ответить | Правка | К родителю #164 | Наверх | Cообщить модератору

	240. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от n00by (ok), 08-Окт-22, 15:51
	>> Но не я делал заявление на тему «естественно столько же», >> так что тут есть кому искать тот талмуд. :) > Этот талмуд идёт в комплекте с masm32 и он у меня под > рукой > bound - 7 тактов на 486 > cmp reg, mem - 2 такта > Jxx при пропуске прыжка - 1 такт Данные по cmp и Jxx неактуальны для современного железа. У cmp латентность 1, а пропускная способность 0,25 или 0,33. > Ой, bound даже немного медленнее. То есть согласно даже тем данным, в № 67 написана, мягко говоря, неправда, поскольку опирается на ложное утверждение: Не бывает бесплатных проверок, даже за защищённый режим процессора с его виртуальной памятью приходится платить свою цену, реальный режим реально быстрее. У x86 так же есть инструкция bound для проверки соответствия указателя определённому диапазону, но естественно ***времени она занимает столько же как и пара cmp+j[ab]***, хотя реализована аппаратнее некуда.
	Ответить | Правка | К родителю #105 | Наверх | Cообщить модератору

	89. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от Аноним (89), 06-Окт-22, 15:56
	В защищенном режиме много всякой мути, которая в теории должна жутко тормозить. Виртуальная память, переключение контекстов и т.д. В современных процах все это решается за счет распараллеливания. Т.е. проблему по сути закидывают шапками. Это когда тебе тех процесс позволяет клепать сколько угодно транзисторов, так что можно параллельно просчитывать 100500 инструкций вперед при over9000 ветвлениях. Другое дело, что расплатой за это является возможность атак по сторонним каналам. Так что, как сказал Мэт Дэймон, да, да...
	Ответить | Правка | К родителю #67 | Наверх | Cообщить модератору

	98. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от Аноним (98), 06-Окт-22, 16:29
	Так чтож, теперь отказаться от защищённого режима? Привет, эпоха DOS! Сторонние каналы не требуются, получай достпуп к любым соседним процессам сколько хочешь!
	Ответить | Правка | Наверх | Cообщить модератору

	103. "Проект LLVM развивает средства для безопасной работы с буфер..."	–1 +/–
	Сообщение от n00by (ok), 06-Окт-22, 16:35
	> Привет, эпоха DOS! Сторонние каналы > не требуются, получай достпуп к любым соседним процессам сколько хочешь! И правда, быстрее же. =)
	Ответить | Правка | Наверх | Cообщить модератору

	136. "Проект LLVM развивает средства для безопасной работы с буфер..."	+1 +/–
	Сообщение от Tita_M (ok), 06-Окт-22, 20:08
	Существует архитектура Mill в которой нет виртуальной памяти и много чего другого, что есть в классических процессорах усложняющих их и тем не менее многие FLOSS программы и операционки корректно работают на ней после компиляции и  практически без изменений.
	Ответить | Правка | Наверх | Cообщить модератору

	218. "Проект LLVM развивает средства для безопасной работы с буфер..."	+1 +/–
	Сообщение от Аноним (218), 07-Окт-22, 18:11
	Но в реальном мире, кроме FOSS, ещё браузер загружает страницы с тоннами стороннего JS, которому наплевать на корректное сосуществование с другими просессами в архитектуре без виртуальной памяти.
	Ответить | Правка | Наверх | Cообщить модератору

	272. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от Аноним (-), 12-Окт-22, 16:10
	> Но в реальном мире, кроме FOSS, ещё браузер загружает страницы с тоннами > стороннего JS, которому наплевать на корректное сосуществование с другими просессами в > архитектуре без виртуальной памяти. И при всем этом там приколы типа ROWHAMMER могут работать. Даже оттуда. Который как оказалось даже в DDR4 все же вылезает в определенных условиях. Сюрприз!
	Ответить | Правка | Наверх | Cообщить модератору

	244. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от n00by (ok), 08-Окт-22, 16:33
	А ещё есть компьютер Спектрум. Самый быстрый там вариант - самомодифицирующийся код. Но реальный мир - это немного другое.
	Ответить | Правка | К родителю #136 | Наверх | Cообщить модератору

	270. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от Аноним (-), 12-Окт-22, 15:47
	> А ещё есть компьютер Спектрум. Самый быстрый там вариант - самомодифицирующийся код. > Но реальный мир - это немного другое. В реальном мире вооон те игроделы бьют рекорды по скорости декомпресии vs плотность сжатия используя "data to code transformation". Из данных генерится код, это для их случая самый быстрый способ распаковки. Это нишевой случай но так можно было.
	Ответить | Правка | Наверх | Cообщить модератору

	276. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от n00by (ok), 13-Окт-22, 10:54
	Можно было, конечно, осталось посчитать, сколько играли в тот «Дум» на Спектруме и подумать, почему оно появилось сильно позже чем всякие Dyzzy и почему сорцы всех этих шедевров написаны под PC, который маст дай. ;)
	Ответить | Правка | Наверх | Cообщить модератору

	192. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от _kp (ok), 07-Окт-22, 11:00
	> В защищенном режиме много всякой мути, которая в теории должна жутко тормозить. На счёт "жутко тормозить" это уже слишком безграмотно. Если писать эмулятор 386+, то конечно, софтовая эмуляция защищенного режима требует каких то ресурсов, но не много. А по сравнению с иными издержками, и вовсе не беспокоит. Даже в софтовом виде, без предсказаний и спекулятивных операций. Так же, "грамотно" написанное ПО не спасает никакой самый быстрый процессор. Примеры? Неповоротливые игры на Unity, числодроюильные алгоритмы на Питоне, извращения с компиляцией в Ардуино. Причем, тут и i10 10GHz принципиально не поможет. А проверки диапазонов, есть много где, и почему то, рейтинг тормозного ПО они не занимают. Про инструкцию bound сказано верно. Оптимизированный алгоритм, с учетом архитектуры, часто побеждает, то что предусмотрено разработчиками. Пристномамятная фича - в z80 добавили инструкцию копирования памяти, стало быстрее, чем на 8080, но с учетом специфики z80 применяли програмное копирование, ибо на 90%(!) быстрее работало, чем аппаратное. Это совсем разгромный пример, а с меньшей разницей в скорости, как грязи.
	Ответить | Правка | К родителю #89 | Наверх | Cообщить модератору

	245. "Проект LLVM развивает средства для безопасной работы с буфер..."	+1 +/–
	Сообщение от n00by (ok), 08-Окт-22, 16:40
	> Пристномамятная фича - в z80 добавили инструкцию копирования памяти, стало быстрее, чем > на 8080, но с учетом специфики z80 применяли програмное копирование, ибо > на 90%(!) быстрее работало, чем аппаратное. Ну про 90% Вы загнули. LDIR - 21 такт на 1 байт. LDI - 16. Серия последних немного выигрывала по скорости за счёт раздутия кода. Быстрое копирование, насколько помню, выполнялось сериями POP+PUSH - 10+11 на 2 байта. Где-то вдвое быстрее, без учёта дополнительных инструкций. Хотя, может я что-то забыл, да и вариант с генерацией 100 Кб кода для заполнения 6 Кб экрана не рассматриваю. Кстати, в IA32 с была похожая ситуация rep movs, но ныне она ускорена аппаратно с учётом нюансов работы с кешем.
	Ответить | Правка | Наверх | Cообщить модератору

	252. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от _kp (ok), 09-Окт-22, 00:23
	Верно. Вдвое быстрее, плюс издержки, это и есть примерно на 90% быстрее. Прирост зависит от размеров портянки из push/pop в реализации memcpy(). Больше 32..64 пар редкость. Про rep movs тоже в курсе. Я как коллекционер старого железа, сконен и что под них иногда написать, и эмуляторы пишу тоже. Удивлен грамотному комментарию, по столь экзотической теме.
	Ответить | Правка | Наверх | Cообщить модератору

	254. "Проект LLVM развивает средства для безопасной работы с буфер..."	+1 +/–
	Сообщение от n00by (ok), 09-Окт-22, 15:58
	> Верно. > Вдвое быстрее, плюс издержки, это и есть примерно на 90% быстрее. Действительно. Как обычно, я налажал с арифметикой. > Прирост > зависит от размеров портянки из push/pop в реализации memcpy(). Больше 32..64 > пар редкость. > Про rep movs тоже в курсе. > Я как коллекционер старого железа, сконен и что под них иногда написать, > и эмуляторы пишу тоже. > Удивлен грамотному комментарию, по столь экзотической теме. Довелось когда-то покодить для Спека. Вот редактор обратно совместимый с SoundTracker https://github.com/STrusov/CPS Писался для демок, проигрыватель не самый быстрый, но более-менее стабильный по тактам. Про копирование помню немного, поскольку тогда мы искали пути скроллировать весь экран и перепробовали все комбинации, до каких докопались в чужом коде и додумались сами. В итоге удалось лишь хитростью.
	Ответить | Правка | Наверх | Cообщить модератору

	257. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от _kp (ok), 10-Окт-22, 10:46
	Благодарю. Взял в коллекцию. Смотрю. А на Гитхабе меня уже забанили, поэтому ссылками не делюсь.
	Ответить | Правка | Наверх | Cообщить модератору

	258. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от n00by (ok), 10-Окт-22, 16:34
	Как забанили? Это надо в новости. Тут публика любит, когда кого-то банят. Ну и вроде есть gitflic (что бы изменить там видимость репозитория, надо в службу поддержки написать, как говорят; я не пишу, просто год жду, вдруг заработает).
	Ответить | Правка | Наверх | Cообщить модератору

	259. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от _kp (ok), 11-Окт-22, 10:34
	> Как забанили? Это надо в новости. Уже писали про это. Хотя, банили якобы сотрудничавших с подсанкционными организациями, работавших из Крыма, и вроде как не очень много народу. Но, меня то за что? Даже не отвечают причину в отписках. А вообще, рукописи и репозитории не горят. А кучу чужих добавленных в лайки и форки проектов жалко.
	Ответить | Правка | Наверх | Cообщить модератору

	261. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от n00by (ok), 11-Окт-22, 14:41
	Если забанили на основании решения властей США - тогда им ничего не стоит указать это в причине (таким образом Микрософт как бы получаются невиновны). Не удивлюсь, что там была ещё опция «стукани на коллегу», и замешаны какие-то неадекваты. Во всяком случае, когда местная шаражка удалила мои репозитории, они точно так же не могли объяснить причину.
	Ответить | Правка | Наверх | Cообщить модератору

	266. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от Аноним (-), 12-Окт-22, 15:05
	> Не бывает бесплатных проверок, Вообще в компилтайм они условно бесплатные. В том плане что это время потратит компилер 1 раз, при сборке, а не софт в рантайм. Проблема в том что в полном случае это решение нерешаемой задачи. Но в многих частных случаях это все же можно свести к доказуемым на автомате вещам. Что и дает возможность потрепыхаться на тему влезания на елку не обдирая зад.
	Ответить | Правка | К родителю #67 | Наверх | Cообщить модератору

	195. "Проект LLVM развивает средства для безопасной работы с буфер..."	+1 +/–
	Сообщение от yet another anonymous (?), 07-Окт-22, 11:12
	> Проверка диапазона не ресурсоёмкая, и на некоторых платформах даже аппаратная. Звон-то конечно слышали, но откуда он, не разобрались. Заканчивайте уже тащить слухи про Рабиновича, выигравшего на бегах два миллиона.
	Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема