LINUX.ORG.RU
Форум — Development  

Деление целых на 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)
← gtkiconview вопрос
почему питон мешает св-ва одного объекта класса с другими объектами? →

  1 2 3 4 5 6
Ответ на: комментарий от i-rinat

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

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

std::string

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

(new_size << 1)

Очередной неосилятор матчасти?

$cat 1kgb.c 
int main(void) {
  void * p = malloc(1000ul*1024*1024*1024);
  memset(p, 0, 1*1024*1024);
  return 0;
}
$ gcc 1kgb.c -o 1kgb
$ ./1kgb 
$ echo $?

Я надеюсь тебе не надо рассказывать, почему так получилось, и почему этот код жрёт ровно 1мегабайт памяти?

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

Конкретно в этом примере да, в том, в котором освобождает - маллок не юзаются.

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

почему memcpy() не проверяет аргументы?

Чтобы флеш мог крашиться, а у Линуса с Ульрихом был повод посраться.

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

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

и пока из них все слились

Правильно это называется так - «надоело спорить с идиотом».

разработать строки с такой же производительность, как мои

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

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

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

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

Какой песец.

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

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

Конкретно в этом примере да, в том, в котором освобождает - маллок не юзаются

У тебя в каждой задаче свои строки используются? Это ещё более инновативно, чем я мог увидеть в кошмарах^W^W^Wпредставить...

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

Чтобы флеш мог крашиться, а у Линуса с Ульрихом был повод посраться.

По делу ничего нет - слив номер один.

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

По какой кучи, глупышка. Ты не неси мне тут херню - иди осиль матчасть.

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

А вот из-за того, что стрлен юзается в libc функциях - именно поэтому они такие тормазные. Да, да. Поэтому strcat() так тормазит.

И да, я могу спокойно написать: 

  char data[] = "Я не знаю матчасть, ко-ко-ко";
  str_t str = create_str(data, sizeof(data));

А ты будешь стрлен в рантайме крутить? Куллстори.

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

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

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

По ссылки выше - конкат и греп, и этот код именно и делает минигреп, глупышка. Только тут реплейс.

От как ты заговорил, когда лужа рядом - ок.

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

У тебя в каждой задаче свои строки используются? Это ещё более инновативно, чем я мог увидеть в кошмарах^W^W^Wпредставить...

Да. Представь.

http://raid6.com.au/~onlyjob/posts/arena/ - крути там до примера си-бенчмарка. По условию задачи я должен был юзать маллок и нуловые строки, поэтому уж извини.

А так да, маллок/new - удел тех, кто не осилил матчасть и нормальный аллокатор.

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

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

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

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

Нет, мы пацаны - зачем нам думать, намн адо кукарекать.

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

В том бенче, для которого я этот код написал

А что-нибудь полезное ты в своей жизни написал? Или только кривые бенчмарки?

Очередной неосилятор матчасти?

$ cat 1kgb.c 
#include <stdlib.h>
#include <string.h>

int main(void) {
  void * p = malloc(1000ul*1024*1024*1024);
  memset(p, 0, 1*1024*1024);
  return 0;
}
$ gcc 1kgb.c -o 1kgb
$ ./1kgb 
Ошибка сегментирования (core dumped)
$

Я надеюсь тебе не надо рассказывать, почему так получилось, и почему твой код — говно?

Конкретно в этом примере да, в том, в котором освобождает - маллок не юзаются.

Ну ладно, показывай свой код, так и быть, почитаю.

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

А что-нибудь полезное ты в своей жизни написал? Или только кривые бенчмарки?

О как, с темы съехал - молодец.

Я надеюсь тебе не надо рассказывать, почему так получилось, и почему твой код — говно?

Т.е. ты о5 съехал. Глупышка, какая же ты смишна. Ты хоть понял, что кукарекать не против всех канает?

Мой код юзает то, что ты не осилил юзать. Т.к. ты деточка сидишь либо 32битном фуфле, либо с оверкоммитом - это твои проблемы.

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

Ну ладно, показывай свой код, так и быть, почитаю.

Как же вы любите съезжать с темы. Щас ответит аниме-пацан, я напишу ему норм код.

Ну и так же, тоесть теперь ты притензий к моему коду не имеет? Либо ещё поспорим?

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

рабочий код - это тот код, который работает так, как его написали

Любой код работает так, как его написали. Сюрприз!

Искать гипотетические проблемы

анскилл

Да уж, куда нам :-D

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

Любой код работает так, как его написали. Сюрприз!

Только вот он не работает так, как его пытались написать. О5 юлишь и пытешься съехать, не надоело?

Да уж, куда нам :-D

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

И проблем ты в нём не найдёшь, а кукарекать про то, чего так нет - ты можешь сколько угодно.

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

О как, с темы съехал - молодец.

Да тема всё та же, «как писать код». И я пока не видел твоего кода. Только те 25 строк, в которых баг на каждые 4 строки. :)

Мой код юзает то, что ты не осилил юзать.

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

Ну и так же, тоесть теперь ты притензий к моему коду не имеет? Либо ещё поспорим?

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

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

Только вот он не работает так, как его пытались написать

Именно так. Но ты сам сказал: «А так да, напомню вам, глупышки - рабочий код - это тот код, который работает так, как его написали.» Уже забыл?

и работать будет всегда.

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

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

Да тема всё та же, «как писать код». И я пока не видел твоего кода. Только те 25 строк, в которых баг на каждые 4 строки. :)

Баг? Ну, где баг? ко-ко-ко.

Твой код впустую разбазаривает ресурсы.

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

Я ещё понимаю те ситуации, когда удобно иметь сплошное пространство и использовать только часть. Здесь этого нет, поэтому это плохой код.

У тебя минимум 256ТЕРАБАЙТ адресного пространства. А физического адресного пространства - полсотни гигабайт. Ты понимаешь разницу между этими числами?

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

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

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

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

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

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

Именно так.

Это одно итоже - ты переиначиваешь слова. Написание должно быть осмысленное и отражать то, что ты хотел написать - если то, что ты наваял не вяжется с тем, что ты хотел наваять - это /dev/urandom, а не код.

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

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

В реальном, нормальном коде никакой маллок не юзается, как и new. Юзается он только в тормазящем прикладном говне, автор которого не осилил аллокаторы и память.

Это всегда, в контексте данно задачи - для другой задачи, в которой будет нужен маллок и фри - я напишу по другому. Удержу, не беспокойся. Мои и рядовые способности памяти и мышления - несравнимо разные вещи.

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

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

никакие ресурсы не тратятся

Тратятся ресурсы человека, который читает твой код. Код пишется для человека, не для машины.

Да, да - я видел твой код.

Я твой никто не видел. Он вообще есть?

Там читаемость и быстрота - это последние, о чём ты думал, поэтому не надо мне тут.

С читаемостью там нормально. А быстрота, да, последнее, о чём думал. Мне важно иметь систему с минимальным (а лучше нулевым) числом ошибок.

А уж люди читать его не могут.

Не надо по себе других измерять, ага.

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

Тратятся ресурсы человека, который читает твой код. Код пишется для человека, не для машины.

Сел в лужу и съюлил. Т.е. ресурсы машины не тратся и new_size << 1 тратит не больше памяти, чем твой тормазящий std::string? А зачем ты кукарекал, если не осилил матчасть?

Я твой никто не видел. Он вообще есть?

Нету.

С читаемостью там нормально. А быстрота, да, последнее, о чём думал. Мне важно иметь систему с минимальным (а лучше нулевым) числом ошибок.

this-> - не осилил матчасть, not - не осилил матчасть, паскалист. Не осилил указатели. Детсад, отсутвие логики: 

uint32_t root_block_level = block_obj->level();
if (TREE_LEVEL_LEAF == root_block_level)




Лишния строчка, нарушененная логика - человек с нормальной логикой это не читает. Ты block_obj->level() сравниваешь с TREE_LEVEL_LEAF, а не наоборот.

const struct Block::item_header &ih = block_obj->itemHeader(k); - не осилил матчасть, это не сишкаа. Не осилил указатель и инлайн - не осилил матчасть.

for (int idx = 0; idx < ih.length/4; idx ++) - ущербанские циклы на интех, кукарекал про size_t - сам юзает говно. 

Тысячи continue - не осилил циклы и нормальные структуры данных.

Это я ещё не начал к перфомансу прикапываться.
osh5pntp8
()
Ответ на: комментарий от osh5pntp8

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

[0] Artur@ [~/tmp]
tmp$ gcc -g hacker.c 
hacker.c: In function ‘correct_data_size’:
hacker.c:17: warning: assignment makes pointer from integer without a cast
hacker.c: In function ‘create_str’:
hacker.c:31: warning: incompatible implicit declaration of built-in function ‘malloc’
hacker.c: In function ‘main’:
hacker.c:56: warning: format ‘%lu’ expects type ‘long unsigned int’, but argument 3 has type ‘uint64_t’
hacker.c:56: warning: format ‘%lu’ expects type ‘long unsigned int’, but argument 3 has type ‘uint64_t’

[0] Artur@ [~/tmp]
tmp$ gdb ./a.out
GNU gdb 6.3.50-20050815 (Apple version gdb-1824) (Wed Feb  6 22:51:23 UTC 2013)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin"...Reading symbols for shared libraries .. done

(gdb) r
Starting program: /Users/Artur/tmp/a.out 
Reading symbols for shared libraries +.............................. done

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x00000000001039c0
0x00007fff906eea4d in memmove$VARIANT$sse42 ()
(gdb) bt
#0  0x00007fff906eea4d in memmove$VARIANT$sse42 ()
#1  0x00007fff90708793 in __memcpy_chk ()
#2  0x00000001000009c0 in __inline_memcpy_chk (__dest=0x1039c0, __src=0x1001039a0, __len=17) at _string.h:61
#3  0x000000010000092f in concat (dest={begin = 0x1039c0 <Address 0x1039c0 out of bounds>, size = 1, data_size = 34}, src={begin = 0x1001039a0 "abcdefghefghefgh", size = 17, data_size = 17}) at hacker.c:25
#4  0x0000000100000b1b in test (star_n=0, n=16384, gstr=0x7fff5fbffb00, str={begin = 0x1001039a0 "abcdefghefghefgh", size = 17, data_size = 17}) at hacker.c:37
#5  0x0000000100000d38 in main () at hacker.c:55
(gdb)
arturpub ★★
()
Ответ на: комментарий от osh5pntp8

Нету.

Ну так напиши, а потом «кукарекай».

this-> - не осилил матчасть

Это просто ты мало кода писал. Так сделано специально, подрастёшь — поймёшь.

not - не осилил матчасть, паскалист

Это просто ты не осилил спецификацию C++.

Не осилил указатели.

Подрастёшь, поймёшь.

Лишния строчка

А-а-а, строчки кончаются! Но да, надо было там const вкорячить.

Ты block_obj->level() сравниваешь с TREE_LEVEL_LEAF, а не наоборот.

Это просто ты мало кода писал. Так сделано специально, подрастёшь — поймёшь.

не осилил матчасть, это не сишкаа

Это компилируется g++, конечно это не си. Неожиданно, правда? А классы тебя не смутили?

Тысячи continue - не осилил циклы и нормальные структуры данных.

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

Нету.

Это я ещё не начал к перфомансу прикапываться.

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

i-rinat ★★★★★
()

компилятор наверно заменяет деление на сдвиг при оптимизации

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

32битное фуфло, нежданчик - не интересует.

hacker.c:31: warning: incompatible implicit declaration of built-in function ‘malloc’

Читать варнинги не учился. У меня всё работает - что ты там нафигачил __dest=0x1039c0 с чего там появилось.

__inline_memcpy_chk (__dest=0x1039c0, __src=0x1001039a0, __len=17) - как такое могло произойти, почему. Скорее всего из-за того, что твой конпелятор говно и напортачил что-то в стеке. Это твои проблемы, а не мои.

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

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

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

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

Кстати вот тебе пример когда маллок не возвращает зануленную память без фри (кто бы сомневался, да?):

#include <stdlib.h>
#include <stdio.h>

int
main(int argc, char *argv[])
{
    unsigned char *p = NULL;
    int i = 0;

    do {
        size_t size = random() % 4096;
        if ((p = malloc(size))) {
            for (size_t n = 0; n < size; n++) {
                if (p[n] != 0) {
                    printf("chunk %d, size %ld, p[%ld] is %u\n", i, (long)size, (long)n, p[n]);
                    return 0;
                }
            }
        }
        i++;
    } while (p);

    return 0;
}

[0] Artur@ [~/tmp]
tmp$ gcc -std=c99 -Wall mem.c 

[0] Artur@ [~/tmp]
tmp$ ./a.out
chunk 34, size 13, p[0] is 173

[0] Artur@ [~/tmp]
tmp$
arturpub ★★
()
Ответ на: комментарий от osh5pntp8

Извини, это твой код не работает, о великий гений. Кстати file a.out -> a.out: Mach-O 64-bit executable x86_64. В коде ничего не менял, хотя правда странно, что компилятор вместо division by zero генерит a.out, который выдает segfault в рантайме. Слился ты, лалка, но повеселил зачетно ;)

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

Варнинги не мои, я только исходник собрал.

как такое могло произойти, почему.

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

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

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

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

проигнорил половину пунктов

Оправдался детсадовскими аргументами

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

про size_t промолчал

Потому что я точно знаю, что size_t там не нужен. Это прикладной код со строго очерченной предметной областью. Ты же писал библиотечную функцию, там size_t уместно.

вам даже улицу мести нельзя доверять.

Это я предоставляю тебе. С таким вниманием к деталям ты будешь отличным специалистом по клинингу придомовых территорий.

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

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

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

Упс, его таки забанили. А я думал, он мне халявное ревью кода сделает. Может баги какие-нибудь нашёл. :(

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

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

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

Если тебе так нужно, то его на говнокоде уже которую неделю макают в говно (и он даже успел пару раз эпично слиться, при этом переводя стрелки на оппонентов). Например, в последнее время доставляет эта ветка: http://govnokod.ru/13187#comment182349

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

Если написать возведение двойки в целую степень через цикл

...то это будет совсем другой usecase; во-вторых, таки заменит:

unsigned f()
{
        int i = 0;
        unsigned ret = 1;

        for (i = 0; i < 4; i++)
                ret <<= 1;

        return ret;
}

$ gcc -O2 -c a1.c 
$ objdump -d a1.o

a1.o:     file format elf32-i386

Disassembly of section .text:

00000000 <f>:
   0:   55                      push   %ebp
   1:   b8 10 00 00 00          mov    $0x10,%eax
   6:   89 e5                   mov    %esp,%ebp
   8:   5d                      pop    %ebp
   9:   c3                      ret    
$

(вместо сдвига можно поставить умножение на 2).

tailgunner ★★★★★
()
Ответ на: комментарий от arturpub 
$ ./a.out 
Убито
$ dmesg
[482822.260272] Out of memory: Kill process 32392 (a.out) score 374 or sacrifice child
[482822.260274] Killed process 32392 (a.out) total-vm:1514840kB, anon-rss:1510552kB, file-rss:32kB

На каком говне ты сидишь, что у тебя за говно либц? С чего у тебя uint64_t - это long long?

Выкинь это говно.

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

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

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

Разумное время определяется потребностями ядра ЦА. Ускориться «царским способом» в два раза, или сожрать в два раза меньше памяти с точки зрения разработки дороже не всего в два раза, а на порядок. По сути это та самая экономическая зависимость спрос-предложение, только не на одном продукте, а на потенциальном спектре продуктов, из которых будет производиться лишь один вариант. Ты всегда в узкой щелке между имеющейся платформой и потребностями покупателя — вот там и выбираешь каким быть.

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

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

Ты упоролсячтоли? Ты знаешь, что такое аллокатор? Откуда он берёт память? У ОС, а ОС(нормальная по крайней мере) память всегда зануляет.

Поэтому маллок выдаёт всегда нули - это это не так, значит либц говно, ОС говно, маллок говно - ты идиот. Как-то так.

В чём слить? У меня всё работает так, как я вказал. И у всех будет работать, а на каком говне ты сидишь - мне не интересно.

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

Разумное время определяется потребностями ядра ЦА.

Какие портребности - ты упоролся? В мире давно уже всё не попотребностям. Кому-то нужны твои сайтецы? Айпонты? Маздайка? Новые офисы? Нет, они некому не нужны, ибо если бы они были нужны - реклама была бы не нужна.

Ускориться «царским способом» в два раза, или сожрать в два раза меньше памяти с точки зрения разработки дороже не всего в два раза, а на порядок.

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

Таких как ты в мире миллионы в кажой области, таких, которые пилят как Царь - таких тысячи и то не в каждой области.

Темболее, ты не забывай - люди «как Царь» никогда не пойдут работать на конвейер за еду(собирать айпонты и прочее) - им это не надо. Поэтому шансов запилить то говно, которые ты пилишь «по Царски» у тебя просто нет. Ибо: а) Нет стольких людских ресурсов, б) Слишком примитивная работа для «как Царь», в) Дороже.

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

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

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

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

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

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

Так ты расскажешь, почему твой код валится с фейспалмом, или ты настолько скилен, что такие мелочи тебя не волнуют?

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

О5 ты, питушок, слился как детё.

Я уже тебе объяснил - твоя ОС/конпелятор/либц - говно. Твоя проблема - ошибка твоего конпелятора, либо ты наговнякал что-то сам там.

С какого хрена у тебя там пропали левы/правые биты из твоего указателя - меня не интересует. Это твоя проблема.

Выкладывай свои uname -a, lscpu, gcc -v, emerge --info | grep libc или как там в твоём говне это добывать.

И ещё раз, питушок, повторю тебе - мой код не валится - валится твоё говно. Запомни это, и повтори это раз 500, пока в твоей породии на «думалку» это не заклеймится.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
  1 2 3 4 5 6
← gtkiconview вопрос
Development
почему питон мешает св-ва одного объекта класса с другими объектами? →