@laacz tvītu arhīvs

Ziniet, kas ir traki ar to Swift plāniem par lingua franca? Tas nejēdz būt mazs un ātrs. Triviālākais uzdevums no AoC 2020. Atrast 200 skaitļu virknē trīs, kuri summā dod 2020. Bruteforce ar PHP - 1.5s. Bruteforce ar Swift: 40s. IMHO pat Java outperformētu par kārtu.

@laacz @aiidziis

@laacz Es droši vien kaut ko nesaprotu. PHP versijā Tu lasi failu 3 reizes? Kāpēc neielasi vienā mainīgajā 1x? Un Swift, kāpēc 1x nenomappo lines uz masīvu/listi ar Int un tad nelieto uzreiz tos?

@aspruds Tāpēc, ka fundamentāli veiktspējā tas neko nemainīs.

@jurgenzz @laacz Reku šajā thread arī daudz atklāsmes par Swift un Uber pieredzi: https://twitter.com/StanTwinB/status/1336890442768547845

McLaren Stanley
@StanTwinB citēja

2020-12-10 06:28:14 | atvērt tviterī | 7588 ☆, 2143 RT

Alright folks, gather round and let me tell you the story of (almost) the biggest engineering disaster I’ve ever had the misfortune of being involved in. It’s a tale of politics, architecture and the sunk cost fallacy [I’m drinking an Aberlour Cask Strength Single Malt Scotchh] https://twitter.com/StanTwinB/status/1336835936538087428

McLaren Stanley
@StanTwinB atbildēja @tapbot_paul

2020-12-10 02:51:39 | atvērt tviterī | 171 ☆, 3 RT

@tapbot_paul @lorenb @gsapienza I’m gonna have to get a glass of whiskey to answer this properly.

@aspruds PS Swift es vēl tikai apgūstu, bet PHP versijā šī ir slinkumoptimizācija. Produkcijā neko tādu neatļautos.

@aiidziis @jurgenzz Jau lasīju. Tas bija ļoti sen. Teju viss no tur minētā vairs nav attiecināms uz mūsdienām. Ja neskaita Swift veiktspēju.

@laacz Bet ja nu Swift lēnā vieta ir Int tipa konstruktors?

@laacz Offtopic: drīkstēja vienu un to pašu skaitli izmantot vairākas reizes?

@andyqp Nebija liegts.

@aspruds Tā arī ir. Šis ir 2s.

Šī versija, savukārt, ir 2s (noapaļojot uz leju). Kas ir tikai par trešdaļu lēnāk, nekā PHP versija.

@laacz @aspruds Var arī pamēģināt .forEach aizstāt ar for .. in varbūt kādas milisekundes var nogriezt.

@laacz Un, ja foreach uztaisa iekš PHP, nav vēl ātrāk?

Līdzīgi uzlabojumi PHP dod 0.4s, kas ir 5x ātrāk, nekā jaunā Swift versija.

@ugisu https://twitter.com/laacz/status/1337477599438778370

Kaspars Foigts
@laacz atbildēja @

2020-12-11 21:21:23 | atvērt tviterī | 0 ☆, 0 RT

Līdzīgi uzlabojumi PHP dod 0.4s, kas ir 5x ātrāk, nekā jaunā Swift versija.

@ugisu PHP foreach versija ir 0.15s.

Šī PHP versija ir 0.15s. Teju 10x ātrāk.

@aiidziis @aspruds 1.85s

Šī Swift veraija ir 1.9s. Kas ir vairāk nekā 10x lēnāk par PHP versiju.

@laacz Kura PHP versija?

@streelnieks 8.0

@laacz Ja par pašu algoritmu, nevis par performances salīdzināšanu, tad es nelaistu *) otro un trešo ciklu, ja pirmais skaitlis lielāks par 2020 *) trešo ciklu, ja pirmo divu summa jau lielāka par 2020 :)

@Kolliss Es arī.

@Kolliss PS Šis nav algoritma optimizācijas uzdevums.

@streelnieks 7.4 rezultāti ir identiski.

@laacz Vari lūdzu kaut kur ievietot to Swift projektu? Paskatīšos kāpēc tik lēns.

@janiskirsteins Tas nav projekts. Viens pats fails. Kompilēts ar `swiftc 02.swift`. Palaists ar `./02`. Ar nosacījumiem, ka algoritmu NEVAR mainīt, uzlabotais kods (tikai ~10x lēnāks par PHP) te: https://gist.github.com/laacz/e8096d890b9107a76a9e1ab88083ad51

@laacz Paldies, bet ļoti nepieciešami arī tie ievaddati.

@laacz Vēl 2 domas: 1) Vai vari tikt vaļā no ! pie saskaitīšanas? Varbūt tur ir Optional, kas tiek unwrappoti? 2) Kas notiek, ja kodu palaid 20x un izvelc vidējo laiku? Varbūt Swift JVM paiet laiks, kamēr "uzsilst"?

@janiskirsteins Es pieņemu, ka tiekot vaļā no optionals unwrapošanas, būtu vēl ātruma ieguvums.

@aspruds 1) Unwrapošana ārpus cikla ieguvums nedod. Tas bija sagaidāms, jo implicit unwrapošana reāli neko papildus nedara. Tik dabon tavu parakstu par runtime erroriem. 2) 20x mediāna neatšķiras no pirmā.

@janiskirsteins https://laacz.lv/tmp/01.txt PS Optionals unwrapping ārpus cikla veiktspējas ieguvumus nedeva nekādus, kas arī loģiski, jo implicit unwrapping principā ir atļauja mest runtime error.

@laacz Kuru php versiju testē?

@jancha Sāku ar 8.0, tad pamēģināju 7.4 un izmaiņu nekādu. Taimingi identiski.

@jancha Ja gribi vainot JIT, tad tas nostrādā uz CPU intensīviem tāskiem. Šis tāds nav.

@laacz Referencei uztaisi ieksh c ;)

@jancha Nevēlos. Es savus C/C++ laikus ar lielu prieku esmu atstājis ciešā pagātnē :)

@jancha BTW, ir aizdomas, ka C versija nebūs mega ātrāka par PHP, jo PHP lieliski interpretējas pa taisno uz C.

@laacz @ugisu PHP joprojām rulz.

@skeptiks @ugisu Strīdīgi. PHP galvenais pluss ir deploymenta tehnoloģija. Uzmet failu uz servera un voila. Nevienam citam tā nav, ja neskaita js/jhtml :D

@laacz @ugisu Nu, nekautrējies php rulz.

@skeptiks @ugisu Jā, tā ir vide, kurā es esmu džigits. Bet tā nav vide, ar kuru es lepojos.

@skeptiks @laacz Man Jums lūgums šādā saistībā. Vēlos array matrix pārkārtot citā, diagonālā secībā iekš JS. Sākotnēji array ir: [1, 2, 3, 4, 5, 6, 7, 8, 9], ko vēlos pārvērst par: [1, 3, 6, 2, 5, 8, 4, 7, 9] man nav svarīga sortēšana augoši, bet sākotnējā array secības pārkārtošana diagonāli.

@laacz @ugisu Štrunts par lepošanos. Tā ir vide, kas tevi nepiečakarēs.

@ugisu @skeptiks Šo sauc par matricu transponēšanu. Pirmais rezultāts google uz "array transpose javascript" atbilst :)

@skeptiks @ugisu LOL. Pasaki to 8.0 :)

@ugisu @skeptiks Paga. Es īsti neredzu sakarību starp pirmo, otro un diagonāli.

@laacz Atradu 2 lietas 1) Pirmais `try` ir jāforše (`try!`), jo errori netiek handloti. Ar Xcode nemaz nevar nokomilēt. 2) Noklusējumā Swift komilē neoptimizētu debug kodu. Lai panāktu optimālu komiplēšanas laiku. `swiftc *.swift -O` ieslēdzu optimizāciju un jau ms mērāms rezultāts.

@janiskirsteins OK. Tagad skats ir PAVISAM savādāks. 0.01s pret 0.18s no PHP puses.

Ha! Swift uzvarēja. ./swiftc 02.swift -O (bez debuginfo, ar optimizācijām). Un. 0.01s Swift, kamēr PHP labākā versija patlaban ir 0.15s. 15x lēnāk nekā Swift.

@laacz To visu noteikti var izdarīt ātrāk iekš PDF.

@laacz

@jancha Iedod kodu. Palaidīšu uz sava benchmarkam.

@laacz http://www.ambienttech.lv/a.c

@jancha Negribu būt slikto ziņu nesējs, bet `02` ir swiftc kompilēts un `a.out`, obv, cc. Atbilst 20 reizes palaistam vidējam...

@laacz Tev gcc ari ir? Un palaid kadas 100reizes. Un php kodu referencei ari.

@jancha Ar gcc kompilēts tas pats. No 100 laidieniem vidējais: swiftc 0.01s cc 0.02s gcc 0.02s php8.0 0.15s php7.4 0.16s

@laacz Nu tatad c vs php performance day vs night. Par swiftc, interesanti, kapec atraks. Principa lēnākā vieta varētu būt drukas komanda.

@laacz Cik ir izmers kompiletam swiftc vs gcc?

@jancha Pieļauju, ka mega optimizācijas, pateicoties lietām, kuras viņi var izķert kompilācijas fāzē. gcc ar -Ofast arī ir 0.01s.

@jancha Baigi incanti. Lai arī binary izmērs ir identisks, -Ofast rezultāts izpildās būtiski ātrāk...

@laacz Interesanti, ka man a.out izmers uz linux kastes ir 8kb

@jancha Darwin Kernel Version 20.1.0: Sat Oct 31 00:07:11 PDT 2020; root:xnu-7195.50.7~2/RELEASE_X86_64 x86_64