Было какое-то чтиво времён 2008 про пни третьи, но есть ли похожее про Core i7 / Xeon последние?

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

Вот хочется почитать что-то по сабжу, но про новые камни, а не древние пни.

Страдаю таким недостатком. Когда случается баг, я не иду его дебажить, а иду жрать чай и обдумывать «блеать, где же могло сломаться», потом через полдня ни к чему не прихожу, открываю дебуггер, ковыряюсь там и нахожу то, о чём не мог подумать.

Является ли это недицсиплинированным жопничеством или все так живут?

Ну вы понели.

Существуют всякие непонятные слова, типа калорийность, энергетическая ценность, углеводы, углеводы простые и сложные, жиры, белки.

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

Профессор Савельев говорит, что Моск жрёт ~25% всей энергии организма, когда занят чем-то нетривиальным.

Короче, хочется чего-то почитать, чтобы понимать что лучше жрать, чтобы весь день не уставая кодить и думать, чтобы не болела бошка от голода (как добиться «не болела» я опытным путём таки понял - надо просто нормально жрать до начала серьёзной работы). Хочется разобраться, только не тратя дофига времени во всех этих грёбаных калориях, жирах, углеводах, что как сжигается, зачем, почему. Чтобы описано было просто, логично. Не в стиле женских сайтов, где надо прочитать 100500 воды ради 10 бит инфы по сути.

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

Имеется самый тупой массив типа std::vector, где по индексу можно за O(1) получить элемент. То есть, указатель на начало + индекс = указатель на нужный элемент.

Хочется выдернуть из середины элемент с индексом Y и вставить его в начало.

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

Вставка в начало: вставляемый элемент получает индекс 0, а у всех последующих элементов индекс увеличивается на 1.

Операция «выдернуть из Y и вставить на 0» на самом деле в итоге сохранит индексы у всех элементов начиная с индекса Y+1, а у всех элементов [1...Y-1] индексы увеличатся на 1, а у элемента Y индекс поменяется на 0.

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

Ясно, что противоречащие условия. Я не хочу никакого memmove() на 999 элементов, если переношу тысячный элемент в начало. При этом хочется доступа по индексу за O(1) или близко к этому.

А ещё хочется, чтобы элементы в памяти лежали максимально запаковано, с точки зрения хеша, т.е. в идеале это недостижимый std::vector, а на практике хотя-бы какая-то цепочка из блоков, где лежит последовательно по 64 элемента. Что-то memmov-ать в пределах нескольких линий кеша — норм.

Вот для C или С++ есть минимум:
1) любая IDE от vim до CLion
2) make/cmake/gcc/g++
3) ПРОФИТ

То есть, я могу руками в vim написать Makefile, написать несколько .cpp файлов и одной командой make получать результат.

Причём так можно сделать даже гуй: берём Qt, пишем положения каждой кнопочки руками чиселками, возможно что-то в каких-нибудь там XML форматах, что тоже делается руками в vim, потом так же в vim можно сочинить примитивный файл .qrc всё ништяк. Мне не нужно для этого иметь QTCreator и фигачить окошки в конструкторах окошек.

В общем, хочется понимания такого же пути для ведроида.

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

Пару раз пробовал создавать хеллоу-ворлды в Android Studio. Это выглядело как пахание шести соток взводом межгалактических станций. Откуда в проекте овердохера каких-то файликов, папочек, иксэмелек и прочего говнища? Нахрен мне тыкать в эти окошечки, почему нельзя поменять какой-то XML файлик руками по понятному стандарту? Да-да, Manifest.xml я видел, но нахрена нужны остальные овер9000 файликов? Где среди них java код с моим main? Короче, проще застрелиться, какая-то жесть для дебилов. Мне не надо дизаен, я не хочу красиво, мне надо минимум байтов и производительность.

Дайте мануал по современному кодингу под ведроед для нормальных пацанов без овердохера херней.

В идеале хочется менять в .vim какой-нибудь комплект .java файликов, что-то править в каких-то XML там же в vim, что-то запускать в консоли и видеть результирующий APK.

Есть 40 крутых солнечных элементов с алиэкспресса 156x156мм мощностью на техпаспорте 4.5W (видимо в упор при подлёте к солнцу) 0.5V 9A, которые я могу объединять по-разному внутри панели - параллельно несколько групп, внутри которых они последовательно или все последовательно.

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

Правда ли, что лучше на выходе панели получить больше V и меньше A, чем меньше V и больше A?

P.S. Топик не о пропаганде солнечной энергетики, просьба не кидаться говнами о том, как это жесточайше невыгодно. Да, не выгодно - я потратил на 40 элементов ~4000 руб, а окупятся они в моём климате и моём странном желании юзать их внутри помещения за 175 лет. И это не учитывая стоимости корпуса панели, который надо будет из чего-то собрать - одно стекло оптивайт (не зелёное) таких размеров будет на пару косарей.

Перемещено leave из talks

Кажется объяснение в том, что ядро не видит глобальной картины, а видит только отдельные brk() (попытки выделения памяти), которые происходят почти всегда в любом безобидном процессе.

Допустим процесс 1 работает давно и делает brk() с частотой 1 Гц, а процесс 2 запустили только что и он делает brk() с частотой 50 Гц и отожрал почти всю свободную память. Но вызов brk(), первым столкнувшийся с концом памяти, по случайности исходил из процесса 1 и потому замочат именно его, а не 2?

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

Про OOM слышу истории, что постоянно невиновные страдают. Ну типа, «Вася, если ты запустишь на серваке свой говнопроцесс на 256 гигов и мой скромный на 36 гигов убьёт OOM, то я тебя зарублю топором!» В админских былицах постоянно мрут какие-то невиновные от OOM. Или это старые сказки уже и он научился убивать качественно.

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

Codeforces похоже немного про другое, там иногда запускаются соревнования, а в свободное форме порешать задачки там не дают или я кнопку не нашёл за 5 минут ознакомления.

Какова красная цена ipad pro 10.5 wi-fi 64GB за новый и за бушный в отл.сост?

Типа «loopstation».

1. Есть дорожки. Штук 8 хватит за глаза. Жму на первую дорогу, говорю в микрофон, дорога пишется. Желательно в стерео с 2 микрофонов. Останавливаю запись, запускаю play всех дорог.

2. Слыша все играющие дороги синхронно пишу новую. И так далее до посинения, заполняю все 8 дорог.

3. Софтина должна как loopstation уметь калиброваться - понимать какая задержка есть между записью данных в play-буфер и получением из record-буфера, то есть она должна понимать когда я услышал то, что она воспроизводила. То есть, чтобы если я захотел пропеть то же самое, что слышу, оно идеально наложилось в новом треке на старый по времени.

4. Обязателен экспорт всей получившейся хренотени в какой-нибудь .ogg / .mp3, но только не в .wav в обычном бесплатном режиме.

Вопрос - в абзаце 4.

КДПВ: https://powercoup.by/wp-content/uploads/2017/07/Mendosinskiy-motor-3.jpg — кстати самый клёвый дизайн девайса, который когда-то видел.

Мои параметры: солнечный элемент 0.5V 200ma (особо жирный) 70x20mm (4 штуки). Ну 200ma он даст только на экваторе конечно, тут ясно, но у меня давало ток КЗ в десятки ма. С проводом я до сих пор не разобрался, кругом разные советы, намотал 150 витков проводом 0.1 ... 0.12 (точно не смог понять его диаметр), сопротивление получилось дофига - ом 100 где-то. Длина полного витка - где-то 180 мм. Ну это ладно.

В общем, подвес готов. Ничего не сбалансировано, ротор просто висит-качается. Подключил только 1 обмотку с паре элементов. Если послать на какую-либо панель импульс света от белого светодиода смартфона в упор, то ротор может не сильно качнуться. Я думал - ладно, так и должно быть без баланса-то. «Сильно» оно уметь и не должно. Хотя интуитивно кажется, что на магнитном-то подвесе с источником, способном дать 30mA тока КЗ и сильном неодимовом магните должно резвее дёргаться.

Вопрос. Вот наиболее ясная из существующих в интернетах схема подключения одной обмотки к паре солнечных элементов: http://mozgochiny.ru/wp-content/uploads98983jkhdkjf9873/2016/03/13-429x600.jpg Я соединил солнечные элементы как показано тут - «минус-к-плюсу», обмоткой эту «пару» не нагружал и померял напругу на получившейся паре. Она расстраивает меня. При том, что один элемент был затемнён, а второй освещён, напруга была около 0.05V. В общем, один элемент нагружен на второй. Вроде логично, но непонятно как тогда живут все эти люди. Почему бы не исключить из нагрузки элемента второго собрата? Пускай элемент питает обмотку один. А второму подарить ещё одну дублирующую независимую обмотку. Сделать 4 обмотки, 2 из которых будут лежать в одном пазе и дублировать соседа, но питаться независимо разными элементами. В общем, чтобы ни у какого солнечного элемента в нагрузке не было собрата вообще. С другой стороны, я намерял сопротивление элемента где-то 30кОм, то есть элементы нагружены на 30 кОм собрата и это приводит к такому падению напруги? Причём это не страшно, т.к. сопротивление обмотки вообще на 2-3 порядка ниже при её подключении к паре элементов можно пренебречь нагрузкой 30 кОм, которую элементы создают друг другу, так? В общем, в этом и вопрос - считать ли плохим тот факт, что один элемент оказывается нагруженным вторым элементом и не надо ли попробовать запилить мою идею с 4 обмотками вместо двух, исключив элементы из нагрузки других элементов.

Ещё один вопрос про балансировку. Читал про это многа букаф, но есть своя простая идея: закрепить на валу крест (4 лопасти) из алюминия - вырезанный из алюминевой банки. От лопастей креста отрезаем по полмиллиметра материала - у той лопасти, которая находится с перевешивающей стороны. Крест на валу сурово фиксирован.

Есть некий тонкий провод. По кривым замерам, это 0.1mm или 0.15mm. Штук 8-10 витков уложилось в миллиметр. Мерял на глаз железной линейкой в потьмах. Провод медный, эмалированный, взят из катушки некого реле с габаритами 100x25x25mm.

Намотал я 160 витков диаметром где-то 60-70мм (большой диаметр, да, но так надо). Померял сопротивление - 110 Ом. Длину итогового провода не могу сказать. А точнее, там не диаметр катушки 60-70мм, а катушка имеет не круглую форму, а форму прямоугольника со сторонами 20 и 70мм. И то примерно.

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

Перемещено leave из talks

«Камерофоны» - фтопку. Это такие, у которых камера не мелкая, как у айфона, а жирная с выдвигающимся объективом как у цифромыльницы. Интересны именно малогабаритные не шевелящиеся мелкие камеры.

В штатном приложении делаю пальцами максимальный зум и фоткаю. Ясно, что это всегда интерполированная хрень, но часто бывает норм. Фоткаю на samsung note 4, у него дофига мегапикселей и оптический стаб, получается очень гуд. Например фотка телеги в далеке за окном, ресайзнутая потом вниз до 640x360 выглядит вполне чётко. Сравнивал по этому параметру note 4 с samsung note 8 — результат однохренственный, у note 4 мегапикселей больше, а в цифровой обработке фоток производитель видимо кардинально не продвинулся. Непонятно почему наличие двух камер в note 8, одна из которых типа с телеобъективом, не привели к победе. Если сравнить с samsung s8, то note 4 выигрывает даже больше и даже на обычных фотках. iphone X тестил и он тоже особо не даёт профита по этому критерию (zoom фотки). Тестил note 4 VS samsung S9 — у S9 мегапикселей формально меньше, но S9 уже победил note 4 по цифровому интерполированному зуму — чуть лучше читаются мелкие надписи на книжке в другом углу комнаты. Кое-какие тексты S9 смог прочитать, какие на note 4 не читаются совсем.

google pixel 2 нет в доступе, не мог потестить. Говорят он вообще космос, но по видеообзорам samsung note 8 вполне забарывает google pixel 2, так что непонятно чё ждать.

Чё-то прогресс в фотошпионаже как-то подзастрял на 2015 годе и на note 4.

Есть чё ещё?

P.S.

1. Да-да, это называется кадрирование, а не зум, зум - это когда трансфокация физическая работает, т.е. элементы объектива приводятся в движение и меняется фокусное расстояние.

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

1. Без рута.

2. Ради прикола желательно, чтобы фоткала обоими камерами сразу.

3. android 6.0.1, samsung note 4.

Вопрос не в жирноте тела, а тупо в чувстве обожратости.

Пойти в обед сожрать стандартный бизнес-ланч и потом иногда час сидеть охреневать от обожратости - задолбало.

Хочется как-то понять вообще науку жратвы. Что огранизму нужно, как это рассчитать и что можно жрать, чтобы не замечать этого вообще. В каких вообще параметрах это всё меряется, как всё работает. Цель: жрать не более чем функция, чтобы голода не было, но и никаких других ощущений тоже. Но без препаратов и аптек.

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

Есть ветка master, есть ветка sobaka.

В sobaka коммичу много коммитов. Делаю в неё merge мастера. Опять делаю коммиты. Sobaka запушена в origin. Ветка sobaka никому не нужна, она пушится только на случай смерти локального ноута, больше ни для чего.

Теперь хочется сделать так, чтобы к мастеру добавился 1 коммит, отражающий все изменения сделанные в sobaka с момента форка от мастера. Этот коммит должен содержать разницу между последним коммитом master и последним коммитом в sobaka. А ветку sobaka потом надо выкинуть и забыть.

Хочу как-то через git rebase, а не через --squash. Как именно?

Ноут XPS 13 9360. Монитор dell 2560x1440 с кучей входов, используется DisplayPort. Схема: ноут -> переходник usb-c / displayport (HP мелкий такой) -> dell моник.

Любая софтина показывает большое FPS, но на глаз реальное FPS низкое.

Как будто FPS в видеопамяти высокий, но до монитора кадры доходят реже, чем они рендерятся.

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

P.S. Незнаю что произошло, но всё починилось ребутом. До этого месяц не перезагружался, WebGL постоянно сдыхал в браузерах, всё еле шевелилось, а стало всё норм.

Перед ребутом что было обновлено за этот месяц чёрт знает.

Ещё перед ребутом в настройках самого монитора (через кнопки монитора и меню монитора) выставил DP1.2 = enabled, а было disabled и работало на DP1.1. Незнаю важно ли это, но сразу после смены этой настройки мониторы и ноутбучный экран стали чёрными, система подумала и монитор снова вывел картинку, но такую же тормозную. Кабель можно было попробовать выдернуть из порта, может бы помогло и без ребута.

Оказывается в природе существует вероятность того, что 1-2 метровый кабель теряет кучу энергии. Кривой кабель — и мобила уже не умеет fast charge. Чё за жопа, неужели так трудно воткнуть толстую медь...

Кто шарит, какие кабели на алиэкспрессе СЕЙЧАС рулят? Если читать обзоры годичной давности, то всех упомянутых брендов уже не существует в природе. В Китае всё происходит очень быстро. Только не «бери Ugreen», а конкретную ссылку и модель провода, которую лично вы тестили.

Adruino или Raspberry? Или это всё существовало 10 лет назад, а щас в моде другое? Знаю ещё есть семейство ESP8266 штуковин...

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

Есть ветка от мастера, в ней 10 коммитов.

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