•  

    pokaż komentarz

    To czekaj... To teraz 2+2, to ile to będzie czwórek po przecinku, bo już się kurza pogubiłem??? 0.O

    pokaż spoiler ( ͡° ͜ʖ ͡°)

  •  

    pokaż komentarz

    Artykuł jest dobry, ale sam tytuł wprowadza w błąd. Proponowany nowy standard też jest zmiennoprzecinkowy (i to nawet bardziej zmienny niż dotychczasowy, bo dla małych liczb będzie większa dokładność niż dla dużych). Co więcej, mocno wątpię w szybką popularyzację tego standardu - języki programowania starają się nie porzucać kompatybilności wstecznej, a już szczególnie nie w miejscach, które nie są widoczne na pierwszy rzut oka.

    •  

      pokaż komentarz

      @AutomatycznyCzarodziej:

      To nie wiem szczerze mówiąc jak oryginalny tytuł dokładnie i sensownie przetłumaczyć na język polski :(

      NEW APPROACH COULD SINK FLOATING POINT COMPUTATION

    •  

      pokaż komentarz

      @RFpNeFeFiFcL: Nowe podejście możesz znaleźć obliczanie punktu płynnego. Wujek Google nie boli ヽ( ͠°෴ °)ノ

    •  

      pokaż komentarz

      @nabzd: dobrze przetłumaczył, taka trochę poezja

    •  

      pokaż komentarz

      języki programowania starają się nie porzucać kompatybilności wstecznej

      @AutomatycznyCzarodziej: co ma język programowania do sprzętowej implementacji operacji artymeetycznych?

    •  

      pokaż komentarz

      @keny-keczuloki-anuloki że się nie może zmienić epsylon operacji ani istniejące (nawet głupie i błędne) porównania. A skoro zmienimy dokładność reprezentacji to zmienimy zachowanie istniejącego kodu czyli zerwie kompatybilność.

      Jeżeli sprzętowa realizacja obliczeń nie będzie miała żadnego wpływu na wyniki to jaki jest cel tego nowego standardu?

    •  

      pokaż komentarz

      @keny-keczuloki-anuloki: Na przykład Java gwarantuje, że float będzie IEEE 754. Gdyby popularne procesory przestały wspierać ten standard to wtedy pojawiłby się problem, czy symulować starą semantykę na nowym standardzie.

    •  

      pokaż komentarz

      A skoro zmienimy dokładność reprezentacji to zmienimy zachowanie istniejącego kodu czyli zerwie kompatybilność.

      @illustratum-monachus:

      że float będzie IEEE 754

      @AutomatycznyCzarodziej:

      No tak, ale ten nowy typ mógłby być po prostu nowym typem, a float pozostałby floatem...

    •  

      pokaż komentarz

      @AutomatycznyCzarodziej: a to nie jest tak że na poziomie budowy procesora będzie trzeba dokonać zmian? float dalej pozostanie floatem jedynie procesor inaczej będzie przechowywał zmiennoprzecinkowe liczby i inaczej dokonywał na nich obliczeń

    •  

      pokaż komentarz

      @illustratum-monachus: częściowo masz rację a częściowo nie, bo wszystkie te triki programowe wynikają właśnie z niedokładności floata, walnie się parę ifów w preprocesorze tak żeby obsłużyć nowy rodzaj float i to cała magia

    •  

      pokaż komentarz

      To nie wiem szczerze mówiąc jak oryginalny tytuł dokładnie i sensownie przetłumaczyć na język polski :(

      @RFpNeFeFiFcL: nie zawsze trzeba dokładnie tłumaczyć. Oryginalne tytuły wcale nie muszą być dobre. Zmień po prostu na "Nowe podejście do reprezentacji liczb zmiennoprzecinkowych." lub "Klasyczna reprezentacja liczb zmiennoprzecinkowych może odejść od lamusa". Bieżący tytuł to informacja nieprawdziwa.

    •  

      pokaż komentarz

      A skoro zmienimy dokładność reprezentacji to zmienimy zachowanie istniejącego kodu czyli zerwie kompatybilność.

      @illustratum-monachus: przecież poprawienie dokładności nie musi niczego psuć. Nie używamy floatów po to, żeby mieć określoną niedokładność. Z reguły używamy ich, gdy wprowadzona przez nie niedokładność może być zignorowana i wcale nie obrazimy się, gdy będzie mniejsza.

    •  

      pokaż komentarz

      @RFpNeFeFiFcL: floating point to zmienno przecinkowe ale floating znaczy rownież "pływający" a wczenisniej mamy "sink" czyli zatopić, czyli ktos tu zabawil siew grę słow którą można przetłumaczyć: "nowe podejscie pozwoli zatopić obliczenia zmiennoprzecinkowe" oczywiscie po tlumaczeniu traci to sens :)

    •  

      pokaż komentarz

      @AutomatycznyCzarodziej:
      Myślę, że oprogramowanie przechodzi gdzie tylko może na wyższy poziom, bez "pokazywania komputerowi palcem które bity gdzie". To jedyna opcja na przyszłość. Wirtualizacja. Bez tego nie będzie możliwy dalszy rozwój techniki. "Palcem pokazywać" to można było w C-64, gdzie cały komputer miał 64KB pamięci, a słowo danych 8-bitów.

      Niektórzy się upierają, żeby to robić do dziś, bo przecież tyle cykli można wyciągnąć z dzisiejszych CPU.

      Ja mam bez porównania więcej szacunku do szalonego Terry-ego Davisa i jego Temple OS-a, niż tych, co się dzisiaj upierają przy C++ w poważnych aplikacjach czy nawet grach. Czemu? Bo u Terry-ego to była pasja, sztuka dla sztuki i w takim kontekście niech sobie ludzie budują komputery lampowe nawet. Albo... kalkulatory mechaniczne.

      Ale jak mówimy o rozwoju techniki - nie ma nic bardziej wstecznego, niż programowanie chipa w dzisiejszych czasach, niż marnowanie potencjału roboczego programisty, który mógłby tworzyć nowe rzeczy, ale po raz dziesięciomiliardowy kombinuje jak przydzielić pamięć na tablicę albo jak wyszukać dane w strukturze. Oczywiście dla danego modelu sprzętu, danego rocznika, danej wersji systemu operacyjnego itd.

      Czas, żeby to komputery decydowały o takich pierdołach gdzie i jak mielić bity liczb, programista, program i użytkownik chcą LICZBY. I operowania na takich pojęciach jak liczba. Na szczęście w IT już nie rozmawiamy o woltach i amperach, prawda, tak samo należałoby przestać rozmawiać o bitach. No chyba że... Tam gdzie jest tego miejsce, czyli projektowanie samych komputerów, sterowników czy systemów operacyjnych.

      Jakoś nikt dziś nie narzeka, że programy komputerowe z reguły nie mają dostępu do sterowania mechaniką dysków w komputerach, czy fizycznego składowania danych w chipach dysków SSD. Program może sobie co najwyżej zapisać plik w katalogu, całą resztą zajmuje się OS. Dzięki temu nie ma problemu z nośnikiem. Cokolwiek nowego jest wymyślane, można NATYCHMIAST zacząć tego używać, nie trzeba portować gigantycznej ilości STAREGO oprogramowania.

      Nikomu nie przeszkadza brak dostępu do "bebechów" systemu plików czy składowania - tak samo powinno się stać z resztą komponentów systemu. Pomiędzy kodem "przestrzeni użytkownika" a metalem powinien stać "gruby" system, który przejmuje 100% drobiazgowych implementacji technicznych, chociażby takich jak fizyczne operacje na liczbach. W tym momencie powstaje nowy procesor - cały dotychczasowy soft nadal na nim działa - w dodatku działa szybciej.

      Nie jestem pewien, czy dobrze się domyślam, ale troszkę coś takiego zadziałało w przypadku kart graficznych. Softu nie pisze się pod kątem konkretnego chipa. Pisze się raczej na biblioteki graficzne, które te same rzeczy wykonują szybciej i lepiej na nowocześniejszym sprzęcie. W innym przypadku, być może teoretycznie dałoby się zrobić 100x lepszą i szybszą grafikę w grze ale... ta gra nigdy by nie powstała, bo cóż, nie dożylibyśmy wersji alfa 0.1 ;)

    •  

      pokaż komentarz

      @keny-keczuloki-anuloki czyli chcesz wspierać sprzętowo dwa układy to gdzie 'pozbywanie sie' z tytułu?

      @KKK1337 nie ważne co oczekujemy a czego nie, zmiana zachowania to zerwanie kompatybilności.
      @zarowka12 czytaj wyżej, nie mówię czy to źle czy dobrze

    •  

      pokaż komentarz

      NEW APPROACH COULD SINK FLOATING POINT COMPUTATION

      @RFpNeFeFiFcL: nowe podejście może ZREDUKOWAĆ (?) obliczenia zmiennoprzecinkowe

    •  

      pokaż komentarz

      @the_revenant gość opisuje dość szczególne zastosowania w których małe optymalizacje na bardzo niskim poziomie mogą dać duże oszczędności. W takim przypadku babaranie się z detalami na poziomie bitów ma sens. To są zastosowania gdzie warto już nawet wlasnego proca zaprojektować właśnie pod ten cel.

      Ja rozumiem że "programiści PHP" takimi detalami się brzydzą:) ale HL to nie cały świat i ktoś ten LL tez projektuje i robi.

    •  

      pokaż komentarz

      @the_revenant: Fajna teoria. Taka troche nie zyciowa.

      Masz bardzo waskie pojecie rozwoju. Bo rozwoj to nie tylko implementacje big data, si itd. Maszyny wirtualne mialy, maja i beda miec wady i zalety, ktore w niektorych zastosowaniach po prostu je dyskwalifikuja. To taka klotnia jak o wykazanie, ze dany jezyk programowania jest tym jedynym slusznym, do wszystkiego. Dlatego wlasnie maszyny wirtualne juz masz od dawna, sa wykorzystywane tam gdzie jest sens i dlatego nie wyparly jezykow niskiego poziomu i noe zanosi sie o ich wyparcie. Chociazby dlatego, ze w czyms te maszyny do wirtualizacji trzeba pisac.

      Po drugie zakladasz ze zawsze i wszedzie masz dostep do nie ograniczonych zasobow i hardware będzie się rozwijal w nieskonczonosc. W procesorach wydajnosc z generacji na generacje nie rosnie tak szybko, a jak jeszcze 10 lat temu. Dochodzimy do granicy atomu. Po trzecie sa zastosowania jak chociazby IoT, urzadzenia ktore na baterii maja pracowac lata... Po co im ladowac maszyny wirtualne?

      Co z systemami czasu rzeczywostego, gdzie czesto opoznienia rzedu setnej milisekundy maja gigantyczny wplyw na poprawnosc dzialania? Kto normalny wrzuci tam dodatkowo vm?

      Tak samo wielowatkowosc - tez bylo gadanie ze to przyszlosc i trzeba tak pisac oprogramowanie. I co? I nic, bo pewnych rzeczy nie da sie zrownoleglic.

    •  

      pokaż komentarz

      @kofey:
      Jasne że wszystkiego się nie da, ale sporo się da. Powiedziałbym większość.
      Zobacz sobie - masz urządzenie mobilne, gdzie jest nacisk na małe rozmiary i oszczędzanie baterii. Telefon komórkowy. I co? Maszyna wirtualna. Nie tylko się to rozwiązanie sprawdziło - to rozwiązanie wygrało - Android zawojował świat szybkością z jaką powstały na niego apki.

      Ech, ciężko zrzucić kompatybilność wsteczną, ale się da i trzeba.

      A pamiętam, że swojego czasu były takie cudaczne procesory, które na poziomie sprzętowym miały emulację różnych dialektów CICS na fizycznym RISC. Szkoda, że rozwiązanie się nie przyjęło.

      Wracając do tematu - brak wirtualizacji powinien być wyjątkiem od reguły teraz, a nie regułą. Robią dziś telewizor to się nie pierdaczą w pisanie dedykowanego kodu maszynowego pod jakiś specjalizowany procek - walą tam androida i od razu mają praktycznie za darmochę obsługę YT i innych podobnych ustrojstw. Jasne, że byłoby bardziej wydajne a nawet tańsze zrobienie rozwiązania dedykowanego pod specyficzny hardware TV, ale zanim ktokolwiek to dopracuje, konkurencja wypuści cały "ekosystem" usług, apek i innych atrakcji.

    •  

      pokaż komentarz

      No tak, ale ten nowy typ mógłby być po prostu nowym typem, a float pozostałby floatem...

      @keny-keczuloki-anuloki: Tak, ale wtedy ten nowy typ będzie bardzo fajnym nowym dodatkiem, a nie zabójcą dzisiejszych floatów.

      Na szczęście w IT już nie rozmawiamy o woltach i amperach, prawda, tak samo należałoby przestać rozmawiać o bitach.

      @the_revenant: Ale przecież bity to jest podstawowe ograniczenie, bo nie ma nieskończonej pamięci w komputerze. Nawet takie języki jak python czy Java, które dają duże gwarancje, co do pamięci, i tak mogą mieć wycieki pamięci albo zużyć wszystkie bity.

      programista, program i użytkownik chcą LICZBY. I operowania na takich pojęciach jak liczba.

      Ale nie da się fizycznie zrobić liczby. Takie pojęcie jak liczba nie przenosi się do komputera. Co najwyżej jakieś przybliżenia, które tu i ówdzie będą ujawniać swoją naturę.

      Liczby naturalnych da się reprezentować w pełni, bo są ograniczenia pamięci. Tu co prawda można zrobić sztuczki i ukryć to przed programistą (są zresztą takie języki, które udostępniają "nieograniczone" liczby - chociażby Haskell i jego Integer). To całe ukrycie jednak jest kosztem znacznego obniżenia szybkości obliczeń.

      Ale w przypadku liczb rzeczywistych jest znacznie gorzej, bo nawet w wyniku prostego dzielenia można dostać liczby z nieskończonym rozwinięciem. I tu zaczynamy mówić o precyzji, liczbie bitów, zaokrągleniach itd.

      Nie jestem pewien, czy dobrze się domyślam, ale troszkę coś takiego zadziałało w przypadku kart graficznych. Softu nie pisze się pod kątem konkretnego chipa. Pisze się raczej na biblioteki graficzne, które te same rzeczy wykonują szybciej i lepiej na nowocześniejszym sprzęcie.

      No czyli podobnie do tego, jak systemy operacyjne traktują dzisiejsze procesory. Tyle tylko, że te abstrakcje mają wady i ujawniają się w mało oczekiwanych momentach. Polecam poczytać: https://stackoverflow.com/questions/11227809/why-is-processing-a-sorted-array-faster-than-processing-an-unsorted-array

    •  

      pokaż komentarz

      @AutomatycznyCzarodziej:
      A czytałeś o tych positach? To nie jest wolniejsze tylko szybsze przybliżenie.

      I tylko o przybliżenia nam chodzi. Ale na wyższym poziomie abstrakcji. Jasne, czasami to kosztuje za dużo, ale czasem jest wprost przeciwnie.

      Dziś w stacjonarnych urządzeniach trudno wykorzystać dostępną pamięć i jest to częściej problemem dziś, niż niedobór pamięci. I znów, posity o których mowa akurat dają tę samą funkcjonalność przy 2x mniejszym zużyciu pamięci.

      Co do liczby w ujęciu fizycznym - podobno 64 bity dzisiejszego typu double wystarczą do przedstawienia wszystkiego w fizyce, od kwarków po galaktyki. Większa rozdzielczość nie ma fizycznego sensu. Ale teoretycznie i matematycznie jest oczywiście możliwa.

      Wiesz co najbardziej się przyda? Elastyczność. Brak tego sztywnego ograniczenia do standardów z lat 70-tych.

      Zauważ jeszcze, że producenci sprzętu będą wykorzystywać możliwości ulepszania rzeczy. Zwłaszcza, jak będzie coraz trudniej dodawać kolejne gigaherce i terabajty. Teraz trafiają na ścianę - co nie wymyślą czy nie ulepszą - istniejący soft nie pójdzie. Przy dodaniu dodatkowej warstwy abstrakcji ta bariera częściowo przynajmniej zostanie pokonana.

    •  

      pokaż komentarz

      @the_revenant: Nie chce cie martwic, ale android stara sie odejsc od maszyny wirtualnej. Co raz czesciej bytecode w czasie instalacji jest w przynajmniej w czesci kompilowany, a nie uruchamiany w vm. Masa apek ma wstawki w c/c++ wlasnie w najbardziej krytycznych dla wydajnoscia miejscach.

      Po za tym o sukcesie androida w glownej mierze zadecydowala specyficzna sytuacja na rynku, a nie to czy byla tam vm czy nie. Uzytkownikow interesowalo co innego, co android mial, a konkurencja nie. Ale nie mam teraz warunkow, a zeby sie o tym rozpisywać.

      O wykorzystaniu danej technologii ma decydowac jej charakterystyka, koszty, wydajnosc i ograniczenia. Usilne wciskanie czegos "bo tak powinno byc" to jest dopiero hamulec rozwoju. I nie, nie na kazda konfiguracje sprzetowa masz dostepna vm, wiec nie przedstawiaj jej jako lek na cale zlo.

    •  

      pokaż komentarz

      A czytałeś o tych positach? To nie jest wolniejsze tylko szybsze przybliżenie.

      @the_revenant: Sam napisałeś, że liczba to powinna być liczba. I ja się odniosłem do tego, że to jest niemożliwe. Detale implementacyjne wyciekną. Będzie tak dlatego, że nie da się dokładnie reprezentować liczby. Posit nie ma tu nic do rzeczy.

      I znów, posity o których mowa akurat dają tę samą funkcjonalność przy 2x mniejszym zużyciu pamięci.
      I nie są kompatybilne wstecznie.

      podobno 64 bity dzisiejszego typu double wystarczą do przedstawienia wszystkiego w fizyce

      Ale potem może się pojawić potrzeba wykonywania operacji arytmetycznych na tych liczbach. I wtedy zniknie zakładana dokładność.

      Wiesz co najbardziej się przyda? Elastyczność. Brak tego sztywnego ograniczenia do standardów z lat 70-tych.

      O tym właśnie był mój komentarz. Co najwyżej będzie sztywne ograniczenie do standardów z 2020. Nie da się w całości przenieść liczb rzeczywistych do komputera, a podmiana ich implementacji na inny standard będzie widoczna, nawet jeśli zabronimy zaglądać do reprezentacji. I będzie tak dlatego, że operacje arytmetyczne to nie będą operacje liczb rzeczywistych, tylko ich przybliżenie.

    •  

      pokaż komentarz

      Co do liczby w ujęciu fizycznym - podobno 64 bity dzisiejszego typu double wystarczą do przedstawienia wszystkiego w fizyce, od kwarków po galaktyki. Większa rozdzielczość nie ma fizycznego sensu. Ale teoretycznie i matematycznie jest oczywiście możliwa.

      @kofey: Co ty powiesz...

      Jądro atomu jest rzędu 10^-15m. No więc sprawdźmy. Uzyję double czyli 64-bitowej liczby zmiennoprzecinkowej.
      Powinno wyjść zero. Skompilujmy to, można też na ideone

      `#include <stdio.h>

      void main(void)
      {
      double d;
      d = 0.1 + 1e-15 - 0.1 - 1e-15;
      printf("d=%1.20g\n", d);
      }

      $ gcc -o a a.c ; ./a
      d=-7.9927783735919132413e-19
      `

      Nie widzę zera. Może 1/1250 jądra atomu to nie błąd ale to wciąż 8000 razy więcej niż rozmiar elektronu, który wynosi 10^-22m. Więc większa rozdzielczość ma sens czy go nie ma?

    •  

      pokaż komentarz

      @osetnik: looool. O czym ty k%??a w ogole do mnie piszesz?

      Wiesz ze w granicy atomu chodzi o zmniejszanie wielkosci tranzystora? Wiesz ze wydajnosc procesorow wzrasta, bo zmniejszamy tranzystory i mozemy ich upakowac wiecej na danej przestrzeni? Wiesz ze nie zrobisz tranzystora mniejszego niz rozmiar kilku atomow? Ergo nie bedzie sie dalo zwiekszac wydajnosci w nieskonczonosc. I o tym pisalem w kontekscie rozwoju i maszyn wirtualnych, a nie ze nie mamy typu danych do reprezentacji wielkosci fizycznej jaka jest rozmiar atomu...............

    •  

      pokaż komentarz

      Jasne że wszystkiego się nie da, ale sporo się da. Powiedziałbym większość.

      @the_revenant: nie, nie i jeszcze raz nie! przestudiuj sobie historię sprzętu komputerowego, procesorów a w szczególności procesorów graficznych to zrozumiesz.

      był sobie kiedyś procesor co bezpośrednio w sprzęcie implementował maszynę wirtualną Java - pamiętasz jak zawojował świat? nie? to zrozumiałe - to była ślepa droga.

      tak samo ślepa droga jest we wszystkich procesorach które chcą być bardziej zaawansowane architektonicznie niż dobrze już oklepana podstawa. nie będą, bo jakiekolwiek zmiany raz wyprodukowanego sprzętu są mocno ograniczone. owszem istnieją rozwiązania jak fpga ale ich koszt jest ekstremalnie drogi i znajdują swoje nisze w specyficznych zastosowaniach. historia pokazała że lepiej jest zrobić prosty procesor ogólnego (cpu) lub prawie ogólnego (gpu) zastosowania i go oprogramować dając użytkownikowi końcowemu wymaganą funkcjonalność, niż tą funkcjonalność mozolnie rzeźbić w krzemie.

      Zobacz sobie - masz urządzenie mobilne, gdzie jest nacisk na małe rozmiary i oszczędzanie baterii. Telefon komórkowy. I co? Maszyna wirtualna. Nie tylko się to rozwiązanie sprawdziło - to rozwiązanie wygrało - Android zawojował świat szybkością z jaką powstały na niego apki.

      @the_revenant: dokładnie o to chodzi, ale nikt i to absolutnie nikt nie będzie przenosił tą maszynę wirtualną na poziom sprzętu!

      A pamiętam, że swojego czasu były takie cudaczne procesory, które na poziomie sprzętowym miały emulację różnych dialektów CICS na fizycznym RISC. Szkoda, że rozwiązanie się nie przyjęło.

      @the_revenant: jak to się nie przyjęło? a obecne procesory intela to czym są? to jest właśnie procesor risc implementujący sprzętowo x86+amd64 ISA.

      Wracając do tematu - brak wirtualizacji powinien być wyjątkiem od reguły teraz, a nie regułą. Robią dziś telewizor to się nie pierdaczą w pisanie dedykowanego kodu maszynowego pod jakiś specjalizowany procek

      @the_revenant: sprawa jest znacznie bardziej skomplikowana niż to przedstawiasz. po pierwsze to dla nowego sprzętu zawsze musisz napisać nowe drivery i to jest i zawsze będzie babranie się w bity i niskopoziomowe bebechy. z drugiej strony obecnie istniejące systemy operacyjne jeśli pominiemy kwestię driverów to wymagają zwyczajnego przebudowania i już w pełni działają na nowej platformie - to jest właśnie przykład Androida. pokazujesz, że na Androidzie jest VM ale to jest już warstwa wyżej. kernel w takim Androidzie i zwykłym PC jest praktycznie taki sam, choć dostosowany do sprzętu.

    •  

      pokaż komentarz

      @ksawery2001:
      Jesteś pewien, że nowe procki nie dodadzą nowego formatu liczb? Patrz, kiedyś zaczęli wprowadzać rozszerzenia typu MMX, na początku mało który soft to obsługiwał, dziś to już standard wszędzie, obsługa jest praktycznie wszędzie, gdzie jest korzyść z tych rozszerzeń.

      Może i kompatybilność wsteczna będzie trzymana jeszcze długo, ale patrz - jak tylko dodadzą nowy format liczb do maszyn wirtualnych typu JVM czy CLR, cała masa softu napisanego dla nich przyśpieszy.

      Z resztą, jasna sprawa, że z dodawania "rdzeniów" też nie można uzyskać cudów, ale tutaj jest szczególna sytuacja - różnica pomiędzy 1 rdzeniem a 4 jest gigantyczna w wydajności takiego sobie normalnego OS-a, apek, czy nawet serwera. Ba, dla serwerów dodawanie "rdzeniów" będzie dawać dużo lepsze efekty niż dla desktopów. Pojedyncze procesy typu obliczenia jest dość trudno zrównoleglać, bo dość często do wykonania kolejnych obliczeń potrzebne są wyniki poprzednich, a to scenariusz stricte szeregowy. Można dzielić na porcje, ale porcje trzeba potem połączyć, w jednym miejscu coś się zyska, w innym straci.

      Ale bardzo powszechnym scenariuszem użycia jakiegokolwiek komputera, nie tylko PC jest scenariusz, kiedy komputer reaguje na zewnętrzne zdarzenia asynchronicznie. W tym układzie jeśli ma mało rdzeni, musi sobie obsługiwanie zdarzeń kolejkować, przełączać pomiędzy wątkami a to kosztuje czas. Przy większej liczbie wątków zaczynają pojawiać się lagi i maszyna generalnie się zapycha. A dodasz rdzenie i robienie kilku rzeczy na raz bez przycinki nagle staje się nie tylko możliwe, ale i komputer ogarnia to na luzie i zapasem mocy. To w praktyce widziałem przy konfiguracji wirtualek. Jak dawałem im mało rdzeni, to przycinały okrutnie, czasem dodanie jednego więcej robiło ogromną różnicę. Jasne, znów jak masz 32 rdzenie, to dodanie jeszcze 32 już dużo nie pomoże, a dodanie następnych 1000 praktycznie nic już nie da.

      Tak samo z wszelkimi nowinkami jak ta odnośnie liczb. Może w niektórych scenariuszach przyśpieszyć, w niektórych nie.

      Na koniec taka ciekawostka - kiedyś goście napisali programik który w skrócie umożliwiał nawigację po wektorowej mapie terenu. W znaczeniu przeglądarka / edytor map. Napisane w C++. Wyglądało tragicznie (brak wygładzania linii, krzywych, siermiężny interfejs), ale co najważniejsze - przycinało jak diabli. Ja napisałem coś podobnego w dotnecie, rysowaniem zajmował się system, ja mu tylko napuszczałem wektorów całymi wiadrami, a system rysował, skalował, obracał, animował itd. Nie dość że zajęło mi to ułamek czasu, to mój wysokopoziomowy kod w C#, z tym strasznym Garbage Collectorem zbierającym bez pytania - chodził dużo szybciej, bez żadnych przycinek, stabilne 60FPS i wrażenie absolutnej natychmiastowości każdego działania użytkownika. Jak gra na DirectX. Morzna? Morzna! ;) (Pod spodem z resztą faktycznie rysował DirectX).

      Tak że wysoki poziom ma ogromny potencjał, który stale rośnie. Microsoft bardzo mocno idzie w tę stronę jeśli chodzi o Windows. Przepisują coraz więcej kodu systemu na dotnet. I nowe składniki pomimo bolączek wieku dziecięcego (czyli niedopracowania) - często działają już dużo lepiej od starych. Jednym z powodów jest świadomie forsowana coraz większa niezależność od sprzętu. Podłączam TV 4K - nie ma problemu, tekst, grafika, cały UI skaluje się tak, żeby wykorzystać wyższą rozdzielczość bez utraty czytelności. Z wykorzystaniem pełnej akceleracji dostępnych w nowych kartach graficznych. Nowa funkcja karty czy monitora? Nie ma problemu, soft nie musi o niej wiedzieć, wystarczy że system wie. I sobie to hula z możliwością żonglowania sobie okienkami pomiędzy wirtualnymi pulpitami czy obszarami pulpitów. Wiem, w Linuxach było od dawna, ale w starym API Windowsa opartym na Win32 to tak nie bardzo chciały te wszystkie bajery działać. Od razu taką apkę poznaję po rozmazanym wyglądzie na moim ekranie 4K. Już nie mówiąc, że i problemów to więcej stwarzało, bo wszystko było bardziej skomplikowane to i więcej punktów, gdzie coś mogło się zepsuć.

    •  

      pokaż komentarz

      kiedyś goście napisali programik który w skrócie umożliwiał nawigację po wektorowej mapie terenu

      @the_revenant: zgaduję, że nie używali akceleracji rysowania grafiki a ty tak. :) to teraz odwróć sytuację, ty z tym całym swoim wysoko-poziomowym programowaniem nie używasz directx, a koledzy ze swoim c++ tak. i jak to będzie działać? użycie języka programowania nie ogranicza cię w użyciu technologii.

      to nie jest tak, że jestem przeciwko programowaniu wysokopoziomowym - uważam to za przyszłość i sam coraz więcej w tym programuję. ale całkowicie nie zgadzam się z tematem sprzętowym pokazywanym przez ciebie.

      i nie mmx nie można porównać do jvm czy innej maszyny wirtualnej. to jest taki sam niski poziom jak klasyczne instrukcje asemblera. a podany w artykule nowy sposób obsługi liczb fp to dalej jest niski poziom.

    •  

      pokaż komentarz

      @the_revenant: a pozniej takie lby jak ty sie biora za robienie aplikacji w javascripcie na chromium i gigabajty ramu uciekaja na w sumie nie wiadomo co. Dziala to kilkunastokrotnie (co najmniej) razy wolniej niz natywna aplikacja xD Nie no nie ma czasu na bawienie sie w optymalizacje czy niskopoziomowe jezyki. Tak jak czytalem juz dawno temu artykul goscia co mieli do wczytania cala mase danych w pythonie i z tego co obliczyli to zajeloby im to kilka czy kilkanascie miesiecy. Po zrobieniu natywnego modulu do pythona w c czy tam c++ wczytalo wszystko w kilka godzin :D Przez takie ameby co maja gdzies optymalizacje coraz wiecej aplikacji przestaje nadawac sie do uzytku - chociazby taki skajpaj, ktory kiedy zajmowac w ramie maks 60mb to teraz conajmniej 300mb zajmuje xD Atomowe edytory tekstu to juz w ogole abominacja (w tym klony typu VS code itp). Po chwili kilka gb ramu zajete. Kilka takich aplikacji i system krzyczy, ze nie ma juz pamieci (16gb ram) a jak dojdzie do tego debugowanie + wirtualka w tle to juz w ogole sieczka ostra xD Brawo Ty!

    •  

      pokaż komentarz

      @JohnVanClouds:
      Widzę, że wpadasz w jakiś fanatyzm, a sprawiałeś wrażenie rozsądnej osoby, z którą ciekawie się dyskutuje. Serio, wyzywanie, jak w przedszkolu? Mam inne zdanie na techniczny temat, więc nazwiesz mnie amebą? Nie uznasz, że mogę mieć jakąkolwiek wiedzę i umiejętności, bo mam inny profil i robię w innych tematach? Człowieku, ile Ty masz lat? Ja mam 42. Przez moment miałem wrażenie, że dyskutuję z dorosłym geekiem, ale... Wrażenia w internetach są mylne. Ja Cię nie obrażałem, człowieku. Nie znam Cię, być może jesteś dobrym fachowcem w wąskiej dziedzinie, której nie znam, tak samo jak Ty nie masz pojęcia o mojej pracy i wiedzy. Ja mam niestety trochę pojęcia o Twojej kulturze i umiejętności dyskusji.

  •  

    pokaż komentarz

    Mam 386DX wiec mam kooprocesor i zmiennoprzecinkowe operacje smigaja jak ta lala

  •  

    pokaż komentarz

    Rozwiazaniem jest przejście do przestrzeni Banacha i utworzenie nowej rodziny typów