Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > pl.comp.programming > #31990 > unrolled thread
| Started by | Maciej Sobczak <see.my.homepage@gmail.com> |
|---|---|
| First post | 2018-11-16 00:27 -0800 |
| Last post | 2018-11-29 00:08 -0800 |
| Articles | 20 on this page of 91 — 10 participants |
Back to article view | Back to pl.comp.programming
Niezmienniki pętli Maciej Sobczak <see.my.homepage@gmail.com> - 2018-11-16 00:27 -0800
Re: Niezmienniki pętli queequeg@trust.no1 (Queequeg) - 2018-11-16 15:22 +0000
Re: Niezmienniki pętli AK <nobody@nowhere.net> - 2018-11-16 17:18 +0100
Re: Niezmienniki pętli szykcech@gmail.com - 2018-11-16 07:48 -0800
Re: Niezmienniki pętli szykcech@gmail.com - 2018-11-16 07:50 -0800
Re: Niezmienniki pętli queequeg@trust.no1 (Queequeg) - 2018-11-16 19:14 +0000
Re: Niezmienniki pętli szykcech@gmail.com - 2018-11-16 11:40 -0800
Re: Niezmienniki pętli queequeg@trust.no1 (Queequeg) - 2018-11-16 20:05 +0000
Re: Niezmienniki pętli szykcech@gmail.com - 2018-11-17 07:59 -0800
Re: Niezmienniki pętli queequeg@trust.no1 (Queequeg) - 2018-11-18 00:02 +0000
Re: Niezmienniki pętli Maciej Sobczak <see.my.homepage@gmail.com> - 2018-11-16 14:51 -0800
Re: Niezmienniki pętli queequeg@trust.no1 (Queequeg) - 2018-11-19 09:37 +0000
Re: Niezmienniki pętli fir <profesor.fir@gmail.com> - 2018-11-18 01:10 -0800
Re: Niezmienniki pętli fir <profesor.fir@gmail.com> - 2018-11-18 01:28 -0800
Re: Niezmienniki pętli godek.maciek@gmail.com - 2018-11-16 11:51 -0800
Re: Niezmienniki pętli Maciej Sobczak <see.my.homepage@gmail.com> - 2018-11-16 14:55 -0800
Re: Niezmienniki pętli Sebastian Biały <heby@poczta.onet.pl> - 2018-11-17 14:58 +0100
Re: Niezmienniki pętli Maciej Sobczak <see.my.homepage@gmail.com> - 2018-11-17 15:10 -0800
Re: Niezmienniki pętli AK <nobody@nowhere.net> - 2018-11-18 09:58 +0100
Re: Niezmienniki pętli Sebastian Biały <heby@poczta.onet.pl> - 2018-11-18 17:35 +0100
Re: Niezmienniki pętli Maciej Sobczak <see.my.homepage@gmail.com> - 2018-11-18 23:14 -0800
Re: Niezmienniki pętli Roman Tyczka <noemail@because.no> - 2018-11-19 09:22 +0100
Re: Niezmienniki pętli godek.maciek@gmail.com - 2018-11-19 08:15 -0800
Re: Niezmienniki pętli godek.maciek@gmail.com - 2018-11-19 10:45 -0800
Re: Niezmienniki pętli Sebastian Biały <heby@poczta.onet.pl> - 2018-11-22 18:50 +0100
Re: Niezmienniki pętli godek.maciek@gmail.com - 2018-11-19 10:49 -0800
Re: Niezmienniki pętli szykcech@gmail.com - 2018-11-19 12:18 -0800
Re: Niezmienniki pętli queequeg@trust.no1 (Queequeg) - 2018-11-19 20:44 +0000
Re: Niezmienniki pętli fir <profesor.fir@gmail.com> - 2018-11-19 13:10 -0800
Re: Niezmienniki pętli fir <profesor.fir@gmail.com> - 2018-11-19 13:16 -0800
Re: Niezmienniki pętli queequeg@trust.no1 (Queequeg) - 2018-11-20 09:43 +0000
Re: Niezmienniki pętli fir <profesor.fir@gmail.com> - 2018-11-20 01:58 -0800
Re: Niezmienniki pętli godek.maciek@gmail.com - 2018-11-20 14:27 -0800
Re: Niezmienniki pętli queequeg@trust.no1 (Queequeg) - 2018-11-21 10:12 +0000
Re: Niezmienniki pętli godek.maciek@gmail.com - 2018-11-21 11:35 -0800
Re: Niezmienniki pętli queequeg@trust.no1 (Queequeg) - 2018-11-21 21:10 +0000
Re: Niezmienniki pętli fir <profesor.fir@gmail.com> - 2018-11-21 02:36 -0800
Re: Niezmienniki pętli godek.maciek@gmail.com - 2018-11-19 14:12 -0800
Re: Niezmienniki pętli AK <nobody@nowhere.net> - 2018-11-20 00:20 +0100
Re: Niezmienniki pętli queequeg@trust.no1 (Queequeg) - 2018-11-20 09:35 +0000
Re: Niezmienniki pętli AK <nobody@nowhere.net> - 2018-11-20 12:00 +0100
Re: Niezmienniki pętli szykcech@gmail.com - 2018-11-19 20:37 -0800
Re: Niezmienniki pętli godek.maciek@gmail.com - 2018-11-20 13:46 -0800
Re: Niezmienniki pętli fir <profesor.fir@gmail.com> - 2018-11-20 01:46 -0800
Re: Niezmienniki pętli fir <profesor.fir@gmail.com> - 2018-11-20 12:52 -0800
Re: Niezmienniki pętli fir <profesor.fir@gmail.com> - 2018-11-20 13:16 -0800
Re: Niezmienniki pętli Maciej Sobczak <see.my.homepage@gmail.com> - 2018-11-20 06:07 -0800
Re: Niezmienniki pętli AK <nobody@nowhere.net> - 2018-11-20 17:54 +0100
Re: Niezmienniki pętli Maciej Sobczak <see.my.homepage@gmail.com> - 2018-11-20 23:16 -0800
Re: Niezmienniki pętli AK <nobody@nowhere.net> - 2018-11-21 15:54 +0100
Re: Niezmienniki pętli AK <nobody@nowhere.net> - 2018-11-21 16:07 +0100
Re: Niezmienniki pętli Maciej Sobczak <see.my.homepage@gmail.com> - 2018-11-21 13:48 -0800
Re: Niezmienniki pętli AK <nobody@nowhere.net> - 2018-11-22 16:08 +0100
Re: Niezmienniki pętli AK <nobody@nowhere.net> - 2018-11-20 00:00 +0100
Re: Niezmienniki pętli Wojciech Muła <wojtek.mula@gmail.com> - 2018-11-22 13:53 -0800
Re: Niezmienniki pętli AK <nobody@nowhere.net> - 2018-11-22 23:25 +0100
Re: Niezmienniki pętli AK <nobody@nowhere.net> - 2018-11-23 00:41 +0100
Re: Niezmienniki pętli AK <nobody@nowhere.net> - 2018-11-23 00:43 +0100
Re: Niezmienniki pętli szykcech@gmail.com - 2018-11-22 22:33 -0800
Re: Niezmienniki pętli AK <nobody@nowhere.net> - 2018-11-23 10:34 +0100
Re: Niezmienniki pętli Maciej Sobczak <see.my.homepage@gmail.com> - 2018-11-23 05:46 -0800
Re: Niezmienniki pętli AK <nobody@nowhere.net> - 2018-11-23 15:39 +0100
Re: Niezmienniki pętli AK <nobody@nowhere.net> - 2018-11-23 15:42 +0100
Re: Niezmienniki pętli AK <nobody@nowhere.net> - 2018-11-23 15:47 +0100
Re: Niezmienniki pętli Wojciech Muła <wojtek.mula@gmail.com> - 2018-11-23 10:54 -0800
Re: Niezmienniki pętli Borneq <borneq@antyspam.hidden.pl> - 2018-12-01 15:15 +0100
Re: Niezmienniki pętli Wojciech Muła <wojtek.mula@gmail.com> - 2018-12-01 11:50 -0800
Re: Niezmienniki pętli Borneq <borneq@antyspam.hidden.pl> - 2018-12-02 13:52 +0100
Re: Niezmienniki pętli Maciej Sobczak <see.my.homepage@gmail.com> - 2018-11-24 12:20 -0800
Re: Niezmienniki pętli AK <nobody@nowhere.net> - 2018-11-23 15:53 +0100
Re: Niezmienniki pętli Maciej Sobczak <see.my.homepage@gmail.com> - 2018-11-24 12:05 -0800
Re: Niezmienniki pętli Wojciech Muła <wojtek.mula@gmail.com> - 2018-11-26 02:01 -0800
Re: Niezmienniki pętli szykcech@gmail.com - 2018-11-23 08:42 -0800
Re: Niezmienniki pętli AK <nobody@nowhere.net> - 2018-11-23 19:42 +0100
Re: Niezmienniki pętli AK <nobody@nowhere.net> - 2018-11-23 19:43 +0100
Re: Niezmienniki pętli Wojciech Muła <wojtek.mula@gmail.com> - 2018-11-22 23:00 -0800
Re: Niezmienniki pętli AK <nobody@nowhere.net> - 2018-11-23 10:38 +0100
Re: Niezmienniki pętli Wojciech Muła <wojtek.mula@gmail.com> - 2018-11-23 04:08 -0800
Re: Niezmienniki pętli Wojciech Muła <wojtek.mula@gmail.com> - 2018-11-23 04:10 -0800
Re: Niezmienniki pętli AK <nobody@nowhere.net> - 2018-11-23 15:33 +0100
Re: Niezmienniki pętli Maciej Sobczak <see.my.homepage@gmail.com> - 2018-11-20 05:38 -0800
Re: Niezmienniki pętli godek.maciek@gmail.com - 2018-11-21 11:32 -0800
Re: Niezmienniki pętli Maciej Sobczak <see.my.homepage@gmail.com> - 2018-11-21 13:28 -0800
Re: Niezmienniki pętli godek.maciek@gmail.com - 2018-11-21 14:04 -0800
Re: Niezmienniki pętli Maciej Sobczak <see.my.homepage@gmail.com> - 2018-11-22 02:31 -0800
Re: Niezmienniki pętli fir <profesor.fir@gmail.com> - 2018-11-22 06:22 -0800
Re: Niezmienniki pętli Sebastian Biały <heby@poczta.onet.pl> - 2018-11-22 18:53 +0100
Re: Niezmienniki pętli queequeg@trust.no1 (Queequeg) - 2018-11-19 09:45 +0000
Re: Niezmienniki pętli Maciej Sobczak <see.my.homepage@gmail.com> - 2018-11-20 05:29 -0800
Re: Niezmienniki pętli queequeg@trust.no1 (Queequeg) - 2018-11-20 22:26 +0000
Re: Niezmienniki pętli Maciej Sobczak <see.my.homepage@gmail.com> - 2018-11-29 00:08 -0800
Page 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
| From | AK <nobody@nowhere.net> |
|---|---|
| Date | 2018-11-20 12:00 +0100 |
| Message-ID | <pt0pgg$1t8v$1@gioia.aioe.org> |
| In reply to | #32032 |
On 2018-11-20 10:35, Queequeg wrote: > Jeśli pracę z jednymi językami lubi bardziej niż z innymi, to jest to > poparte czymś więcej niż "nie chciało mi się tego uczyć, to sobie to > znienawidzę i uznam, że nie jest potrzebne". O własnie! Dokładnie tak. AK
[toc] | [prev] | [next] | [standalone]
| From | szykcech@gmail.com |
|---|---|
| Date | 2018-11-19 20:37 -0800 |
| Message-ID | <23bc3612-233a-4e1d-9e4a-138ff25c0286@googlegroups.com> |
| In reply to | #32028 |
> > A to co nie produkcyjne może być w Bash lub Pythonie. > > A dlaczego nie w C++? Żeby było szybciej?!? > > A jak chcemy zrobić bazkę to dodatkowo Sql. > > A dlaczego nie C++? Bo taki mamy standard dla relacyjnych baz danych?!? > I czy oprócz C++, basha, pythona, htmla, javascriptu i sql znasz > jeszcze jakieś języki? Asembler, Php, RegExp - to chyba już wszystko. Trochę liznąłem Java, ale to czysty koszmar... > > Po drugie, primo: > > 2. W języku programowania jest najważniejsze by był kompilowany do kodu maszynowego (niżej nie zejdziemy - chyba że jeżyki opisu sprzętu Vhdl/Verilog są nam niestraszne). > > Dlaczego to jest najważniejsze? Żeby program działał bez sztucznych narzutów (typu maszyny wirtualne i interpretery). > > Lepiej już zaprojektować jakiś program (poćwiczyć projektowanie) z jakimiś ciekawymi algorytmami (poćwiczyć projektowanie algorytmów i ew. złożoność obliczeniową), a potem zastanowić się co w naszym dotychczasowym stylu kodowania było nie tak i to zakodować to wg najnowszych pomysłów i spostrzeżeń (poćwiczyć kodowanie). > > No, jak się uczy podstaw, to warto ćwiczyć podstawy. To nie tylko podstawy, to również szlifowanie i rozwój z każdym nowym projektem. > > To jest racjonalne a nie strata czasu na kolejny (zbędny) język programowania. > > Skąd wiesz, że to "kolejny (zbędny) język programowania"? > Na jakiej podstawie formułujesz taki sąd? Jw. > C++ to najgorszy język, z jakim miałem styczność. > Już dawno oddałem go na złom. Najwyraźniej jesteś oportunistą! Widziałeś tą listę: http://www.lextrait.com/Vincent/implementations.html ?!? Na pierwszym miejscu C++ i na drugim Java - reszta języków na marginesie... > C++ sprawia, że pierdołowate programiki, które w innych > językach zajęłyby kilka linijek, urastają do rangi > wielkiego osiągnięcia. Ta... Bo co?!? Bo ktoś Ci zabronił używania Qt?!? A może się nie chciało?!? > Trzymam kciuki. > Jak będziecie używać mojej funkcji memmove, to może nawet zadziała > o ćwierć promila szybciej na niektórych procesorach. Arm?!? Raspbian z tego co wiem ma własne optymalizowane funkcje memcpy() przez co debuger przy uruchamianiu zgłasza błąd "illegal instruction" (jednak breakpoint-y działają), natomiast z tego samego powodu Valgrind nie działa wcale... Jednak jeszcze nie podjęto decyzji o bazie sprzętowej (może będzie to Arm a może Amd64).
[toc] | [prev] | [next] | [standalone]
| From | godek.maciek@gmail.com |
|---|---|
| Date | 2018-11-20 13:46 -0800 |
| Message-ID | <8ee92551-175a-4b8b-9fe5-a75ffac2753e@googlegroups.com> |
| In reply to | #32031 |
W dniu wtorek, 20 listopada 2018 05:37:31 UTC+1 użytkownik szyk...@gmail.com napisał: > > > A to co nie produkcyjne może być w Bash lub Pythonie. > > > > A dlaczego nie w C++? > > Żeby było szybciej?!? A dlaczego w C++ jest wolniej? > > > A jak chcemy zrobić bazkę to dodatkowo Sql. > > > > A dlaczego nie C++? > > Bo taki mamy standard dla relacyjnych baz danych?!? Czyli C++ nie jest "zupełnie wystarczający do wszystkiego"? Nota bene, Rich Hickey zwrócił kiedyś uwagę, że problemem SQLa jest to, że jego twórcy nie pomyśleli o interfejsie dla maszyn. Interfejs dla człowieka łatwo jest dorobić do interfejsu dla maszyny, ale dorobienie interfejsu dla maszyny do interfejsu dla człowieka zawsze powoduje bezsensowne problemy (tak jak SQL injection) > > I czy oprócz C++, basha, pythona, htmla, javascriptu i sql znasz > > jeszcze jakieś języki? > > Asembler, Php, RegExp - to chyba już wszystko. Trochę liznąłem Java, ale to czysty koszmar... To niewiele. PHP, Python i JavaScript to właściwie "różne skórki" na ten sam język. Z języków, które faktycznie mogą dać nowe perspektywy na programowanie, jest Smalltalk (Pharo albo Squeak), Lisp, Prolog, Erlang i Haskell. (no i oczywiście angielski) > > > Po drugie, primo: > > > 2. W języku programowania jest najważniejsze by był kompilowany do kodu maszynowego (niżej nie zejdziemy - chyba że jeżyki opisu sprzętu Vhdl/Verilog są nam niestraszne). > > > > Dlaczego to jest najważniejsze? > > Żeby program działał bez sztucznych narzutów (typu maszyny wirtualne i interpretery). Ale dlaczego to jest najważniejsze? > > > Lepiej już zaprojektować jakiś program (poćwiczyć projektowanie) z jakimiś ciekawymi algorytmami (poćwiczyć projektowanie algorytmów i ew. złożoność obliczeniową), a potem zastanowić się co w naszym dotychczasowym stylu kodowania było nie tak i to zakodować to wg najnowszych pomysłów i spostrzeżeń (poćwiczyć kodowanie). > > > > No, jak się uczy podstaw, to warto ćwiczyć podstawy. > > To nie tylko podstawy, to również szlifowanie i rozwój z każdym nowym projektem. > > > > To jest racjonalne a nie strata czasu na kolejny (zbędny) język programowania. > > > > Skąd wiesz, że to "kolejny (zbędny) język programowania"? > > Na jakiej podstawie formułujesz taki sąd? > > Jw. Tzn. co "jw."? > > C++ to najgorszy język, z jakim miałem styczność. > > Już dawno oddałem go na złom. > > Najwyraźniej jesteś oportunistą! Widziałeś tą listę: > http://www.lextrait.com/Vincent/implementations.html > ?!? > Na pierwszym miejscu C++ i na drugim Java - reszta języków na marginesie... To bez znaczenia. C był "pionierskim językiem" projektu UNIX, i stąd się wzięła jego popularność. Poza tym ani C, ani C++ nie wprowadziły niczego rewolucyjnego. Większość rzeczy związanych z GUI (edytory tekstu, programy graficzne itd.) powstały wokół Smalltalka. Zaawansowane projekty matematyczne (np. całkowanie symboliczne) powstały wokół Lispa. "Property-based testing" powstał w Haskellu. To nie jest przypadek. Jakkolwiek znoszę język C, muszę stwierdzić, że projekty C i C++ ciągną się w ogonie rewolucji, a nie na jej czele. To języki, w których można robić rzeczy znane, ale do nieznanych nie nadają się zupełnie. Przykładowo, firma Rigetti stosuje Common Lisp do programowania komputerów kwantowych, a Christian Schafmeister stworzył implementację Common Lispa opartą na LLVM żeby ułatwić sobie prace w biologii molekularnej. > > C++ sprawia, że pierdołowate programiki, które w innych > > językach zajęłyby kilka linijek, urastają do rangi > > wielkiego osiągnięcia. > > Ta... Bo co?!? Bo ktoś Ci zabronił używania Qt?!? A może się nie chciało?!? Rozumiem, że masz bibliotekę, którą lubisz. W porządku, nie ma nic złego w lubieniu biblioteki. Zabawne jest jednak to, że zarzucasz mi lenistwo (a może ignorancję) pomimo że ja znam narzędzia, o których Ty piszesz, ale Ty najwidoczniej nie znasz tych, o których ja piszę.
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2018-11-20 01:46 -0800 |
| Message-ID | <43bede32-9f44-4926-9758-ac9080ca247a@googlegroups.com> |
| In reply to | #32028 |
W dniu poniedziałek, 19 listopada 2018 23:12:21 UTC+1 użytkownik godek....@gmail.com napisał: > Jak będziecie używać mojej funkcji memmove, to może nawet zadziała > o ćwierć promila szybciej na niektórych procesorach. takie teksty nie brzmia za madrze (pominawszy fakt ze tego typu spory/dyskusje (tego okreslonego typu) wogole nie sa za madre) (z trzeciej stony wlaczanie sie w takie logiczne podejscie (typu wypowiadanie zdan i rozrtrzasanie co jest rpawda a co nie) jest ok) ile to jest cwierc promila? 0.025 %, cos tu nie gra, wygladami na to ze ktos kto to pisze ma bardzo osobliwe podejscie do optymalizacji i robil to albo jakos dziwnie albo zupelnie zle albo wogole ja optymalizowalem relatywnie sporo i 1) takie wartosci jak 0.025% nie wchodza tam wogole w gre bo te czasy wogole nie sa tak stabilne by moc to zauwazyc i zmierzyc (aq czas czystego memcopy to juz wogole gdy ja to mierzylem niezle oscylowal) 2) samego memcopy raczej sie nie optymalizuje bo przestrzen by tu poprawic jest mala ale juz cale okolice bliskie memcopy - jak najbardziej 3) czynniki jakimi mozesz przyoptymalizowac juz calkiem dobrze ale zwyczajnie napisany kod w c czy tam c++ moga byc naprawde spore, i wtedy nie wyrazasz tez tego raczej w procentach tylko w 'x' ile razy, to ilemozesz osiagnac zalezy od natury zagadnienia i od tego jak wstepnie przyoptymalizowany byl kod oraz od tego jak bardzo daleko chesz isc w ta optymalizacje ale moje przykladowe casy jakie ja znam 1) kiepsko napisany kod 60 ms na ramke 2) pobawianie sie z flagami kompilacji (ale takie ktore polega na tym ze po roznych zmianach patrzysz na wplyw a nie tylko na pale wlaczysz kilka) oraz wogole wyodrebnienie petli i przepisanie jaj tak by bylo jasne co tam sie dzieje (jelsi ktos napisal bez wiekszej uwagi) 30 ms na ramke (dla mnie to pow punkt startoway bo jzu na starcie zwracam na to uwage) 3) poprzepisywanie, porozwijanie wyrazen, zredukowanie dzielen, poprzepisywanie na inline (choc to malo pomaga raczej chodzi o to by miec wglad co tam sie dzieje), ogolne poupraszczanie tak ze kod bardziej jest przyjazny podejsciu optymalizacyjnemu - 16 ms 4) tabelaryzowanie kawalkow kodu, porozbijanie kodu na specjalne casy pod wzgledem optymalizacji, dorobienie skomplikowanych algorytmow 'odrzucania roboty', zagladanie do generowanego asma, ew wwalenie paru intrinsincow sse... przerobienie niektorych czesci na kod ktory dzial w sposob lekko przyblizony (zlinearyzowany) (strata jakosc wzgl szybkosci) - 1.6- 1.2 ms 5) zejscie na poziom asma i robienie jakiegos hardkoru w mikrokodzie razem ew jeszcze z dorobieniem jeszcze wiekszych rewolucji w algorytmach odrzucania - prawdopodobnie jeszcze mozna przyspieszyc 2 razy (i zejsc ponizej milisekundy ale to juz hardkor i tego nie robie za duzo roboty i nei znam az takl asma slowem jak ktos mowi ze optymalizacja to walka o promile to raczej nie wie co mowi, wg mopich doswiadczen optymalizacja to raczej 'srednio' czynnik 10x 15x jeslis ie nawet zaczyna z calkiem poprawnego kodu w c nie widze przypadku w ktorych mowienie o promilach mialoby sens - bo to chyab musialobybyc w wypadku potwznie przyoptymalizowanego kodu a taki kod ma juz wtedy procentowo spoore fluktuacje wiec gadanie o promilach nie ma sensu
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2018-11-20 12:52 -0800 |
| Message-ID | <cc376925-76cd-40ae-a5e6-3bd32d933671@googlegroups.com> |
| In reply to | #32034 |
W dniu wtorek, 20 listopada 2018 10:46:04 UTC+1 użytkownik fir napisał:
> W dniu poniedziałek, 19 listopada 2018 23:12:21 UTC+1 użytkownik godek....@gmail.com napisał:
> > Jak będziecie używać mojej funkcji memmove, to może nawet zadziała
> > o ćwierć promila szybciej na niektórych procesorach.
>
> takie teksty nie brzmia za madrze (pominawszy fakt ze tego typu spory/dyskusje (tego okreslonego typu) wogole nie sa za madre) (z trzeciej stony wlaczanie sie w takie logiczne podejscie
> (typu wypowiadanie zdan i rozrtrzasanie co jest rpawda a co nie) jest ok)
>
> ile to jest cwierc promila? 0.025 %,
> cos tu nie gra, wygladami na to ze
> ktos kto to pisze ma bardzo osobliwe podejscie do optymalizacji i robil to albo jakos dziwnie albo zupelnie zle
> albo wogole
>
> ja optymalizowalem relatywnie sporo i
>
> 1)
> takie wartosci jak 0.025% nie wchodza
> tam wogole w gre bo te czasy wogole nie sa tak stabilne by moc to zauwazyc i zmierzyc (aq czas czystego memcopy to juz wogole gdy ja to mierzylem niezle oscylowal)
> 2)
> samego memcopy raczej sie nie optymalizuje bo przestrzen by tu poprawic jest mala ale juz cale okolice bliskie
> memcopy - jak najbardziej
> 3) czynniki jakimi mozesz przyoptymalizowac juz calkiem dobrze ale zwyczajnie napisany kod w c czy tam c++ moga byc naprawde spore, i wtedy nie wyrazasz tez tego raczej w procentach tylko w 'x' ile razy, to ilemozesz osiagnac zalezy od natury zagadnienia i od tego jak wstepnie przyoptymalizowany byl kod oraz od tego jak bardzo daleko chesz isc w ta optymalizacje
>
> ale moje przykladowe casy jakie ja znam
>
> 1) kiepsko napisany kod 60 ms na ramke
> 2) pobawianie sie z flagami kompilacji
> (ale takie ktore polega na tym ze po roznych zmianach patrzysz na wplyw a nie tylko na pale wlaczysz kilka) oraz wogole
> wyodrebnienie petli i przepisanie jaj tak by bylo jasne co tam sie dzieje (jelsi ktos napisal bez wiekszej uwagi) 30 ms na ramke
>
> (dla mnie to pow punkt startoway bo jzu na starcie zwracam na to uwage)
>
> 3) poprzepisywanie, porozwijanie wyrazen, zredukowanie dzielen, poprzepisywanie na inline (choc to malo pomaga raczej chodzi o to by miec wglad co tam sie dzieje), ogolne poupraszczanie tak ze kod bardziej jest przyjazny podejsciu optymalizacyjnemu - 16 ms
>
> 4) tabelaryzowanie kawalkow kodu, porozbijanie kodu na specjalne casy pod wzgledem optymalizacji, dorobienie skomplikowanych algorytmow 'odrzucania roboty', zagladanie do generowanego asma, ew wwalenie paru intrinsincow sse... przerobienie niektorych czesci na kod ktory dzial w sposob lekko przyblizony (zlinearyzowany) (strata jakosc wzgl szybkosci) - 1.6- 1.2 ms
>
> 5) zejscie na poziom asma i robienie jakiegos hardkoru w mikrokodzie razem ew jeszcze z dorobieniem jeszcze wiekszych rewolucji w algorytmach odrzucania - prawdopodobnie jeszcze mozna przyspieszyc 2 razy (i zejsc ponizej milisekundy ale to juz hardkor i tego nie robie za duzo roboty i nei znam az takl asma
>
>
> slowem jak ktos mowi ze optymalizacja to walka o promile to raczej nie wie co mowi, wg mopich doswiadczen optymalizacja to raczej 'srednio' czynnik 10x 15x jeslis ie nawet zaczyna z calkiem poprawnego kodu w c
>
> nie widze przypadku w ktorych mowienie o promilach mialoby sens - bo to chyab musialobybyc w wypadku potwznie przyoptymalizowanego kodu a taki kod ma juz wtedy procentowo spoore fluktuacje wiec gadanie o promilach nie ma sensu
moze jeszcze 3 drobne uwagi co do tego powyzej:
1) calkiem mozliwe ze optymalizacje roznych programow sa zasadniczo rozne
i generuja rozne wnioski - i by moc duzo
o tym powiedziec tzrebby rozne przypadki optymalizowac (sam mam na mysli glownie optymalizacje grafiki perpixel (glownie 3d) na cpu) choc nie tylko costam jeszcze
czasem tez sie troche optymalizowalo ale slabiej pamietam
2) ten pierwszy krok ktory wymienilem jest troche nienormalny i nie dotyczy tak bardzo tego co ja pisze (bo dotyczy on glownie prostych bledow) ale podejrzewam moze dotyczyc kodow wielu ludzi bo wydaje mi sie ze wiele ludzi nie mierzy na bierzaco czasow wykonania - nie sa swiadomi zmian tych czasow, ich wartosci itd... mz to moze powodowac toz e kod ma pewne bledy - np jesli nei mierza czasow moga byc nieswiadomi jakie obciazenia pododuje systemowe api (ostatniuo pisalem swoj wlasny edytor tekstu w winapi i okazuje sie np ze rysowanie fontow winapowskin TextOutem czasem dziala szybko a czasem dziwnie wolno (np o ile pamietam rysowanie malych fontow po literce dzia dziwnie wolno itp)-- niesprawdzanie tego to nawet nie blad optymalizacji tylko raczej zwykly blad programu
[wogole z rysiowaniem tych fontow ogolnie mam pewien problem i nawet chetnie bym tu napisal na czym to polega, ale raczej nikt tu i tak nie znalby na to odpowiedzi
- w skrocie mowiac nie wiem jak zrobic to by moc swobodnie przeplatac rysowanie fontow z rysowaniem np spritow moimi procedurami per piksel ->
ogolnei by cos narysowac rysuje tow ramie po czym blituje do contekstu i dopiero wtedy mge na tym kontekscie narysiowac fonty TextOutem z gdi
gdybym chcial to przeplatac to by cos narysowac na tym wszystkim musialbym sciagnac to z kontekstu do ramu naryswoac do ramu i znowu blitnac - innymi slowy takie swobodne przeplatanie powoduje mase blitow i sciagniec wiec jest spieprzone
do tego nie pamietam czy przypadkiem tych textoutow nie moge wywoalywac tylko z handlera spod WM_PAINT (juz nie pamietam bo robilem to pol roku temu) a ja chcialbym to rysowanie miec zupelnie wolnym, przeplatac i wywolywac dowolnie z kodu ramki (idle loop)
naplsz("ala ma kota");
draw_line(10,10,300,400,0xffffff);
naplsz("zzzz");
draw_sprite(...)
a nie byc sztucznie ograniczanym, przez api (gdzie pisania napisow mozesz tylko zrobic po calej grafice jakby w odzielnej czasowo "warstiw" i nie mozesz tego uzywac normalnie - jak printfa) --- nie jestem pewien czy w wianpi sie da to zrobic (nie wiem bo nei czytalem o tym wszystkego co sie da wyszukac w necie
bo wtedy te problemy mnie zmeczyly a czcialem kodowac sam edytor
nie dotyczy to strikte optymalizacji tylko raczj poprawnego kodowania w realacji do wydajnosci ale jest mz ciekawym przykladem ]
przez toz e ludzi ne bierzaco nuie sprawdzaj tej wydajnosci moim zdaniem
kod mozne poprawic wydajnosciowo czesto nawet nie piszac optymalizacji, tylko raczej bedac swiadomym co jak wydajnie dziala i mierzac czasy
pozaym warto poswprawdzac te flagi optymalizacji, co smieszne okazuje sie ze
zmiana gcc z jednaj wersji na inna (przy tych samych opcjach) moze spowodowac to ze zmiania sie szybkosc wygenerowanego kodu (u mnie raz np kod zwolniel o jakies 10 czy 20% przy przejsciu kiedys z chyba gcc 4.9 na 5.2 czy cos takiego), przy bawieniu sie opcjami tez np warto zwracac pewnie uwage czy kompilator nie generuje jakichs niespodzianek bo kompilatory schodza na psy troche, wrzucaja jakis niepotrzbny syf
3) te techniki 'algorytmicznej ' optymalizacji (czyli a)odrzucanie/odfiltorowywanie roboty do wyonania
b) 'linearyzacja' / czyli cos w stylu liczeni stratenego na jakosci ale szybszego (jak np nie liczenie calych pierwiastkow a tylko przyblizonych, albo licznie ich tylko na rogach kafelkow a pozniej interpolowanie liniowe)
wymianione sa charakterystyczne dla kodwowania grafiki ale raczej dadza sie jakos uogolnic w pewnym sesnie na ogolene
metody algorycznej optymalizacji - i sam w to szedlem z ciekawosci ale moze to sie
przerodzic troche w robote rodem z jakiegos NASA czy cos (mowiac metaforycznie ) bo okazuje sie ze kod ktory w oryginale ma Xliniejek po dowaleniu tej algorytmiki ma 10 razy
tyle - jest doalebnie mniej nieczytelny i diablenie zamkniety na poprawki - ale dziala szybciej, po przepisywaniu na profesjonalnego asma pewnie jeszcze szybciej i jeszcze bardziej nieczytelny i jeszcze bardziej zamkniety na zmiany
dlatego by nie klepac po proznicy w usenecie (bo ludzi nei eznaja sie na optymalizacji ale klepia bzdury jak kompletne downy (np ze kompilator sam zoptymalizuje - kompilator nie zoptymalizuje to jest totalna bzdura bo kompilator tylko potrafi skompilowac co programista zapiesze by to optymalizowac tzreba to przepisywac) mozna powiedzic tye;
1) optymalizacja moze duzo dawac ale maszkilak jej poziomow i typow - wbrew pozorom mikrooptymalizacje na poziomie c sa mz jedna z najtanszych i najlepszych rzeczy jaka mozna robic... warto tez rozumiec api jakiegios ie uzywa i system
(nie jest to optymalizacja el chodzi o poprawne rozumienie kodu)... te optymalizacje algorytmiczne o ktorych tez downy z netu nawijaja tez mozna rozumeic dwojako, jako wybor algorytmu do zrobienie czegos (co zwykle raczej nie jest trudne i kazdy kumaty programista nie ma chyab z tym wiekszego problemu, bo czemu ma wybrac cos wolnego zamiast czegos normalnego) ale tez do pisanie tych algorytmow ktore rozbudowaywuja algorytm po to by dziala szybko np przez to odrzucani i linearyzowanie - ale to jest troche ryzykowan apsrawa bo z prostego kodu dostejesz dlgi i bardzo techniczny... schodzenie do poziomu recznego asma... jak ktos umie to cyba mozna ale to kolejna doza roboty
i poza wszystkim tzreba pamietac ze
by cos zoptymalizowac najpierw trzeba to napisac w zwyklej wersji a z tym jest duzo wiekszy problem... co z kolei jest pociecha dla tych ktorzy uzywaja wolnieszych jezykow - faktycznie to ze cos jest wolniejsze wcale tego nie dyskwalifikuje, bo chodzi o to byc cos
na poczatek wogole zrobic
by cos wogole zrobic z kolei trzeba miec odpowiednia pare by to moc zrobic i to jest jeszcze inny problem itd itd
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2018-11-20 13:16 -0800 |
| Message-ID | <e6e0ea2c-2088-4e27-ba7d-a8da7f5d2a29@googlegroups.com> |
| In reply to | #32041 |
W dniu wtorek, 20 listopada 2018 21:52:07 UTC+1 użytkownik fir napisał: > by cos wogole zrobic z kolei trzeba miec odpowiednia pare by to moc zrobic i to jest jeszcze inny problem itd itd dla mnie problemem ostatnich czasow jest wlasni ebardziej jakby psychologia -umiem kodowac rozne rzeczy (w granicach rozsadku bo niektore rzeczy umiem zakodowac np kompilator c, czy edytor tekstu ale niktorych nadal nie (bo albo sie natkne na zomecznie (prosta robota ale jest jej za duzo) albo na jakas "sciane" (yeoretcznie jest to malo kodu al enie moge tego jakos ogarnac by zazarlo) - i moja glowan bolaczka w tym temacie bylo by jak wymyslic by wogole zmusic siebie do kodowania... im bardziej je umiem tym mniej mi sie chce je robic (byc moze dlatego ze im bardziej zaawansowane kodowani tym bardziej pierze mozg lub przynajmniej meczy) choc sa pocieszajace elementu ostatnio wlasnie pouczylem sie ze 3 wieczory pehapa i wydawalo mi sie to proste jak jezyk dla dzieci (mw dlapieciolatkow), co jest optymistyczne - ale i tak mi sie po tych 3 wieczorach tymczasowo znudzilo jak sie zmusic do porzadnego kodowani to juz wogle nie wiem (na szczesci eniby jak sie w sobie zbiore to wykrzesam z siebie zapal i costam da sie przykodowac np ostatnio ten edytor przykodowalem w jakies 10 dni (niedokonczony ale da sie pisac a byl pisany z reki wszytko trzebylo obkodowac nawel lamanie lini tekstu sklejania ich itd) ale ogolneie to walsnie ta walka z ta psychologia (zmusisc sie do kodowania) to najwiekszy chyab problem, innym problemem sa te wspomnaiane 'sciany' koncepcyjne
[toc] | [prev] | [next] | [standalone]
| From | Maciej Sobczak <see.my.homepage@gmail.com> |
|---|---|
| Date | 2018-11-20 06:07 -0800 |
| Message-ID | <0dbe70a9-be2b-4220-a8e0-69d47d43ae7b@googlegroups.com> |
| In reply to | #32028 |
> C++ sprawia, że pierdołowate programiki, które w innych > językach zajęłyby kilka linijek, urastają do rangi > wielkiego osiągnięcia. A co z niepierdołowatymi programami? Bo dane zebrane przy pisaniu pierdołowatych programików nie muszą być reprezentatywne w szerszym kontekście. Natomiast lista, która tu już została pokazana (http://www.lextrait.com/Vincent/implementations.html) pokazuje, że kilka niebanalnych projektów w C++ powstało, a w zarządzaniu ryzykiem takie przykłady mają znaczenie. > Programując, staram się minimalizować dystans pomiędzy moimi > myślami a programami. Język programowania jest dla mnie > precyzyjną formą wyrazu myśli. To jest bardzo ciekawe stwierdzenie. Bo jeśli dystans między Twoimi myślami a programami będzie bardzo mały, to może się wtedy okazać, że dystans między tymi programami a tym co faktycznie robi procesor będzie wtedy tak duży, że nie uda się wykazać, że CPU robi to, co chciałeś. Są co najmniej trzy punkty: 1. Twoje myśli. 2. Program (albo jakiś inny inżynierski artefakt). 3. To, co robi komputer. Punkty 1. i 3. mają stałe położenie. Przesuwając 2. zmieniasz jeden dystans *kosztem* drugiego. To nie jest teoria - właśnie dlatego im bardziej "wysokopoziomowy" jest język (mała odległość między Twoimi myślami a programem), tym mniejsza szansa, że ktoś w nim zrobi jakikolwiek system, który *musi* być poprawny. Dlatego paradoksem naszej branży jest to, że najwięcej systemów krytycznych pisze się w... C. Ciekawostka: dystanse między tymi punktami powyżej można zmniejszyć wstawiając więcej punktów. Tylko 1. i 3. nie da się ruszyć. -- Maciej Sobczak * http://www.inspirel.com
[toc] | [prev] | [next] | [standalone]
| From | AK <nobody@nowhere.net> |
|---|---|
| Date | 2018-11-20 17:54 +0100 |
| Message-ID | <pt1e79$1alf$1@gioia.aioe.org> |
| In reply to | #32039 |
On 2018-11-20 15:07, Maciej Sobczak wrote: > Dlatego paradoksem naszej branży jest to, że najwięcej systemów > krytycznych pisze się w... C. Tak. To jest paradoks. Dodam tylko, że jeszcze wiekszym paradoksem jest to, iż nie wynika to _w najmniejszym stopniu_ z jakosci jezyka C jako języka programowania. Wprost przeciwnie. Wynika to wlasnie z jego prymitywizmu (zarowno jezyka, jak i jego biblioteki podstawowej/standardowej). Ten prymitywizm przeklada sie na bardzo duze ulatwienia w stworzeniu kompilatora, ktory "pojdzie" bez problemu rowniez na prymitywnym sprzecie (embedded itp). PS: Podobnie drzewiej bylo z Fortranem (4,77) AK
[toc] | [prev] | [next] | [standalone]
| From | Maciej Sobczak <see.my.homepage@gmail.com> |
|---|---|
| Date | 2018-11-20 23:16 -0800 |
| Message-ID | <5bd1a974-d057-4579-ad78-9ee1978ea696@googlegroups.com> |
| In reply to | #32040 |
> > Dlatego paradoksem naszej branży jest to, że najwięcej systemów > > krytycznych pisze się w... C. > > Tak. To jest paradoks. > Dodam tylko, że jeszcze wiekszym paradoksem jest to, iż nie wynika to > _w najmniejszym stopniu_ z jakosci jezyka C jako języka programowania. > Wprost przeciwnie. Tak. > Ten prymitywizm przeklada sie na bardzo duze ulatwienia w stworzeniu > kompilatora, ktory "pojdzie" bez problemu rowniez na prymitywnym > sprzecie (embedded itp). Nie. Tzn. łatwość w tworzeniu kompilatora była argumentem, który miał znaczenie dawno temu, jak nie było kompilatorów i trzeba było je tworzyć. Wtedy fakt, że napisanie kompilatora C było proste, ułatwił ekspansję C na każdą nową platformę. Teraz ten argument nie ma znaczenia, bo kompilatory już są i nie trzeba ich pisać. Nowe platformy sprzętowe nie powstają, wszystko się z grubsza zunifikowało a np. nowe mikrokontrolery powstają w ramach istniejących już rodzin. A nawet jak się jakiś producent wychyli z czymś istotnie nowym, to wystarczy dopisać backend do gcc, czyli skorzystać z istniejącego już front-endu. Dlatego walory języka C w tym zakresie przestały mieć znaczenie. Dodatkowo, nie jest istotne, żeby kompilator "poszedł" na prymitywnym sprzęcie, bo nikt poważny nie kompiluje na targecie. Kompiluje się na dowolnym biurkowym hoście a na target wrzuca gotowy obraz - to pozwala użyć dowolnie skomplikowanego toolsetu nawet w odniesieniu do mikrokontrolera z 512 bajtów RAMu. Właśnie dlatego typowe dzisiejsze środowisko do programowania takich mikrokontrolerów jest oparte na Eclipsie i zajmuje ileś GB na dysku i wymaga procesora i7, żeby się dało z niego korzystać. Prymitywizm języka C jest natomiast przydatny (również dzisiaj) do tego, że w takim języku związek między kodem źródłowym a obiektowym (tzn. tym skompilowanym) jest niemal 1:1 i każdy średnio rozgarnięty inżynier jest w stanie wskazać linię ciągłą, w obie strony, pomiędzy tym co napisał a tym co uruchomił. To jest absolutnie kluczowe w projektach krytycznych - tzn. jeśli tej jednoznaczności nie ma, to projekt nie ma szans na sukces, przynajmniej nie przy dzisiejszych standardach procesowych. Innym językiem, który pozwala na takie jednoznaczne przełożenie, jest Ada (tzn. jakiś rygorystycznie dobrany podzbiór). Z C++ też się da, przy starannie wybranym podzbiorze języka. Z tych trzech wygrywają... przyzwyczajenia. -- Maciej Sobczak * http://www.inspirel.com
[toc] | [prev] | [next] | [standalone]
| From | AK <nobody@nowhere.net> |
|---|---|
| Date | 2018-11-21 15:54 +0100 |
| Message-ID | <pt3rk5$1b6i$1@gioia.aioe.org> |
| In reply to | #32046 |
On 2018-11-21 08:16, Maciej Sobczak wrote: >> Ten prymitywizm przeklada sie na bardzo duze ulatwienia w stworzeniu >> kompilatora, ktory "pojdzie" bez problemu rowniez na prymitywnym >> sprzecie (embedded itp). > Nie. Tak. Po prostu zadzialal mechanizm zdobycia popularnosci/masy krytycznej. Nie tylo w informatyce byle g.. po zdobyciu popularnosci staje sie "mainstreamem" (vive np.siostry Godlewskie...). PS: Od lat piszę na usenecie, ze prawo Kopernika dziala idetycznie w IT jak i w finansach. PS0: Poza tym bylem "naocznym swiadkiem"/uczesnikiem (a nawet niestety propagatorem) wypierania jezykow z duzych maszyn typu Algol, Simula, Prolog, PL/I, Modula2 przez badziewie C/C++ sowe, wiec bede sie upieral, ze to byla glowna przyczyna (bo XT 4.87 MHz 512kB nie uciagnelo nic innego poza prymitywnym TurboC compiler (pozniej TurboC++). Owszem. Czasowo uchowal sie Pascal (dzieki TurboPascalowi), ale w jego przypadku jednak z przyczyn upadku bylo olanie standardu *.obj na rzecz *.tpu, ale glowna idiotyczna polityka Borlanda (miast skupi sie na rozwoju kompilatora/ow to zaczal kupowac a to AMI Pro a to dBase itp.... W rezultacie MS C/C++- wtedy badziewny - go dogonil i przegonil). AK
[toc] | [prev] | [next] | [standalone]
| From | AK <nobody@nowhere.net> |
|---|---|
| Date | 2018-11-21 16:07 +0100 |
| Message-ID | <pt3sb6$1cid$1@gioia.aioe.org> |
| In reply to | #32046 |
On 2018-11-21 08:16, Maciej Sobczak wrote: > Prymitywizm języka C jest natomiast przydatny (również dzisiaj) do tego, że w takim języku związek między > kodem źródłowym a obiektowym (tzn. tym skompilowanym) jest niemal 1:1 i każdy średnio rozgarnięty inżynier > jest w stanie wskazać linię ciągłą, w obie strony, pomiędzy tym co napisał a tym co uruchomił. > To jest absolutnie kluczowe w projektach krytycznych - tzn. jeśli tej jednoznaczności nie ma, to projekt nie ma > szans na sukces, przynajmniej nie przy dzisiejszych standardach procesowych. Co? To niby na mainframes nie bylo projektow krytycznych/fault tolerant? Nie bylo np. AS400 itp, a toto wcalenie bylo tworzone w C/C++. > Innym językiem, który pozwala na takie jednoznaczne przełożenie, jest Ada (tzn. jakiś rygorystycznie > dobrany podzbiór). W kwestii Ady nie do konca sie zgodze. To jednak o wiele wyzszy poziom jezyka niz assemblerowate C/C++. No a co np. z Modula2?. Kiedys przez lata de-facto standard w RealTime? To byl jezyk wyzszego poziomu niz C++, a nie przeszkodzilo mu to w zawladnieciu RT. > Z C++ też się da, przy starannie wybranym podzbiorze języka. PoMISRAny C czy C++ to juz wlasciwie nie jest C/C++ tylko calkiem inny jezyk (tez oczywiscie potworek). > Z tych trzech wygrywają... przyzwyczajenia. Tu sie zgodze (a nawet wiecej). Kiedysz krolowala sztuka, dzis kroluja przyzwyczajenia/lenistwo/ "brak ciekawosci swiata". Datego dzis tylu Ayatollahow C/C++. AK
[toc] | [prev] | [next] | [standalone]
| From | Maciej Sobczak <see.my.homepage@gmail.com> |
|---|---|
| Date | 2018-11-21 13:48 -0800 |
| Message-ID | <f8e74072-815d-44a8-b5e7-c83c3f8049c2@googlegroups.com> |
| In reply to | #32051 |
> Co? To niby na mainframes nie bylo projektow krytycznych/fault tolerant? > Nie bylo np. AS400 itp, a toto wcalenie bylo tworzone w C/C++. Nie wiem, ale tutaj: https://en.wikipedia.org/wiki/IBM_System_i jest: "The AS/400 operating system was originally named OS/400" a tutaj: http://www.stroustrup.com/applications.html OS/400 jest wymieniony jako zrobiony w C++. Niemniej, pisząc "systemy krytyczne" miałem na myśli takie, które zabijają ludzi i z racji tego podlegają certyfikacji. Obecne wymagania dla takich systemów są takie, że kod obiektowy ma być w pełni pokryty testami oraz ma istnieć śladowanie (traceability) pomiędzy kodem źródłowym a tym kodem obiektowym. Da się to spełnić językami imperatywnymi, w których nie ma niejawnych operacji albo ukrytych ścieżek. Mamy tu *podzbiory* C, C++, Ady oraz wspomnianych przez Ciebie Modula, Pascal i im podobnych. > W kwestii Ady nie do konca sie zgodze. To jednak o wiele wyzszy poziom > jezyka niz assemblerowate C/C++. Nie w tym kontekście. Wsparcie dla modułów czy kontrola dostępu albo typy z zakresami to nie jest dla mnie wyższy poziom języka. Masz na myśli jakieś inne cechy? > No a co np. z Modula2?. Kiedys przez lata de-facto standard w RealTime? No i co nim? No był taki język. Najwyraźniej nic nie wnosił. W sumie - nie potrzeba nam 10 podobnych do siebie języków. > > Z C++ też się da, przy starannie wybranym podzbiorze języka. > > PoMISRAny C czy C++ to juz wlasciwie nie jest C/C++ tylko calkiem inny > jezyk (tez oczywiscie potworek). Żaden język nie może być użyty w całości. To zawsze jest starannie dobrany podzbiór - tak, aby dało się spełnić wymogi procesów certyfikacyjnych. A MISRA to nie jest poważne i kompleksowe rozwiązanie problemu. Jeśli większość obowiązkowych reguł jest jednocześnie "undecidable" (!), to widać, że to jest tylko wstęp do dalszych rozważań a nie jakaś broń ostateczna. -- Maciej Sobczak * http://www.inspirel.com
[toc] | [prev] | [next] | [standalone]
| From | AK <nobody@nowhere.net> |
|---|---|
| Date | 2018-11-22 16:08 +0100 |
| Message-ID | <pt6gq8$1q78$1@gioia.aioe.org> |
| In reply to | #32056 |
On 2018-11-21 22:48, Maciej Sobczak wrote:
> a tutaj:
>
> http://www.stroustrup.com/applications.html
>
> OS/400 jest wymieniony jako zrobiony w C++.
Ot chorendalna manipulacja.
C/C++ do OS/400 dodano znaaaacznie pozniej jako jeszcze jeden
jezyk aplikacyjny.
Jest wierutna bzdura, ze w nim napisano OS/400.
PS: Dla "znawcow" co to nie lubia bytecode(s) (bo wolne itp.):
Caly OS/400 jest oparty na bytecode.
Wszystkie kompilatory w nim produkuja _wlasnie_ bytecode.
AK
[toc] | [prev] | [next] | [standalone]
| From | AK <nobody@nowhere.net> |
|---|---|
| Date | 2018-11-20 00:00 +0100 |
| Message-ID | <psvfau$s2$1@gioia.aioe.org> |
| In reply to | #32024 |
On 2018-11-19 21:18, szykcech@gmail.com wrote: >> Warto przyjrzeć się językowi Idris i typom zależnym. Twórca Idris, Edwin Brady, >> opowiada tutaj o nim z humorem: >> https://www.youtube.com/watch?v=zSsCLnLS1hg > > Po po pierwsze, primo: > 1. C++ jest zupełnie wystarczający do wszystkiego. Boze jedyny... to juz nie jest odlot. To niczym nie skazone wstecznictwo i betoniarstwo - wlasciwie eliminujace z zawodu zwanego programostą. AK
[toc] | [prev] | [next] | [standalone]
| From | Wojciech Muła <wojtek.mula@gmail.com> |
|---|---|
| Date | 2018-11-22 13:53 -0800 |
| Message-ID | <170bb219-f954-45e2-9912-99106a1ca1a9@googlegroups.com> |
| In reply to | #32029 |
On Tuesday, November 20, 2018 at 12:00:50 AM UTC+1, AK wrote: > On 2018-11-19 21:18, szykcech@gmail.com wrote: > >> Warto przyjrzeć się językowi Idris i typom zależnym. Twórca Idris, Edwin Brady, > >> opowiada tutaj o nim z humorem: > >> https://www.youtube.com/watch?v=zSsCLnLS1hg > > > > Po po pierwsze, primo: > > 1. C++ jest zupełnie wystarczający do wszystkiego. > > Boze jedyny... to juz nie jest odlot. > To niczym nie skazone wstecznictwo i betoniarstwo - wlasciwie > eliminujace z zawodu zwanego programostą. Niestety, w tym zdaniu szyka jest dużo prawdy, zastąpiłbym tylko słowo "wszystkiego" zwrotem "wszystkiego za co płacą całkiem nieźle". C++ mimo swojej wielopoziomowej koślawości wygrywa, m.in. dlatego, że stoją za nim duże firmy, które inwestują w rozwój i promocję. Jest takie ładne określenie cubic dollars. To prawda, że C++ jest technologicznie zapóźniony o jakieś 10-20 lat, ale powoli nadrabia (i nawet wygląda na to, że komitet sobie z tego zdaje sprawę). To prawda, że można w C++ pisać w popieprzony sposób, ale na szczęście nikt nie zmusza. Alternatywy się nie przebiły, mimo teoretycznej lepszości i często wielkiego szumu. Np. taki D chyba już zdechł odkąd Facebook przestał go promować. Go był pomyślany jako zastępstwo dla C++ - moduły, współbieżność, odśmiecanie pamięci. Czyli niby bolączki C++, ale fakty są takie, że do Go poszli phppwcy, pythoniarze, javascriptowcy. Bo język prosty, ale kompilowany więc szybszy. Ada? No jest gdzieś tam[1]. Rust? Nie powala i poza Mozillą i podjaranymi studentami nikt tego poważnie nie używa. Niestety, jesteśmy skazani na C++. I być może w wersji C++27 będzie już całkiem dobry. ;) w. [1] taka historyjka: pewna zachodnia firma chciała przenieść do Polski utrzymanie adowego projektu, ale... nie było u nas wystarczającej liczby programistów.
[toc] | [prev] | [next] | [standalone]
| From | AK <nobody@nowhere.net> |
|---|---|
| Date | 2018-11-22 23:25 +0100 |
| Message-ID | <pt7acb$181j$1@gioia.aioe.org> |
| In reply to | #32063 |
On 2018-11-22 22:53, Wojciech Muła wrote: > Go poszli phppwcy, pythoniarze, javascriptowcy. Bo język prosty, ale kompilowany więc szybszy. Nie. Nie dlatego. Glownie dlatego, ze sedno go to b.dobre asychro (goroutines). (z tego powodu sam pobawie sie jeszcze w Go przed emerytura). PS: Powrot do "przyszlosci" - pomyslec, ze asynchro/multitasking oparte na korutynach bylo "immanentna" ustandaryzowana czescia Simuli67. No tak.. ale przyszly XT i zabily nie tylko Simule67 ale i ine porzadne j.prog. AK
[toc] | [prev] | [next] | [standalone]
| From | AK <nobody@nowhere.net> |
|---|---|
| Date | 2018-11-23 00:41 +0100 |
| Message-ID | <pt7erk$1eer$1@gioia.aioe.org> |
| In reply to | #32063 |
On 2018-11-22 22:53, Wojciech Muła wrote: > Niestety, jesteśmy skazani na C++. I być może w wersji C++27 będzie już całkiem dobry.;) Tu sie zgodzę (lubię żyć nadzieją:) PS: Na szczęście wtedy już będę w krainie wiecznych kompilatorów... AK
[toc] | [prev] | [next] | [standalone]
| From | AK <nobody@nowhere.net> |
|---|---|
| Date | 2018-11-23 00:43 +0100 |
| Message-ID | <pt7evk$1eer$2@gioia.aioe.org> |
| In reply to | #32065 |
On 2018-11-23 00:41, AK wrote: > Niestety, jesteśmy skazani na C++. Poprawka. 1. Siebie wykluczam 2. Wcale nie jestesmy skazani (jest .NET, jest Java). AK
[toc] | [prev] | [next] | [standalone]
| From | szykcech@gmail.com |
|---|---|
| Date | 2018-11-22 22:33 -0800 |
| Message-ID | <ff4af9ad-fd12-42f4-8e64-70fc991929e1@googlegroups.com> |
| In reply to | #32066 |
W dniu piątek, 23 listopada 2018 00:43:51 UTC+1 użytkownik AK napisał: > On 2018-11-23 00:41, AK wrote: > > Niestety, jesteśmy skazani na C++. > 2. Wcale nie jestesmy skazani (jest .NET, jest Java). Przecież to syf w porównaniu do C++ z Qt...
[toc] | [prev] | [next] | [standalone]
| From | AK <nobody@nowhere.net> |
|---|---|
| Date | 2018-11-23 10:34 +0100 |
| Message-ID | <pt8hiv$uaq$1@gioia.aioe.org> |
| In reply to | #32067 |
On 2018-11-23 07:33, szykcech@gmail.com wrote: > Przecież to syf w porównaniu do C++ z Qt... Nie wypowiadaj sie na tematy o ktorych masz dokladnie zerowe pojecie. PS: Gdybys mial choc troche oleju w glowie, to zauwazylbys od razu, ze model Qt (obiekt w Qt jest tak naprawde tylko referencja) jest dokladnie "zmalpowaniem" model Java-owego i .NET-owego. Dobrze zreszta, bo model "wartosciowy" C++ byl (a szczegolnie dzisiaj jest) chory. Qt poprawia wiec w tym wzgledzie chore C++. Tylko ze... Qt to nie standard, ba! Nawet nie darmowe (GPL) i ciezkie (jako biblioteka) jak cholera. PS1: Co do syfiastosci modelu wartosciowego. Nie jest syfiasty jesli istnieje jako alernatywa, a nie "only you" jak w C++. W takiej Simuli67 istnialy sobie dwa modele 1. wartosciowy: a := b // a staje sie kopia b - tak jak '=' w C++ 1. referencyjny: a :- b // a staje sie referencja b - tak jak '=' w Java Autor C++ pozwala sobie twierdzic ze zaczerpnal z Simule i poprawil :) Smich :) AK
[toc] | [prev] | [next] | [standalone]
Page 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
Back to top | Article view | pl.comp.programming
csiph-web