Тогда же я читал, что по законам физики и аэродинамики майский жук не должен летать. А если его в масштабе увеличить, то вообще слов нет. Кстати, не будем забывать, что если мы кого-то увеличиваем в линейных размерах в два раза, то объем и, соответственно, масса увеличатся в 8 раз, а площадь (крыла тоже) только в 4 раза.
Как же можно было без предусилителя-корректора. К чему подключать. Есть у меня в кладовке "Вега-206" с Unitra G-602, в ней имеется усилитель, правда на транзисторах.
Интересно было бы сделать проигрыватель с лазерным считыванием. Такой был в продаже, японский.
Можно добиться, что не будет галлюцинаций вообще. На очень базовой штуке можно понять, как всё это работает. Гипотезы проверяю, интересно экспериментировать.
Обычно я железками управлял, но пока нет таких заказов, нашёл этот объект, "чтобы расти над собой" :)
Вообще -то речь здесь о перемещении частиц внутри предмета. Но можно и масштабировать. То есть, есть два предмета, например, шары электроыорной машины. Берём некий объект, предмет, касаемся более заряженного электронами вывода. Часть электронов переходит на наш предмет. Предмет теперь имеет потенциал, равный электроду машины. Потом перемещаем предмет к другому полюсу и касаемся его. При этом электроны перейдут на этот шарик. Происходит перенос заряда, то есть это и есть ток. Только здесь он будет не плавный, а пульсирующий.
Посмотрите
капельный электростатический генератор Кельвина.
в нем заряд переносится каплями воды.
В общем случае это вопрос терминологии. Тучи тоже переносят заряд и и.д.
Это точно. Хотел тоже написать. но Вы опередили. Когда открыли электрический ток. про электроны еще не знали, поэтому условились, что ток течет от плюса к минусу. Здесь как раз так и есть, положительно заряженные ионы движутся от плюса к минусу. В полупроводниках еще есть понятие "дырки" - атомы, у которых не хватает электронов. Поэтому у них положительный заряд.
Когда-то для "Жигулей" в хозтоварах продавали защитные наборы из цинковых пластин и проводов для монтажа на кузов. И наборы для цинкования.
Не мучаюсь. просто когда-то давно выяснял, что лучше. А C++ стараюсь не использовать (и требования часто такие), а в C - есть memcpy, я ее и внутри смотрел, и свою сделал, чтобы четко работала. (Иногда попадаются процессоры с несколько нестандатной памятью, например, которые только кратные адреса 4-м терпят на шине). А еще бывает, что на "голом железе" функции некоторые вообще не работают из стандартных библиотек или большие, приходится свои делать.
#include <stdio.h>
int i, number=777;
int src_data [20000000] = {0,1,2,3,4,5,6,7,8,9, };
int dst_data [20000000] = { };
int *src_ptr, *dst_ptr;
int main(void)
{
src_ptr = (int *)src_data;
dst_ptr = (int *)dst_data;
for ( i=0; i<20000000; i++) { dst_data [i] = src_data [i]; }
//for ( i=0; i<20000000; i++) { *dst_ptr++ = *src_ptr++; }
//dst_ptr = (int *)dst_data;
//for ( i=0; i<20; i++) { number = dst_data [i]; printf("num: %d\n", number ); }
return 0;
}
Примерно одинаковая скорость, если закомментировать строку 15 и раскомментировать строку 15. Точно - компилятор по своему делает, возможно, один и тот же ассемблерный код вставляет. Это на Intel. На ARM потом попробую. Раньше было так, что через указатели быстрее, но надо дихассемблировать.
Согласен. это было "образно". Думал написать *dst++=*src++ или dst++=some_data, но при вводе "*" тут текст становится курсивом, и это сбило с толку.. Речь, собственно о том, что при работе с указателями получалось быстрее, чем при работе с массивом с индексом.
У меня тоже сомнения. ARM архитектура, язык C (такие были всегда требования). Проверял, *dst=*src работает быстрее, чем dst[i]=src[j]. Массивы с указателем data[i] внутри (ассемблер) не смотрел. Но если они работают с байтами, то у них должно быть более сложное устройство кода. А вот указатели - смотрел. С байтами они не работают, в частности, была ситуация, память могла работать только с 32-битными словами. Если на шину адреса выставить число, не кратное 4-м - то получал исключение. В таком случае выход такой - делается на Ассемблере, проверяется выравнивание (на 1, 2. 3. 0) и производится переход на метку для этого случая. Работаем с 32-разрядными адресами, считывам данные, потом выделяем из них нужные байты и т.д. Чтобы было быстрее, применяем команду PLD (preload). Так и системная memcpy работает (не со всеми SoC). Но оно того стоит - скорость выше.
А теперь - немного про caches. На днях запустил микротрансформер на "голом железе" на Raspberry Pi Zero 2W. (Cortex-A53, 64 бита, 4 ядра). Сначала без кешей, мне надо было код изменять раньше. Работало, медленно. Включил кеши и MMU. Вместо ожидаемых 10...20 крат прироста скорости, получились все 40. Вот тут я начал сомневаться, а что если процессор берет данные не из ячеек памяти, где они актуальные, а из кеша и помещает также, где гарантия, что они - валидны. Тут есть вариант либо чтения несколько раз, пока не считается нужное, либо надо ставить барьер в памяти. И то, и другое -лишние циклы. А если несколько ядер, у каждого свои кеши - как они могул знать, что у кого в "мозгаз" пока не попадут в RAM. На "голом железе" легко можно включить/отключить кеши и сравнить. А в случае OC и Python? (Когда-то кеши можно было вклчать в BIOS, там же настраивать write-back, write-through). Были сообщения о дискредитации научных работ на Питоне, тогда списали на "разное представление чисел с плавающей запятой в разных процессорах". А что, если кеши виноваты - кто проверял.
Это мягко сказано. Все знают, что "Константин Циолковский - основоположник теории реактивного движения и космонавтики", Нам бы ещё наши теории претворять в жизнь.
Спасибо за материал. Была также информация, что пока американцы с англичанами ржали над идеей реактивного движения, немцы решили дать этому ход. Тогда и появились ФАУ и т. д. И те же самые американцы вывезли фон Брауна к себе. Кажется, им уже было не смешно. (Интересно, кто-нибудь за свою глупость отвечал или нет. Если лица должностные, то это уже халатность).
В детстве тоже делали ракеты, иа твердом "топливе", брали бумажный охотничий патрон, оклеивали его слоями бумаги, в нос - наконечник, и вперёд. Состав "топлива" тут приводить не буду, довольно просто всё. И наэкспериментировались. То ракета прыгнула высоко - отвалился бумажный патрон, то выдавила из себя "кашу" и не полетела, а поползла, то полетела, но по спирали. Сделали направляющую - прут. Подобрали размер стабилизаторов и получили нормальный полёт. И чего мы только не делали. Интернета тогда не было...
Был я разработчиком, больше не хочу. Заморозил свою пару приложений.
Было Pulta OBD2 Watchface. Сначала как приложение Потом оказалось, что циферблат удобнее - вскинул руку и посмотрел температуру двигателя на светофоре. Приложение устанавливалось в часы с приложения на телефоне. Потом после WearOS2 можно было автономное только для часов сделатьъ Сделал. То пользователи просили что-то добавить, то Google стал донимать. То для Bluetooth правила поменяли, то у них новые версии и надо было переделывать. А там - то одно depricated. то другое. Несет их вечно.
Сделал циферблат Quasar3D - натурально 3D, матрицы перекашивал, чтобы картинка идеально вписывалась в круг и не "эллипсила", программы для GPU с прследующей их трансляцией в часах...
Оба приложения мелькали в топе. Но не зашли. Знакомые сделали приложение, так они ежеднево немало денег на рекламу тратили. Хоть не напрасно получилось.
Кстати. Wear OS на новом телефоне у меня вообще не работает. Часы валяются (несколько штук). Думаю AsteroidOS установить, так сайт у нас не окрыл пока.
Популярность Андроида - заслуга не Google, а пользователей, которые своими приложениями его развили. А он - Google собрал Андроид из подручных материалов как бедный родственник. Кстати. много тысяч устройств Nexus 7 окирпичились из-за кривой прошивки. Google валит вину на Asus и наоборот. Подписи собирали., а один пользователь - уж лучше не буду говорить, что он сделал со своим планшетом.
Паспорт вроде не надо было представлять, права сошли, а вот адрес свой я им не дал.
Да уж, в этот раз свалить проблему на Asus не получится, как было в случае с Nexus 7.
Напомнило китайскую поговорку: "мудрость дана избранным, а законы - остальным". Но звучит несколько крамольно.
Точно.
Тогда же я читал, что по законам физики и аэродинамики майский жук не должен летать. А если его в масштабе увеличить, то вообще слов нет. Кстати, не будем забывать, что если мы кого-то увеличиваем в линейных размерах в два раза, то объем и, соответственно, масса увеличатся в 8 раз, а площадь (крыла тоже) только в 4 раза.
Как же можно было без предусилителя-корректора. К чему подключать. Есть у меня в кладовке "Вега-206" с Unitra G-602, в ней имеется усилитель, правда на транзисторах.
Интересно было бы сделать проигрыватель с лазерным считыванием. Такой был в продаже, японский.
Мне в детстве попалась книжка с гигантской окаменелой стрекозой. Ещё тогда я думал, что гравитация на Земле была меньше.
Пробовал, быстро и медленно. Не сбоит. Клавиатура HyperX полноразмерная. Позже попробую другие протестировать. Дома несколько штук.
Переключаю с помощью Ctrl+Shift, мне так удобнее, они рядом и можно одним пальцем нажать. И не сбоит, первый раз слышу, что проблема.
Удачи Вам в таком трудном деле, и не сдавайтесь. На Rust много подобных GPT проектов.
У меня вот тоже эксперименты - на Raspberry Pi Zero 2W попробую сделать нечто узкоспециализированное.
Не в плане рекламы, примерно как это выглядит:
https://rutube.ru/video/55c288c96846fd3402f6bf892df65f90/?r=a
https://rutube.ru/video/299ca79f5fb7d9a558bf2f8f1b7dda15/?r=a
Можно добиться, что не будет галлюцинаций вообще. На очень базовой штуке можно понять, как всё это работает. Гипотезы проверяю, интересно экспериментировать.
Обычно я железками управлял, но пока нет таких заказов, нашёл этот объект, "чтобы расти над собой" :)
Вообще -то речь здесь о перемещении частиц внутри предмета. Но можно и масштабировать. То есть, есть два предмета, например, шары электроыорной машины. Берём некий объект, предмет, касаемся более заряженного электронами вывода. Часть электронов переходит на наш предмет. Предмет теперь имеет потенциал, равный электроду машины. Потом перемещаем предмет к другому полюсу и касаемся его. При этом электроны перейдут на этот шарик. Происходит перенос заряда, то есть это и есть ток. Только здесь он будет не плавный, а пульсирующий.
Посмотрите
капельный электростатический генератор Кельвина.
в нем заряд переносится каплями воды.
В общем случае это вопрос терминологии. Тучи тоже переносят заряд и и.д.
Это точно. Хотел тоже написать. но Вы опередили. Когда открыли электрический ток. про электроны еще не знали, поэтому условились, что ток течет от плюса к минусу. Здесь как раз так и есть, положительно заряженные ионы движутся от плюса к минусу. В полупроводниках еще есть понятие "дырки" - атомы, у которых не хватает электронов. Поэтому у них положительный заряд.
Когда-то для "Жигулей" в хозтоварах продавали защитные наборы из цинковых пластин и проводов для монтажа на кузов. И наборы для цинкования.
Не мучаюсь. просто когда-то давно выяснял, что лучше. А C++ стараюсь не использовать (и требования часто такие), а в C - есть memcpy, я ее и внутри смотрел, и свою сделал, чтобы четко работала. (Иногда попадаются процессоры с несколько нестандатной памятью, например, которые только кратные адреса 4-м терпят на шине). А еще бывает, что на "голом железе" функции некоторые вообще не работают из стандартных библиотек или большие, приходится свои делать.
Примерно одинаковая скорость, если закомментировать строку 15 и раскомментировать строку 15. Точно - компилятор по своему делает, возможно, один и тот же ассемблерный код вставляет. Это на Intel. На ARM потом попробую. Раньше было так, что через указатели быстрее, но надо дихассемблировать.
Согласен. это было "образно". Думал написать *dst++=*src++ или dst++=some_data, но при вводе "*" тут текст становится курсивом, и это сбило с толку.. Речь, собственно о том, что при работе с указателями получалось быстрее, чем при работе с массивом с индексом.
Думал про это, но главное - не попасть впросак, Вы знаете, как тут бывает - засмеют и фамилию не спросят :)
У меня тоже сомнения. ARM архитектура, язык C (такие были всегда требования).
Проверял, *dst=*src работает быстрее, чем dst[i]=src[j]. Массивы с указателем data[i] внутри (ассемблер) не смотрел. Но если они работают с байтами, то у них должно быть более сложное устройство кода. А вот указатели - смотрел. С байтами они не работают, в частности, была ситуация, память могла работать только с 32-битными словами. Если на шину адреса выставить число, не кратное 4-м - то получал исключение. В таком случае выход такой - делается на Ассемблере, проверяется выравнивание (на 1, 2. 3. 0) и производится переход на метку для этого случая. Работаем с 32-разрядными адресами, считывам данные, потом выделяем из них нужные байты и т.д. Чтобы было быстрее, применяем команду PLD (preload). Так и системная memcpy работает (не со всеми SoC). Но оно того стоит - скорость выше.
А теперь - немного про caches. На днях запустил микротрансформер на "голом железе" на Raspberry Pi Zero 2W. (Cortex-A53, 64 бита, 4 ядра). Сначала без кешей, мне надо было код изменять раньше. Работало, медленно. Включил кеши и MMU. Вместо ожидаемых 10...20 крат прироста скорости, получились все 40. Вот тут я начал сомневаться, а что если процессор берет данные не из ячеек памяти, где они актуальные, а из кеша и помещает также, где гарантия, что они - валидны. Тут есть вариант либо чтения несколько раз, пока не считается нужное, либо надо ставить барьер в памяти. И то, и другое -лишние циклы. А если несколько ядер, у каждого свои кеши - как они могул знать, что у кого в "мозгаз" пока не попадут в RAM.
На "голом железе" легко можно включить/отключить кеши и сравнить. А в случае OC и Python? (Когда-то кеши можно было вклчать в BIOS, там же настраивать write-back, write-through). Были сообщения о дискредитации научных работ на Питоне, тогда списали на "разное представление чисел с плавающей запятой в разных процессорах". А что, если кеши виноваты - кто проверял.
P.S. На видео (RuTube) видно, как ядро 0 работает в сравнении с остальными:
https://rutube.ru/video/55c288c96846fd3402f6bf892df65f90/?r=a/
Это мягко сказано. Все знают, что "Константин Циолковский - основоположник теории реактивного движения и космонавтики",
Нам бы ещё наши теории претворять в жизнь.
Спасибо за материал. Была также информация, что пока американцы с англичанами ржали над идеей реактивного движения, немцы решили дать этому ход. Тогда и появились ФАУ и т. д. И те же самые американцы вывезли фон Брауна к себе. Кажется, им уже было не смешно. (Интересно, кто-нибудь за свою глупость отвечал или нет. Если лица должностные, то это уже халатность).
В детстве тоже делали ракеты, иа твердом "топливе", брали бумажный охотничий патрон, оклеивали его слоями бумаги, в нос - наконечник, и вперёд. Состав "топлива" тут приводить не буду, довольно просто всё. И наэкспериментировались. То ракета прыгнула высоко - отвалился бумажный патрон, то выдавила из себя "кашу" и не полетела, а поползла, то полетела, но по спирали. Сделали направляющую - прут. Подобрали размер стабилизаторов и получили нормальный полёт. И чего мы только не делали. Интернета тогда не было...
Был я разработчиком, больше не хочу. Заморозил свою пару приложений.
Было Pulta OBD2 Watchface. Сначала как приложение Потом оказалось, что циферблат удобнее - вскинул руку и посмотрел температуру двигателя на светофоре. Приложение устанавливалось в часы с приложения на телефоне. Потом после WearOS2 можно было автономное только для часов сделатьъ Сделал. То пользователи просили что-то добавить, то Google стал донимать. То для Bluetooth правила поменяли, то у них новые версии и надо было переделывать. А там - то одно depricated. то другое. Несет их вечно.
Сделал циферблат Quasar3D - натурально 3D, матрицы перекашивал, чтобы картинка идеально вписывалась в круг и не "эллипсила", программы для GPU с прследующей их трансляцией в часах...
Оба приложения мелькали в топе. Но не зашли. Знакомые сделали приложение, так они ежеднево немало денег на рекламу тратили. Хоть не напрасно получилось.
Кстати. Wear OS на новом телефоне у меня вообще не работает. Часы валяются (несколько штук). Думаю AsteroidOS установить, так сайт у нас не окрыл пока.
Популярность Андроида - заслуга не Google, а пользователей, которые своими приложениями его развили. А он - Google собрал Андроид из подручных материалов как бедный родственник. Кстати. много тысяч устройств Nexus 7 окирпичились из-за кривой прошивки. Google валит вину на Asus и наоборот. Подписи собирали., а один пользователь - уж лучше не буду говорить, что он сделал со своим планшетом.
Паспорт вроде не надо было представлять, права сошли, а вот адрес свой я им не дал.
Bye-bye Google...
Привет, брат по разуму! :-)
У меня от OCZ есть и несколько SSD, и флешки. И ещё OSZ NIA (нейро импульсный актуатор).
Все до сих пор отлично работают.