Большие бинари в моем Rust?

Такс, попробуем...

#![no_std]

fn main(){
let x=10;
}

компилим: rustc main.rs

Получаем ошибку:

error: language item required, but not found: `panic_fmt`

error: language item required, but not found: `eh_personality`

error: aborting due to 2 previous errors

Rust, Eclipse и STM32

а у вас дебаг в RustDT нормально работает? Я пробовал RustDT и сразу наткнулся на 2 бага:

1. Если что-то поменять в программе и пытаться перекомпилить, то бывает выводится сообщение "Blocking waiting for file lock on build directory" — и компиляция не начинается
2. если у нас есть:
   

   fn func(v:&i32) {
   println!("v={}", v);
   }

   
   

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

   
   

Почему я отказался от Rust

Хотел посмотреть на это nangui-rust. К сожалению, не билдится ни сама либа ни примеры.

Uber — причины перехода с Postgres на MySQL

худжпэджэсы не включены.

Что означает в этом контексте «да и производительность будет оставлять желать лучшего»? Про особенности копирования вы рассказали, очевидно, вы предполагали нечто еще.

Насколько понял из моей тестовой проги, производительность проседает после хипа 4гб: 8гиг заполнялось раз 10дольше, чем 4. Видимо, аппаратная TLB-таблица, или какая-то другая таблица заканчивается — и оно переходит на полусофтварный способ трансляции физических адресов в логические.
Только вот, с форком это уже никак не связано. Но очевидно, гигансткие хипы тормозные сами по себе. Интересно, где этот порог у ксеонов.

Uber — причины перехода с Postgres на MySQL

По всей видимости, чтобы пометить каждую страницу памяти как copy-on-write — их надо все пробежать, возможно с подтягиванием каждой страницы в L0. Это конечно не копировать — но все равно какое-то время.

Навскидку:

#include <stdint.h>
#include <stdio.h>
#include <inttypes.h>
#include <stdlib.h>
#include <sys/types.h>
#include <unistd.h>

__inline__ uint64_t rdtsc() {
   uint64_t x;
  __asm__ volatile ("rdtscp\n\tshl $32, %%rdx\n\tor %%rdx, %%rax" : "=a" (x) : : "rdx");
   return x;
}

void test(size_t size){
    char * mem = (char *) malloc(size);

    uint64_t p;
    for(p=0; p<size; p++){
	mem[p] =(char) p%17;
    }

    uint64_t x = rdtsc();
    pid_t pid = fork();
    uint64_t diff = rdtsc() - x;

    free(mem);
    if (0==pid) exit(0);

    printf("%" PRIu64 "M -> %" PRIu64 "\n", size/(1024*1024), diff);
}

int main(){
int i;
for(i=0; i<14; i++)
    test(1024*1024LL*(1<<i) );
return 0;
}

результат(в тиках):

1M -> 378173
2M -> 421121
4M -> 429324
8M -> 438039
16M -> 447977
32M -> 477917
64M -> 554516
256M -> 980945
512M -> 1457601
1024M -> 2484345
2048M -> 4366125
4096M -> 7856287
8192M -> 15170437

Начиная с некоторого размера fork() с ростом размера время растет линейно. Когда размер памяти мал, то вероятно, работают кэши. На самом деле это может означать, что мой тест некорректен в этой части, но вцелом суть зависимости — ясна.

Uber — причины перехода с Postgres на MySQL

Немножко неочевидно вот это утверждение: "В Postgres на каждое соединение создается отдельный процесс. По сравнению с использованием потоков это более ресурсоемкое решение. На создание нового процесса требуется больше памяти, нежели на порождение нового потока."

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

Практическое применение LD_PRELOAD или замещение функций в Linux

Да, действительно. Частично помогло — теперь хоть по логам вижу, что либа загружается. А то что не красит stderr — это видимо там они, забыли перехватить что-то. По крайней мере, теперь работа этой штуки не выглядит как магия. Спасибо.

Практическое применение LD_PRELOAD или замещение функций в Linux

Есть либа https://github.com/sickill/stderred которая красит красным stderr, работает через LD_PRELOAD. Работает она неплохо, только почему-то вывод программы echo она не перехватывает, хотя с другими программами работает. Я специально вставлял вывод в лог в момент загрузки либы, и результат моих исследований — когда запускаешь echo «abcde» то LD_PRELOAD не срабатывает — по понятно, что раз не подгузило либу, то и перехват не сработает. А если запускаешь cat abcde — то срабатывает и либа подгружается.
Как такое может быть?

КВН: Купил — включил — не работает. О чём нельзя забывать при апгрейде памяти в компьютере

Если бы в 2.
К сожалению, это не амд дешевле в 2 раза, это интел дороже в 5.

Обзор компактных Linux дистрибутивов для системных администраторов

есть еще tinycore linux — 16мб в базовой комплектации, при этом они умудрились запихнуть туда иксы

Электронный микроскоп в гараже. Чёрный вакуум

Ого, цена. Не поверил, загуглил цену обозначенных марок масла. В Украине — чуть больше 100баксов за литр, плюс-минус.

Электронный микроскоп в гараже. Чёрный вакуум

Почему пары кипящего масла не являются источником дополнительного давления?

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

Электронный микроскоп в гараже. Чёрный вакуум

Тоже интересен этот момент. Может, там стоят сопла лаваля?

Космические лучи — причина случайных компьютерных сбоев?

ясно. Тогда я этот даташит не буду искать :) По крайней мере сегодня. Я пришел с работы задолбанный. Может потом…

Космические лучи — причина случайных компьютерных сбоев?

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

Вы когда говорите «все микросхемы — плоские», то подразумеваете вообще все, или все российские?

В чем принципиальная сложность? Вопрос не про конкретные микросхемы, и не про все существующие, а лишь про техническую возможность/невозможность: какая разница, заливать компаундом 1 кристалл или 2? Я не вижу ничего невозможного: 2 кристалла расположили как надо, припаяли куда надо перемычки и все залили керамикой. Если мы уже делаем так с 1 кристаллом, сделать с двумя — осуществимая задача, а взаимное расположение кристаллов в пространстве — неособо важная деталь (при условии что они не перекрывают доступ «жала паяльника»)

Космические лучи — причина случайных компьютерных сбоев?

Это очень странный вопрос. А в чем проблема? Две разные плоскости укладываются в трехмерное эвклидово пространство. Все ок там с геометрией. Я долго думал, что вы подразумеваете таким вопросом. Так и не придумал.

Я ж не предлагаю ядра ставить с самопересечением или взаимопересечением :))
Все происходит в пределах традиционной геометрии.

Или — я не понял вопроса. Можете спросить более развернуто?

Космические лучи — причина случайных компьютерных сбоев?

«Внешняя память используется с помехоустойчивым кодированием данных „
Да. Но ведь все равно есть шина, по которой данные бегают “после проверки ECC». И помехи там тоже могут возникать.
Я когда-то работал с подобной системой, и наткнулся, что memcpy копирует данные с изменением. Начали разбираться с аппаратчиками — оказалось какие-то предварительные настройки памяти плохие. И ничего не ругалось. Настройки мы поправили и все заработало, но вот почему ecc и прочие технологии не спасли — вопрос. Так что надо понимать, что это далеко не от всего защита.

Космические лучи — причина случайных компьютерных сбоев?

Бывает и в одной микросхеме несколько ядер. Можно гуглить что-то вроде «Dual CPUs in lockstep».

Космические лучи — причина случайных компьютерных сбоев?

«Все ядра лежат в плоскости своей микросхемы»
Мы же сейчас не говорим о какой-то конкретной микросхеме. А вы пишите так, как будто мы обсуждаем конкретную. Я вам привел как пример, что так делают.

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

А поток частиц понятно, что сломает все рано или поздно. С тем же успехом можно ломиком по микросхеме. Т.е., это вообще не панацея, а защита от вполне конкретного вида угроз.

Космические лучи — причина случайных компьютерных сбоев?

Вообще, одна частица физически не может пролететь «вдоль» по слою транзисторов обеих ядер: они же разнесены в пространстве.
Нарисуйте две перпендикулярные плоскости и пролетите одной частицей каждую «вдоль». Не получится в силу геометрии. Пролететь вдоль можно только 1 ядро.

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