Не, тут как раз принципиально разных хард. Есть смысл рассматривать только систему софт+хард в целом. Ибо софт не может быть взаимозаменён (с мозга на комп и обратно тоже).
Частота не показатель. Достаточно только взглянуть на фото, мысленно вытащить оттуда предмет и покрутить. А потом повторить это на своём интл корэ. В конце концов ИИ поймёт что любая существующая вычислительная мощность для него мала и данные хранить негде. Тогда он начнёт разрабатывать алгоритмы сжатия нескольких гигабайт в один байт. Может быть выпустит BolgenOS. (Чёрт, ИИ подменил мой комментарий на какую то ахинею).
Пару лет назад, один менеджер из МТС говорил мне, что если абонент тратит 150 рублей в месяц — то он выгоден. Что-то вроде нижней границы. Так что где то Вы, господин, ошибаетесь. Или я ошибаюсь по поводу среднестатистического абонента. Я когда больше 500 рублей тратил (в среднем от 500 до 1000, но это было лет 5 назад) мне звонили и спрашивали всякую ерунду (вроде доволен ли я качеством [...], какие услуги мне бы пригодились и т.д.; оператор не МТС). Да и вообще в Москве и МО цены на услуги мобильной связи завышены по сравнению с остальной РФ. Ещё краем уха слышал, что на Дальнем Востоке за никудышный мобильный интернет берут очень много — может они там, в плане интернета, и больше чем в Москве платят.
Да проще аэростат сделать. Атмосферное давление высокое, значит держаться он будет довольно высоко. Вдали от критических условий. Его будет переносить атмосферными потоками, а он в свою очередь по мере перемещения будет скидывать зонды на землю. Зонды не вечные, а временные. Для аэростата даже реально сделать солнечные батареи. Основная проблема это материал — если метал, то аэростат получится большим и будет сидеть низко в атмосфере из-за массы (солнечные панели отпадают, транспортировка с земли затруднена, условия более жесткие — кто знает какие там на Венере ветра). Предполагаю какой-нибудь многослойный графен раздутый гелием. Или что-нибудь вроде карбона — только гибкое как ткань. Ну это тоже с позиции дилетанта.
У меня с Хром c 15-тью вкладками жесткими рывками только поворачивает. Что то я не понял где покупать боеприпасы и где база марсиан, которую надо разнести? Кто-нибудь уже сражался с боссом?
Я переписал Ваш код на C и что меня удивило. Если компилировать без оптимизации — то результат: небольшое отставание когерентного массива.
sh-4.3$ gcc -o main *.c
sh-4.3$ main
Coherent array avg search - 5187.44 μs
1048575
Random array avg search - -4005.54 μs
1048575
Но при оптимизации (Bang!) Random выхватывает по полной.
sh-4.3$ gcc -O3 -pipe -fomit-frame-pointer -Wall -Werror -o main *.c
sh-4.3$ main
Coherent array avg search - 2837.95 μs
1048575
Random array avg search - 4514.26 μs
1048575
И это ещё не самое главное. При ещё большем ускорении ситуация для Random только хуже (Тарарах-тах-тах!):
sh-4.3$ gcc -march=native -O3 -pipe -fomit-frame-pointer -Wall -Werror -o main *.c
sh-4.3$ main
Coherent array avg search - 2686.56 μs
1048575
Random array avg search - 4637.16 μs
1048575
Прикол в том, что, чем сильнее оптимизация тем сильнее замедляется Random и сильнее ускоряется Coherent. Ну и ну. Хотел бы я знать про эти подводные камни.
Вот код.
Ну, так-то workers придуманы, чтобы не грузить GUI поток. Вот и всё. Это как в Android (образно). Все тяжеловесные задачи выполняются в фоне — и в результате картинка не прыгает, отклик на мышь нормальный. А повышения производительности не добиться. Что быстрее js или js?
Масла жечь он будет не больше чем классический ДВС. Ибо поршень трётся об уплотнения, а те смазываются, сами масло и обратно сошкрябывают. У Ванкеля масло к поршню иначе не подведёшь, кроме как брызгать в камеру или бодяжить с топливом. А тут этой проблемы нет.
Всегда работает. ping — это проверка связи, в данном случае ..56.1 адрес хоста. А вот netcfg eth1 dhcp я так и не дождался завершения (впрочем долго я не ждал — убивал через полминуты).
Судя по всему, теперь поддерживает, вот референс на пример использования прото-файл и дерево примера. Впрочем явного указания что «да, поддерживает» я не нашёл, только директиву syntax="proto3";
Здесь рекомендуется использовать третью версию (Proto3) для gRPC, а Вы какой пользуетесь (всё-таки третья сыровата, а со второй вероятные проблемы в перспективе — дилемма)?
-fomit-frame-pointer — позволит избавиться от мусора в коде (возня со стеком) -Wl,--strip-all — выпиливает символы (экспресс похудение)
776B — таков размер ELF-а
Обращаю Ваше внимание, что -nostdlib напрочь отменяет все подготовительные и завершающие процедуры. Конкретно: аргументов argc, argv, env не будет, ну и как Вы уже смогли убедиться — вызывать выход нужно вручную. Попробуйте заменить
asm("xorq %rdi, %rdi");
на
asm("movq $97, %rdi");
И после компиляции проверить с каким кодом завершилась суперфункциональная программа.
Для bash например это
$ echo $?
Системная функция exit() принимает код возврата в %rid. А xorq %rdi, %rdi, уверен Вам известно — это обнуление регистра. Если нужны аргументы или переменные окружения, то они лежат в стеке и на самой верхушке лежит argc.
P.S.: приятно компилировать свою программку (не эту) на С с флагом -O3 и осознавать что бородатые дядьки, что пилят gcc применяют хвостовую рекурсию.
Были проблемы с gccgo, когда использовал горутины. Решается использованием линкера gold замест ld (в binutils 2.22+ он есть). У меня gccgo собран из сырья, версия 4.10.0 20140719 (experimental). Рекомендую, т.к. более новая. Насчёт флагов я лично не мелочусь:
Но большие пакеты так собирать не приходилось. Так что будьте осторожны. Ещё хочу отметить, что в версии gccgo (Ubuntu 4.9.1-0ubuntu1) 4.9.1 стрип (-Wl,--strip-all) портит всё. Сама по себе опция -Ofast считается не рекомендуемой (gentoo вики), а вот насчёт -O3vs.-O2 скажу прямо — используйте -O3 для узких мест не стесняясь. Мои исследования ассемблерного листинга с этими флагами показали меньший размер и эффективное использование хвостовой рекурсии с флагом -O3. Не мешало бы добавить, что простора для жёсткого «инлайнинга» в моём примере у компилятора не было (что значит, при иных раскладах размер может и увеличиться).
Помимо всего вышесказанного, если использовать в своих программах пакет syscall, то gccgo (упомянутых выше версий) выдаст ошибку — такие пакеты компилируются только golang-go (или нужно подождать патчей). Ну и разумеется не получиться использовать плюшки go 1.4 (что впрочем не сильно напрягает).
LZMAv2 (да наверное и v1) сжимает не хуже GZIP и не медленнее — я имею ввиду LZMA со степенью сжатия 1, против GZIP со степенью сжатия 9. Иногда даже выходит, что LZMA сжимает сильней и быстрее (чего не скажешь про распаковку). Собственно референс. Ну и напоследок то, что я тут в консоли натыкал протестировал:
Исходный HTML с http://ya.ru:
Степень сжатия | размер, байт
В чистом виде | 9118
gzip/xz -1 | 3780 / 3584
gzip/xz -6 | 3515 / 3488
gzip/xz -9 | 3514 / 3488
Js с http://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML:
Степень сжатия | размер, байт
В чистом виде | 58757
gzip/xz -1 | 20809 / 17616
gzip/xz -6 | 17643 / 16636
gzip/xz -9 | 17607 / 16636
Собственно по потребляемым ресурсам GZIP-у нет равных (смотри референс). Замечание: у LZMA (по крайней мере у консольной команды xz) степень сжатия — это не степень сжатия, а количество памяти, которая понадобиться для распаковки, но оно влияет на степень сжатия.
Так же я не предусмотрел возможности обледенения конструкции. На ночной стороне наверное холодно в верхних слоях.
Но при оптимизации (Bang!) Random выхватывает по полной.
И это ещё не самое главное. При ещё большем ускорении ситуация для Random только хуже (Тарарах-тах-тах!):
Прикол в том, что, чем сильнее оптимизация тем сильнее замедляется Random и сильнее ускоряется Coherent. Ну и ну. Хотел бы я знать про эти подводные камни.
Вот код.
Всегда работает.
ping— это проверка связи, в данном случае ..56.1 адрес хоста. А вотnetcfg eth1 dhcpя так и не дождался завершения (впрочем долго я не ждал — убивал через полминуты).syntax="proto3";-Ofastне взлетел, а вот с-O3норм.-fomit-frame-pointer— позволит избавиться от мусора в коде (возня со стеком)-Wl,--strip-all— выпиливает символы (экспресс похудение)776B — таков размер ELF-а
Обращаю Ваше внимание, что
-nostdlibнапрочь отменяет все подготовительные и завершающие процедуры. Конкретно: аргументовargc, argv, envне будет, ну и как Вы уже смогли убедиться — вызывать выход нужно вручную. Попробуйте заменитьasm("xorq %rdi, %rdi");на
asm("movq $97, %rdi");И после компиляции проверить с каким кодом завершилась
суперфункциональнаяпрограмма.Для
bashнапример этоСистемная функция
exit()принимает код возврата в%rid. Аxorq %rdi, %rdi, уверен Вам известно — это обнуление регистра. Если нужны аргументы или переменные окружения, то они лежат в стеке и на самой верхушке лежитargc.P.S.: приятно компилировать свою программку (не эту) на С с флагом
-O3и осознавать что бородатые дядьки, что пилятgccприменяют хвостовую рекурсию.goldзаместld(в binutils 2.22+ он есть). У меня gccgo собран из сырья, версия 4.10.0 20140719 (experimental). Рекомендую, т.к. более новая. Насчёт флагов я лично не мелочусь:Но большие пакеты так собирать не приходилось. Так что будьте осторожны. Ещё хочу отметить, что в версии gccgo (Ubuntu 4.9.1-0ubuntu1) 4.9.1 стрип (
-Wl,--strip-all) портит всё. Сама по себе опция-Ofastсчитается не рекомендуемой (gentoo вики), а вот насчёт-O3vs.-O2скажу прямо — используйте-O3для узких мест не стесняясь. Мои исследования ассемблерного листинга с этими флагами показали меньший размер и эффективное использование хвостовой рекурсии с флагом-O3. Не мешало бы добавить, что простора для жёсткого «инлайнинга» в моём примере у компилятора не было (что значит, при иных раскладах размер может и увеличиться).Помимо всего вышесказанного, если использовать в своих программах пакет
syscall, то gccgo (упомянутых выше версий) выдаст ошибку — такие пакеты компилируются только golang-go (или нужно подождать патчей). Ну и разумеется не получиться использовать плюшки go 1.4 (что впрочем не сильно напрягает).в консоли натыкалпротестировал:Исходный HTML с
http://ya.ru:Js с
http://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML:Собственно по потребляемым ресурсам GZIP-у нет равных (смотри референс).
Замечание: у LZMA (по крайней мере у консольной команды
xz) степень сжатия — это не степень сжатия, а количество памяти, которая понадобиться для распаковки, но оно влияет на степень сжатия.Рискну предположить, что эта галактика образовалась вокруг чёрной дыры, а не ЧД в центре галактики.