> дня
> до x86 этим железкам крайне далеко.
> Пруфы были предоставлены, тема закрыта.
> Не увидел физики на скриншотах
> 1я причина — графон в 3D играх говно.
> Ты чересчур невнимателен.
> нормальную ось
> файрфокс> ось
> И чем же?
> , и не
> хочу смартфон с ней купить
> И в теории не должно так тормозить
> Всё на HTML5.
> Т.е даже просто открытое меню\звонилка будут жрать по 300 мегов оперативки
> когда могут космическими ракетами управлять.
> оболочка для убогого вебкита> объективно это лучший браузер на ведро, который не просто лучше, а опережает всех своих конкурентов на голову.
> любой браузерделать умеет> хуйню ты несешь
> Я не слышал что ведро заражается через дырки в системе.
> Жаль как и в последнем дельфине нету стрелки для быстрой прокрутки вверх
> Умеет в юзерскрипты
> букмарклеты
> Я не ебу, что это за хрень и почему про них везде говорят.
> Почему ты еще здесь, а не устанавливаешь этот вин?
> Видимо тебе не везло со шмотом.
> Пользовался HikkiPlayer
> И всё это работает без проблем уже не первый год на разных девайсах> на разных девайсах
> А если он уже куплен в гуглоплее, то как-нибудь возможно оторвать оттуда его активацию?
> Где гарантия, что ты версию без дрм всем друзьям не раздашь?
> Он не ванильный. Это сонибрак, модель третья, компактная. Запись видео с экрана была на нём и в предыдущей прошивке на 4.4.
> Он не ванильный.
> Замечательная кастомизация
> On the left we see the rather slim power button options for Android 5.0 Lollipop, and on the right, CyanogenMod 11.
> and on the right, CyanogenMod 11.
> в CyanogenMod 11 есть свой движок для смены тем.
> передавать запись с экрана на пеку
> Textra
> Дерганье телефона для попадания по "drums" нотам можно выключить в настройках.
> coreutils> операционная система GNU> > > В треде божественного Android/Linux
> > > В треде божественного Android/Linux
/system/bin/sh
> почему раздел называется LOR
> > ... расшифровка названия раздела ...
> встроенные калькуляторы которой всяко лучше и быстрее каких-то "приложений".
> Бред красноглазого фанатика.
> ты собираешься доказывать, что дело в коде> быстрее
> код не решает, насколько быстро будет работать код
> насколько быстро будет работать код
> что ты к нему так прицепился?
> код, особенно на простых арифметических операциях, не определяет скорость выполнения задачи
#include <stdio.h> unsigned long long int f(register unsigned long long int n) { if (n < 2) return 1; else return f(n - 2) + f(n - 1); } int main() { register unsigned long long int x = f(40); printf("%llu\n", x); }
#!/usr/bin/perl use strict; sub f($) { my $i = $_[0]; if ($i < 2) { return 1; } else { return f($i - 2) + f($i - 1); } } my $x = f(40); print "$x\n";
#!/usr/bin/python def f(n): if n < 2: return 1 else: return f(n - 2) + f(n - 1) x = f(40) print x
#!/usr/bin/php-cgi <?php function f($n) { if ($n < 2) { return 1; } else { return f($n - 2) + f($n - 1); } } $x = f(40); echo "$x\n";
$ gcc -O3 -o test test.c && time ./test 165580141 real 0m0.423s user 0m0.420s sys 0m0.000s $ time ./test.pl 165580141 real 1m52.468s user 1m52.340s sys 0m0.012s $ time ./test.py 165580141 real 0m40.899s user 0m40.848s sys 0m0.004s $ time ./test.php PHP Fatal error: Maximum execution time of 30 seconds exceeded in /tmp/test.php on line 8 Status: 500 Internal Server Error Content-type: text/html; charset=UTF-8 real 0m30.039s user 0m29.992s sys 0m0.012s $ echo "max_execution_time=9000" >> php.ini $ time ./test.php [...] 165580141 real 0m52.483s user 0m52.392s sys 0m0.024s
fork()
return 0;
> меряет скорость вычисления чисел Фибоначчи рекурсивной функцией за O(Ф^N) (Ф ≈ 1.62), когда есть алгоритмы за O(N) и даже за O(log(N))> register> -O3
> использует максимальную оптимизацию на сях> не использует прекомпилированный выхлоп с цитона или пипи для питона
register
f(40)
int
0
EXIT_SUCCESS
-O3
-finline-functions
$ gcc -o test test.c && time ./test 165580141 real 0m1.004s user 0m1.000s sys 0m0.000s
$ gcc -o test test.c && time ./test 165580141 real 0m0.998s user 0m0.996s sys 0m0.000s
> Компилятор сам разберётся, что разложить по регистрам.
> register> 32-битный int
> int32t (и возвращать не 0, а EXITSUCCESS).
> -O3 зачастую делает только хуже.
> чистый грязный цикл
int a = 1, b = 1; for(int i = 0; i < 40; ++i) { int old_b = b; b += a; a = old_b; } printf("%d\n", a);
using System; using System.Diagnostics; class Program { private static long f(long n) { if (n < 2) return 1; return f(n - 2) + f(n - 1); } static void Main(string[] args) { var stopwatch = new Stopwatch(); stopwatch.Start(); var result = f(40); stopwatch.Stop(); Console.WriteLine("Result: {0}", result); Console.WriteLine("Time: {0}", stopwatch.Elapsed); } }
Result: 165580141 Time: 00:00:00.9947558
> у тебя 40 сложений в цикле 0m0.423s выполняются
> Исходник:
> Это вообще что?
> Я не понимаю, как у вас там что работает. Ты показывай время запуска исполняемого файла с нуля.
using System; class Program { private static long f(long n) { if (n < 2) return 1; return f(n - 2) + f(n - 1); } static void Main(string[] args) { var result = f(40); Console.WriteLine("Result: {0}", result); } }
PS D:\Projects\TestProject\bin\Release> Measure-Command {.\TestProject.exe | Out-Default } Result: 165580141 Days : 0 Hours : 0 Minutes : 0 Seconds : 1 Milliseconds : 13 Ticks : 10133275 TotalDays : 1,17283275462963E-05 TotalHours : 0,000281479861111111 TotalMinutes : 0,0168887916666667 TotalSeconds : 1,0133275 TotalMilliseconds : 1013,3275
> C#
> результат работы дисковой подсистемы, кэширования и прочих факторов
> string[] args
> Milliseconds : 13
> Seconds : 1
> Я хочу увидеть готовую программу, которую я смогу скачать и запустить на своём компьютере.
PS D:\Projects\TestProject> Get-Content .\Program.cs using System; class Program { private static long f(long n) { if (n < 2) return 1; return f(n - 2) + f(n - 1); } static void Main(string[] args) { var result = f(40); Console.WriteLine("Result: {0}", result); } } PS D:\Projects\TestProject> C:\windows\Microsoft.NET\Framework64\v4.0.30319\csc.exe /optimize+ /out:Program.exe /target:exe Program.cs Microsoft (R) Visual C# Compiler version 4.6.0079.0 for C# 5 Copyright (C) Microsoft Corporation. All rights reserved. This compiler is provided as part of the Microsoft (R) .NET Framework, but only supports language versions up to C# 5, w hich is no longer the latest version. For compilers that support newer versions of the C# programming language, see http ://go.microsoft.com/fwlink/?LinkID=533240 PS D:\Projects\TestProject> Measure-Command {./Program.exe | Out-Default} Result: 165580141 Days : 0 Hours : 0 Minutes : 0 Seconds : 0 Milliseconds : 725 Ticks : 7251925 TotalDays : 8,39343171296296E-06 TotalHours : 0,000201442361111111 TotalMinutes : 0,0120865416666667 TotalSeconds : 0,7251925 TotalMilliseconds : 725,1925 PS D:\Projects\TestProject>
> О какой дисковой подсистеме, кэшировании и прочих факторах ты говоришь, содомит?
> > string[] args> Почему ты не випилил это? Или это так задумано?
> > string[] args
> Подловил. Подловил всё-таки, засранец.
> C:\windows\Microsoft.NET\Framework64\v4.0.30319\csc.exe /optimize+ /out:Program.exe /target:exe Program.cs
> Ни разу в жизни не компилировал дотнетные программы вне визуальной студии, но чего не сделаешь ради анона.> не компилировал программы вне IDE
> дело в отладочной информации
> мой первый пример (с замером времени только арифметики) отработал за 995 мс
> ты мне сейчас собираешься доказывать, что криво слепленный java-быдлокод будет быстрее оптимизированного кода на C?
> минимум настолько же быстро> мелкософтовская поделка может работать минимум в два раза медленнее, чем код на Си
#!/usr/bin/sbcl --script (defun f (n &optional (n1 0) (n2 1) (sum 1)) (if (<= n 0) n1 (f (- n 1) n2 sum (+ n2 sum)))) (format t "~D~%" (f 100000))
$ time ./test.lisp 25974069347221724166155034021275915414880485386517696584724770703952534543511273 [...] 60895603514383883939018953166274355609970015699780289236362349895374653428746875 real 0m0.242s user 0m0.212s sys 0m0.028s
Base -> ChildOne
Base -> Child2
using System; using System.Numerics; class Program { private static BigInteger f(int n, BigInteger n1, BigInteger n2, BigInteger sum) { if (n <= 0) return n1; return f(n - 1, n2, sum, n2 + sum); } static void Main(string[] args) { var result = f(100000, BigInteger.Zero, BigInteger.One, BigInteger.One); Console.WriteLine("Result: {0}", result); } }
open System.Numerics let rec f(n : int, n1 : BigInteger, n2 : BigInteger, sum : BigInteger) : BigInteger = if n <= 0 then n1 else f(n - 1, n2, sum, n2 + sum) [<EntryPoint>] let main argv = let result = f(100000, BigInteger.Zero, BigInteger.One, BigInteger.One) printfn "Result: %O" result 0 // return an integer exit code
PS D:\Projects\FSharpRecursionTest\bin\Release> Measure-Command {./FSharpRecursionTest.exe | Out-Default} >>> Result: 259740693472217241661550340212759154148804853865176965847247707039525345435112736862655567728367167447546375872 ... 5660895603514383883939018953166274355609970015699780289236362349895374653428746875 Days : 0 Hours : 0 Minutes : 0 Seconds : 0 Milliseconds : 622 Ticks : 6227452 TotalDays : 7,20769907407407E-06 TotalHours : 0,000172984777777778 TotalMinutes : 0,0103790866666667 TotalSeconds : 0,6227452 TotalMilliseconds : 622,7452
> TotalMilliseconds : 622,7452
> Сравнивать производительность языков тупыми числодробилками с обычными циклами бесполезно, ибо оно в итоге всё равно скомпилится в нативный код.
> Заметная разница в производительности появится лишь в большом и сложном коде, где основным влияющим фактором является эффективность использования кэша инструкций и данных, к примеру в виде частоты и паттерна обращений к памяти. А если там есть еще и многопоточность, всё становится экспоненциально сложнее.
> Ты же понимаешь, умник, что твой лиспокод работает совсем не так, как работал предыдущий пример?
> Разница не так велика, ящитаю.
> компилятор может решить, что результат вычисления не используется
> Это не мои трудности, что все реализации Common Lisp'а по стандарту обязаны поддерживать хвостовую рекурсию.
> Лисп это на самом деле читаемый язык программирования
> C* это всё ещё байтоёбство
> Анон, посоветуй калькулятор.> Тредрелейтед.
> Лолчто? Это и есть нативный код и это вот именно что не циклы.
> Кобол или ассемблер?
> MICOROSOFT'О-ОПТИМИЗАЦИИ.
> Плохо быть тобой, анон.
> Как по мне, это всего лишь месиво из скобок и неизвестно откуда вылезающих имён функций и переменных, да ещё и черезжопная запись операций всё осложняет.
> Справедливо, если убрать звёздочку.
> int> BigInteger
> Если ты не видишь разницу между функциональным подходом™ и своими циклами, то мне тебя жаль.
> Потому что Лисп это всего лишь надстро разрабатывался как язык, который будет лёгок для изучения людям, знакомым с математикой (не-гуманитариям)
> то есть необходимость явно указывать тип чисел и "ручное управление памятью"
inline intrinsic
const
> это нормальная практика использовать [UTF-8] в названиях функций и переменных, например.
> а память уже никогда не высвободится после её выделения
> всё равно в итоге будет jump
for (;;)
> с плюсами
> это в любом нормальном компиляторе есть
> ...любого нормального функционального языка.
> Я что-то пропустил, или все не-гуманитарии внезапно перешли на префиксную польскую запись?
> + 2 (* 2 2)
> Статическую типизацию и ручное управление памятью я бы не стал относить к байтоёбству.
> Готов поспорить, тебе просто не попадался код с индусскими письменами или лунными закорючками в названиях функций и переменных.
> Можно, но придется поебаться.
> пхп до недавно времени
> в плюсах
> Ты сваливаешься в демагогию, задавая границы "байтоёбства" по образу и подобию своего любимого языка.
> в Лиспе это вообще никаких затруднений не вызывает и даже добавляет шарма коду.
> C в худших его проявлениях
> укажи размер проекта
> Ты используешь их неправильно, анон, поверь мне.
> Добавить одно-единственное слово register и ты уже байтоёб?
> 1100 строк
> Ты бы наверняка изменил своё мнение, если б тебе пришлось поддерживать проект в ~100 раз больше, где все функции и их параметры были бы названы на каком-нибудь древнеклингонском языке.
> [Лисп] для студенческих хелловорлдов> хелловорлд на функциональном языке
- hanabira 0.6.1320- + wakaba + futallaby + futaba -
