LINUX.ORG.RU

Деление целых на 2 через битовый сдвиг - архаизм?

 


1

3
#include <iostream>
using namespace std;

int main()
{
	int v = 0;
	for(int i = 0; i < 2000 * 1000 * 1000; ++i) {
		v ^= i >> 1; /* i / 2 */
	}
	cout << v << endl;
	return 0;
}

Если битовый сдвиг заменить обычным делением, то время выполнения не изменится. Обе операции насколько мне известно занимают 1 такт. Запускал на x64.
Существуют ли архитектуры (arm, mips, ...), для которых эти и другие известные трюки - полноправная оптимизация?

UPD: при делении на 3, разница между сдвигом и делением ощутимая. Вопрос: как так, ведь обе инструкции за 1 такт выполняются?



Последнее исправление: nerdogeek (всего исправлений: 2)

Ответ на: комментарий от osh5pntp8

Ты немного не понимаещь что такое развитие. Развитие - это когда человек учится решать новые задачи. Умение перекладывать байтики не поможет тебе решать новые задачи.

anonymous
()
Ответ на: комментарий от drBatty

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

osh5pntp8
()
Ответ на: комментарий от anonymous

Ты немного не понимаещь что такое развитие. Развитие - это когда человек учится решать новые задачи. Умение перекладывать байтики не поможет тебе решать новые задачи.

Я понимаю, что аткое развитие. Как развивает делфист, который кидает кнопки на форму? Он может кидать разные кнопки на разные формы, но он не развивается - он делает одно и то же действие.

Как развивается пхпист, который переписывает один и тот же код 100раз, делая сайтики на каком-то конвейере.

Как развивается СУБДешник, который пишет одни и те же вариации примитивных запросов для СУБД?

Это всё одинаковая, монотонная работа - это как функция, да её результат будет разным в зависимости от аргументов, но код един - развития нет.

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

osh5pntp8
()
Ответ на: комментарий от anonymous

Чем лучше?

Тем, либы делаются для всех, но все не способны понимать даже 5-10% синтаксических конструкций сишки - я же уже понимаю ближе к сотне%.

Поэтому я могу юзать непонятный, байтюлюбский код - который проще и мне понятней, который не занимает 100500 строк.

но зачем?

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

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

Как-то так.

osh5pntp8
()
Ответ на: комментарий от osh5pntp8

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

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

Я пилю сложные вещи, а сложность - это основной коэффициень развития.

Нет, не пилишь. На низком уровне не бывает сложных вещей. Сложные вещи появляются с повышением уровня абстракции. Чем выше уровень абстракции - тем сложнее (потенциально) вещи на этом уровне. А на уровне байтиков только байтики, детский сад.

anonymous
()
Ответ на: комментарий от osh5pntp8

Тем, либы делаются для всех, но все не способны понимать даже 5-10% синтаксических конструкций сишки

Конструкции сишки (все 100%) понимает даже тупой компьютер.

Для развития.

но для развития надо решать новые задачи, применяя новые методы. Если же ты решаешь одни и те же задачи, одними и теми же методами (быть может только немного по-другому их компонуя), никакого развития не будет. Перекладывание байтиков сродни детскому конструктору. Деталек мало, их количество ограничено.

Ну и да, разновидностей тех же связных списков сотни

Нет, он только один.

Я пишу реализацию минимально нужную мне - она меньше, красивее, лучше.

Чем лучше? Проще в поддержке? Надежнее? Лучше протестирована? Удобнее в использовании посторонними программистами? По какому критерию лучше?

anonymous
()
Ответ на: комментарий от anonymous

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

Я могу писать всё, начиная от железячного уровня, ip, tcp стеков, сокетов, сокет api, OS api, реализация парсинга протоколов, реализация вебсервера, реализация хранилкид анных с нуля, гинерацию самого хтмл"а и прочее. Причём всё это будет на порядки быстрее, надёжней за меньшее кол-во строк.

Твйо же высокоуровней веб-программист максимум, что осилит - это гинерация хтмл"а, и запросики к БД, через уже реализованное api на его пхп.

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

osh5pntp8
()
Ответ на: комментарий от anonymous

Конструкции сишки (все 100%) понимает даже тупой компьютер.

Понимает транслятор, написанный людьми. А вот люди не понимают.

но для развития надо решать новые задачи, применяя новые методы. Если же ты решаешь одни и те же задачи, одними и теми же методами (быть может только немного по-другому их компонуя), никакого развития не будет. Перекладывание байтиков сродни детскому конструктору. Деталек мало, их количество ограничено.

Это и делают высокоуровневые программисты - они не решают задачи - они копануют готовые кубики.

Твой пхп пишет примитивную гинерацию хтмл"а, пусть она гинерит разные вещи - это тупая гинерация хтмл"а.

Твой накидыватель кнопочек - накидывает кнопочки, пусть по разному - но он накидывает кнопочки.

Запомни набудущи одну вещь, ниодна вещь допусня большеству не является сложной. Сложные вещи - это вещи недоступные большенству. Ты делишь на ноль, причём тупо и явно.

Нет, он только один.

Одно, дву связные списки - кольцевы, с нулями на концах. Списки с 2-й индексацией, списки на оффсетах, хорсписки, спискомассивы - тысячи их, открой википедию. То, что ты этого не знаешь - говорит о твоём примитивно понимании всего, ибо за абстракцией «список» - ты не видишь ничего.

Попробуй свой список задампить в файл - фейл. Поэтому дампятся один вид списков - оффсетные. Попробуй убрать оверхед на указатели - получаешь оффсемтный список. Ты видел где-то реализацию оффсетного списка? Нет.

Чем лучше? Проще в поддержке? Надежнее? Лучше протестирована? Удобнее в использовании посторонними программистами? По какому критерию лучше?

Быстрее, меньше кода, красивее, надёжнее, не нуждается в тестировании, удобен в использовании МНЕ, и либому другому человеку хотябы моего уровня. Меньше оверхеда.

osh5pntp8
()
Ответ на: комментарий от anonymous

но зачем?

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

если два последних достижения тебе кажутся ненужными - подумай о мобильных устройствах. объём аккумулятора наращивать тупо некуда.

KivApple ★★★★★
()
Ответ на: комментарий от anonymous

Решать задачи более эффективно это тоже развитие. Вот штангист решает одну и ту же задачу - поднимание штанги. Но разве он не развивается (в физическом смысле), когда научился тягать вес в 10 раз больше?

В случае интеллектуального труда всё так же. Развитие не только обучение решать новые задачи (это, конечно, тоже важно), но и решать существующие в 10 раз быстрее и эффективнее.

Иначе бы мы ходили пешком - мы уже можем перемещаться на двух ногах, зачем изобретать машину?

KivApple ★★★★★
()
Ответ на: комментарий от osh5pntp8

Чтож ты такой глупый - твой программист не умеет решать задачу вообще

Как же так выходит - решать он ее не умеет, а задача в результате оказывается решена?

если я могу запилить всё, что угодно - начиная от той же СУБД с нуля, от той же гуйни с нуля, тот же сайтик с нуля.

Да любой может. Потенциально.

Я могу писать всё, начиная от железячного уровня, ip, tcp стеков, сокетов, сокет api, OS api, реализация парсинга протоколов, реализация вебсервера, реализация хранилкид анных с нуля, гинерацию самого хтмл"а и прочее. Причём всё это будет на порядки быстрее

Зачем быстрее?

надёжней за меньшее кол-во строк

А вот здесь есть много сомнений.

Твйо же высокоуровней веб-программист максимум, что осилит - это гинерация хтмл"а, и запросики к БД, через уже реализованное api на его пхп.

Осилит он что угодно точно так же как и ты - потенциально.

Высокоуровней программист - дешевая рабсила

Наоборот.

ибо полезную работу делает именно код низкоуровневых программистов

Только этот код никаких задач не решает и потому никому не нужен. Ты пойми - никому не нужны вебсерва. И парсить хмл никому не надо. И сокеты с протоколами тоже. Это не задачи. Это средства для их решения. И ничего полезного сами по себе они не делают. Людям нужны табуретки, а гвозди, молотки и доски - нет.

anonymous
()
Ответ на: комментарий от osh5pntp8

Понимает транслятор, написанный людьми. А вот люди не понимают.

Понимают, конечно же.

Это и делают высокоуровневые программисты - они не решают задачи

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

Одно, дву связные списки - кольцевы, с нулями на концах.

А, ну это все разные структуры данных. Обычно когда говорят «связный список» подразумевают именно обычный односвязный список. Если имеется ввиду какой-то другой список - то уточняют, т.к. это другая структура данных для других задач.

Попробуй свой список задампить в файл - фейл.

В чем фейл? Все спокойно дампится.

Быстрее, меньше кода, красивее, надёжнее, не нуждается в тестировании

Чтобы оно не нуждалось в тестировании, надо доказать корректность. Если корректность не доказана и нету тестов - то о надежности речи нет. Красота - субъективное понятие, скорость - просто не нужна, кода у тебя будет больше.

anonymous
()
Ответ на: комментарий от KivApple

Ты не понимаешь о чем речь. еще раз - программы сами по себе никому не нужны. Нужны решения задач. Программа либо решает заджачу, либо не решает. Обычно задачу надо решать за определенное разумное время. И программа либо решает ее за это разумное время (то есть работает) либо не решает (то етсь не работает). При этом если она работает (то есть производительность достаточна), то от дальнейшего ускорения никакой пользы нет.

anonymous
()
Ответ на: комментарий от anonymous

Да любой может. Потенциально.

Объективно 95% программистов не может, а так же 99% высокоуровневых программистов.

Зачем быстрее?

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

А вот здесь есть много сомнений.

Объективный факт.

Осилит он что угодно точно так же как и ты - потенциально.

Нет, ты врёшь, блишь и несёшь херню. Пока таких прицидентов небыло, да и не будет. Я могу хоть сейчас - они не смогут в ближайщие 10лет, ибо их уровень на днище морском.

Наоборот.

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

Только этот код никаких задач не решает и потому никому не нужен. Ты пойми - никому не нужны вебсерва. И парсить хмл никому не надо. И сокеты с протоколами тоже. Это не задачи. Это средства для их решения. И ничего полезного сами по себе они не делают. Людям нужны табуретки, а гвозди, молотки и доски - нет.

А ну да, никому нен ужны вебсерверы - конечно. Ты нихрена не знаешь про веб. Иди спроси у любого более-менее нагруженного сайта - нужен ли им нгинкс. Сколько времени они убили на кешируещие сервера, и как им не надо парсить хтмл.

Это задачи, глупое существо - кода ты выйдешь из своей песочницы, и увидишь то, что реально нужно миру. Написать сейтец может любой идиот, а вот сделать сайтец, который будет работать под 50-ю миллионами юзверей одновременно - нет.

И именно такие сайтецы сейчас мейнстрим.

Людям нужны не машины, а быстрые, красивые, качественные машины. Ты идёшь по пути автоваза. Опрадывать ты этом можешь сколько угодно, что людям нен ужны движки, нормальный солон, нормальный метал - людям ведь нужны машины.

Но твои машины говно, ибо у тебя ни движка, ни салона, ни материалов, ибо они тебе как-бэ не нужны.

Поэтому ты впариваешь своё говно за еду лохам.

osh5pntp8
()
Ответ на: комментарий от anonymous

Как можно определить это разумное время? Почему юзеру нельзя запустить сразу две копии тяжёлой игры (на разных мониторах)? Почему нельзя запустить выборку не на миллионе записей, а на миллиарде? Почему телефон с запущенной игрой должен садиться за час, а не за сутки? Всё это «разумное время» тут же испаряется, стоит немного поменять условия задачи. И экономия на программистах выливается в нерациональное использование ресурсов и неудобства конечных пользователей.

Разве не было бы прекрасно, если бы игры типа Кризиса шли на калькуляторах (утрирую, конечно же, туда его не впихнуть никаким оптимизациями)?

KivApple ★★★★★
()
Ответ на: комментарий от anonymous

Понимают, конечно же.

Блин, не смеши мои тапки своими детскими сливами - не понимаю. Иди дай кому-то ведро линукс и скажи - раскури - зафейлится через 30секунд.

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

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

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

Твои аналогии на уровне детсада.

А, ну это все разные структуры данных. Обычно когда говорят «связный список» подразумевают именно обычный односвязный список. Если имеется ввиду какой-то другой список - то уточняют, т.к. это другая структура данных для других задач.

Это одна структура данных - связный список. Ничего под связным списком не подразумивается - подразумевается основной принцип - идексация массива.

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

В чем фейл? Все спокойно дампится.

Реально? Ты понимаешь значение слова дамп? Это не копирование полезной инфы, а именно дамп.

Намекну - указатели станут не рабочими, если ты сохранишь их значения, а потом о5 восстановишь.

Чтобы оно не нуждалось в тестировании, надо доказать корректность. Если корректность не доказана и нету тестов - то о надежности речи нет. Красота - субъективное понятие, скорость - просто не нужна, кода у тебя будет больше.

Чтож ты такая глупышка. Ненадо ничего даказывать - ты же не проверяешь молоток на корректность? Он настолько простой, что в нём ломаться нечему. Так же и тут - структуры данных настолько просты, узкоспециализированны, малы, что в них ломаться нечему.

Я там выше давай реализацию строк - скажи, что там может сломаться.

osh5pntp8
()
Ответ на: комментарий от KivApple

Разве не было бы прекрасно, если бы игры типа Кризиса шли на калькуляторах

Было бы. И так будет, кстати - когда калькуляторы сравняются по мощности с нынешними десктопами. Но достигнуто это будет не методами нашего старого доброго знакомого суперхаккиллера1997.

tailgunner ★★★★★
()
Ответ на: комментарий от osh5pntp8

в пентиуме два ALU, U,V трубы, он две команды за такт умеет. Такая древняя «многоядерность».

drBatty ★★
()
Ответ на: комментарий от osh5pntp8

В любом случае,O(n^2) на другом ЯП не сольём O(n^3) сишке, из-за того, что n^3 дороже.

FTFY

Проект на 100тыс строк - это либо гуйня, либо ненужность.

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

90% процессорного времени в СУБД занимает оверх самой СУБД

Неа, они были одними из тех, кто *тогда* добился 100% загрузки проца. Для непосвященных скажу, что даже тогда базы данных упирались в io, а не в проц, и упереться в проц было нефиговым достижением.

arturpub ★★
()
Ответ на: комментарий от osh5pntp8

Ты сильно ошибаешься, думая, что нгинкс или сайты с 50млн. юзеров написаны на сишке с помощью собственных ин-плейс контейнеров. Понимаешь, есть такая штука как боттлнеки, и они довольно быстро проявляются при росте нагрузки. Причем заранее сказать, где они возникнут абсолютно невозможно, т.к. заранее неизвестна точная структура нагрузки. Как их решают? Либо отсрочкой проблемы путем мелкой оптимизации (+10..100%), либо ее долгосрочным решением с помощью к-л новых подходов, структурно. Ты предлагаешь везде и всегда заранее использовать первый подход, оптимизируя вручную пути, по которым рантайм будет проходить пару раз на запуск и пару раз на редкий случай. Тебе придется опровергнуть правило одной неочевидной ошибки на n строк, давай возьмем n в пределах 100, а также доказать, что самописные контейнеры занимают меньше строк, в довесок к O(n2)>O(n3), в противном случае придется экономически обосновывать довольно глупую политику. Причем боттлнеки никуда не денутся, т.к. у каждого подхода есть слабые стороны, и предвидеть их эксплойт нет никакой возможности, а стоимость изменения таких поделий на порядок выше, чем у write-only perl-скриптов. Фишка фреймворков и библиотек в том, что они, будучи казалось бы бесполезным поделием с дурацким интерфейсом, чисто исторически учли некоторые паттерны, и теперь работают шустрее for free. Тот же композитор на телефоне исторически решил столько проблем, связанных с плавной анимацией, что тебе не под силу хотя бы получить тот опыт за разумное время, не говоря уже о корректной реализации. И да, композитор крут, но вовсе не потому, что его написал кулхацкер, а лишь потому, что выдержал проверку временем и ***чими случаями. Что тут решают твои повсеместные +10% — никому непонятно.

arturpub ★★
()
Ответ на: комментарий от osh5pntp8

Я там выше давай реализацию строк - скажи, что там может сломаться.

Глянул я на твой код.

  1. uint64_t на 32-х битных системах это бесполезный перебор;
  2. ты выделяешь памяти всегда вдвое больше, чем нужно. Fail;
  3. о фрагментации памяти ты даже не думаешь. Minor fail;
  4. хранишь в поле size длину строки плюс один вместо просто длины строки. Fail;
  5. при создании строки поведение зависит от неинициализированных данных. Epic fail;
  6. делаешь свои строки и используешь стандартный strcat? Fail.

Удивительно, как в 25 строках можно так налажать.

i-rinat ★★★★★
()
Ответ на: комментарий от i-rinat

при создании строки поведение зависит от неинициализированных данных. Epic fail;

+возвращаемое значение malloc не проверяется

делаешь свои строки и используешь стандартный strcat? Fail.

Эээ... а в чем проблема?

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

делаешь свои строки и используешь стандартный strcat? Fail.

Эээ... а в чем проблема?

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

i-rinat ★★★★★
()
Ответ на: комментарий от i-rinat

хранишь в поле size длину строки

Нихрена он в поле size не хранит - create_str никак не проверяет входные данные на валидность, разрешает как create_str("", 1000), так и create_str(«1234567890», -1). Ещё обилие скобочек говорит о том, что автор плавает в приоритетах операций настолько, что перестраховывается даже в очевиднейших случаях. Обычный школьный говнокод, все в 10 лет такой писали.

redgremlin ★★★★★
()
Ответ на: комментарий от i-rinat

Хотя, с другой стороны... если уж делать строки нормально, то нужно разрешать и нулевые символы в середине, тогда strcat не катит.

tailgunner ★★★★★
()
Ответ на: комментарий от osh5pntp8

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

nerdogeek
() автор топика
Ответ на: комментарий от i-rinat

uint64_t на 32-х битных системах это бесполезный перебор;

Не нужно - uint_fast_32_t - осиль.

ты выделяешь памяти всегда вдвое больше, чем нужно. Fail;

Иди кури матчасть, а, и не неси херню. Ну и да, любая реализация строк так работает, если конечно она не говно.

о фрагментации памяти ты даже не думаешь. Minor fail;

Иди учи матчасть, о фрагментации памяти никто не думает. Темболее тут её меньше, чем ты осилишь - а вообще, пацаны так не пишут.

хранишь в поле size длину строки плюс один вместо просто длины строки. Fail;

Делай как тебе удобно.

при создании строки поведение зависит от неинициализированных данных. Epic fail;

Кури матчасть. Там нет никаких «неинициализированных данных». Покажи где.

делаешь свои строки и используешь стандартный strcat? Fail.

Кури матчасть, и не неси херню.

Ну и да, ты по ссылки не ходил. Вы нихрена не знаете матчасть, ваши детские представления о коде. Вера в выделение памяти на х86.

osh5pntp8
()
Ответ на: комментарий от i-rinat

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

Ты нихрена не знаешь, о том, что быстрее. Это ручной инициализатор строк, в который ты максимум напишешь 20-30символов. В данном случае strcat() почти бесплатен, и будет не особо медленнее мемкопи.

И о5 ты про память - иди осиль матчасть.

osh5pntp8
()
Ответ на: комментарий от tailgunner

strcat(malloc(size), str)

Что тут «неинициализированное»? Это 2 аргумента функции, с чем они тебе неинициализированны? Или ты не осилил матчасть и проверяешь результат маллока?

Темболее тут это не надо, ибо никто из вас по ссылки не ходил.

osh5pntp8
()
Ответ на: комментарий от redgremlin

Нихрена он в поле size не хранит - create_str никак не проверяет входные данные на валидность

Ещё один. И как ты представляешь себе проверку на валидность? А почему мемкопи не проверяет входные данные на валидность? А? Мне там strlen() зафигачить?

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

Ой, глупышка, ты хочешь со мной посоревноваться в осилении сишки? Я пишу так, как нравится мне - мнение неосиляторов меня не интересует.

Обычный школьный говнокод, все в 10 лет такой писали.

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

osh5pntp8
()
Ответ на: комментарий от osh5pntp8

strcat(malloc(size), str)

Что тут «неинициализированное»?

Мде. Тут malloc возвращает указатель на неинициализированную память; ты передаешь этот указатель в strcat, которая конкатенирует str к этой неинициализированной памяти. Таким образом, в зависимости от содержимого выделенной памяти, содержимое новой строки будет разным.

Ах да, и еще ты не проверяешь результат malloc.

никто из вас по ссылки не ходил.

Этот фрагмент кода - с твоей ссылки.

tailgunner ★★★★★
()
Ответ на: комментарий от arturpub

FTFY

n=1 дороже. Фикс.

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

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

Наши головы разительно отличаются.

Неа, они были одними из тех, кто *тогда* добился 100% загрузки проца. Для непосвященных скажу, что даже тогда базы данных упирались в io, а не в проц, и упереться в проц было нефиговым достижением.

Что ты некаешь, если ты нихрена не знаешь о матчасти. Вот онименно - они добились 100% загрузки проца, когда IO занимает ел-еле 3-5% проца. Остальное оверхед на саму СУБД.

Уже 10раз вам объяснял - там и нити сделаны для того, чтобы ИО не тормазило, ибо СУБД упирается далеко не в ИО. Иди погугли, почитай про ИО, сколько оно стоит и т.п.

osh5pntp8
()
Ответ на: комментарий от osh5pntp8

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

Linux kernel например уже не один десяток миллионов строк кода

nerdogeek
() автор топика
Ответ на: комментарий от osh5pntp8

Не нужно - uint_fast_32_t - осиль.

Осиль уже size_t.

Иди кури матчасть, а, и не неси херню.

Больше запятых, больше!

Иди учи матчасть, о фрагментации памяти никто не думает.

Ты, наверное, книгу написал про аллокаторы памяти.

Ну и да, любая реализация строк так работает, если конечно она не говно.

Не, так никто не лажает. Если нужно хранить мегабайтную строку, под неё выделяют мегабайт, а не два, как у тебя.

Там нет никаких «неинициализированных данных». Покажи где.

Былинный провал. Ты и вправду считаешь, что malloc зануляет память?

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

Мои детские представления о коде... что? Потрудись хоть предложение сформулировать.

Вера в выделение памяти на х86.

Новая религия, да.

Что, неприятно, когда в собственный код макают?

i-rinat ★★★★★
()
Ответ на: комментарий от tailgunner

Мде. Тут malloc возвращает указатель на неинициализированную память

Учи матчасть. Тут монопольный код - результат маллока всегда занулён. На не монопольном коде маллок юзать никто не будет.

ты передаешь этот указатель в strcat, которая конкатенирует str к этой неинициализированной памяти.

И ты в очередной раз даже слыхом не слыхивал о матчасти.

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

В данном случае там всегда будут нули. В случае, когда их не будет - маллока там не будет.

Этот фрагмент кода - с твоей ссылки.

http://raid6.com.au/~onlyjob/posts/arena/

osh5pntp8
()
Ответ на: комментарий от osh5pntp8

Учи матчасть. Тут монопольный код - результат маллока всегда занулён.

Ахаха. WTF «монопольный код»?

int main()
{
        char *p = malloc(100);
        strcpy(p, "foo");
        free(p);
        p = malloc(100);
        printf("%s\n", p);
}
$ ./a.out
foo
$
tailgunner ★★★★★
()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от i-rinat

Осиль уже size_t.

Не учи, мне не упёрлось это фуфло.

Больше запятых, больше!

Ответить нечего.

Ты, наверное, книгу написал про аллокаторы памяти.

Да. Зачем ты вякаешь, если ты нихрена не знаешь о матчасти? Мне уже надоело каждую глупышку на лоре сливать.

Не, так никто не лажает. Если нужно хранить мегабайтную строку, под неё выделяют мегабайт, а не два, как у тебя.

Ещё раз тебе повторю - иди почитай матчасть. Как работает память на х86, почитай про ммаппирование, почитай, что такое пейдфаулты.

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

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

Былинный провал. Ты и вправду считаешь, что malloc зануляет память?

В данном случае да, я об этом писал выше - почитай.

Мои детские представления о коде... что? Потрудись хоть предложение сформулировать.

О5 юлишь.

Новая религия, да.

Ответить нечего, слился на 1-м же ответе.

Что, неприятно, когда в собственный код макают?

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

osh5pntp8
()
Ответ на: комментарий от tailgunner

Ахаха. WTF «монопольный код»?

Ахаха, я кукарекаю даже не представляя о чём кукареаю.

Ты в коде видишь хоть один free()? Или ресайз строки в меньшую сторону? Я тоже не вижу. char *p = malloc(100); - так сделай 100кк раз, найдёшь мне там не нули - я тебя похвалю.

osh5pntp8
()
Ответ на: комментарий от osh5pntp8

И как ты представляешь себе проверку на валидность?

Тебе лучше знать, код-то твой. Судя по использованию strcat, на входе ты ожидаешь null-terminated строку, соответственно, должен использоваться strlen. Правда, тогда непонятно, нахрена передавать size. К слову, а как ты собирался использовать свой create_str для полученных извне n-t строк без stlen?

ты хочешь со мной посоревноваться в осилении сишки?

С чем соревноваться-то? По факту, си ты банально не знаешь, даже на уровне синтаксиса.

Ну давай, напиши лучше

Да без проблем. С тебя техзадание и 500р/час.

redgremlin ★★★★★
()
Ответ на: комментарий от osh5pntp8

Ты в коде видишь хоть один free()?

Блин, ну нельзя же быть таким тупым. free мог быть перед вызовом create_str. Что, на этот случай твой говнокод не расчитан? И эти люди учат нас программировать, тьфу.

я кукарекаю даже не представляя о чём кукареаю.

Мы все уже это поняли.

tailgunner ★★★★★
()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от redgremlin

Тебе лучше знать, код-то твой.

Ой как ты слилась, глупышка.

Судя по использованию strcat, на входе ты ожидаешь null-terminated строку, соответственно, должен использоваться strlen.

Реально? Я тебе спрашиваю, почему memcpy() не проверяет аргументы? А?

create_str(str, strlen(str)); - реально? Ой как жешь сложно.

С чем соревноваться-то? По факту, си ты банально не знаешь, даже на уровне синтаксиса.

По какому факту. Ты не первый, кто начинает спорить со мной, о ниасиляторстве мной сишки - и пока из них все слились, включая тебя.

Да без проблем. С тебя техзадание и 500р/час.

Т.е. зассал. Техзадание - разработать строки с такой же производительность, как мои. Можешь ваять что хочешь - там писать 2-3минуты. Справишься - я тебе 25рублей заплачу.

Хотя ты очередной балабол, и ничего ты не напишешь.

osh5pntp8
()
Ответ на: комментарий от osh5pntp8

Мне уже надоело каждую глупышку на лоре сливать.

Пока что слили только тебя. А ты ещё и огрызаешься.

Ну найди мне такие строки - я тебе памятник поставлю, а потом покажу, что это в хламт ормазит.

std::string

Тут «выделяется» памяти ровно мегабайт, если добавляется мегбайтная строка.

(new_size << 1)

В данном случае да, я об этом писал выше - почитай.

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

i-rinat ★★★★★
()
Ответ на: комментарий от tailgunner

Блин, ну нельзя же быть таким тупым. free мог быть перед вызовом create_str. Что, на этот случай твой говнокод не расчитан? И эти люди учат нас программировать, тьфу.

Ты видишь в моём коде free() До create_str()? Я нет. И тебя я посылаю писать строки, хотябы такие же, как мои. У вас три тела в комманде, авось осилите.

Ещё раз тебе повторю, вменяемые люди юзают либо маллок без фри, либо не юзают его вообще.

И эти люди учат нас программировать, тьфу.

Да, эти люди. Глупышка всегда ищет оправдания для своего фуфла. Придумывает что-то, чего в жизни не бывает. Ты думаешь тот, кто пишет этот код, пишет так же, как ты? И у него есть проблемы, которые есть у касты 95%?

Мы все уже это поняли.

Расскажи.

osh5pntp8
()
Ответ на: комментарий от osh5pntp8

Ещё раз тебе повторю, вменяемые люди юзают либо маллок без фри, либо не юзают его вообще.

В квотезы!

nerdogeek
() автор топика
Ответ на: комментарий от osh5pntp8

И тебя я посылаю писать строки, хотябы такие же, как мои

Такое бажное говно, как твои строки, никому и даром не нужно. И bstring, кстати, давно написан.

вменяемые люди юзают либо маллок без фри, либо не юзают его вообще.

Какой песец.

tailgunner ★★★★★
()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от i-rinat

Если господин 'осилятор сишки' покажет нам свой супер код в какой-либо подсистеме ядра Linux, тогда мы убедимся в его реальной крутости как системного программиста.

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

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.