Hej, w jakimś projekcie Javowym użyłem tego https://github.com/jhalterman/expiringmap
nie mogę znaleźć czegoś podobnego dla .net.
Jest to mapa, której poszczególne wartości zostają automatycznie usunięte np. po x minutach. Taka opcja właśnie mnie interesuje.
Szukaj pod haslem cache
rjakubowski napisał(a):
https://learn.microsoft.com/en-us/dotnet/api/system.runtime.caching.memorycache?view=net-8.0
Używamy IMemoryCache/MemoryCache w projekcie od kilku miesięcy, działa bez problemów. Thread safe, czas życia każdego elementu ustawia się indywidualnie. Polecam.
@ŁF: a najlepsze jest że jak się zapytałem GPT to mi proponował custom implementacje dekorując Dictonary<TK,TV>. Tak w ramach "czy AI nas zastąpi?" 
ŁF napisał(a):
rjakubowski napisał(a):
https://learn.microsoft.com/en-us/dotnet/api/system.runtime.caching.memorycache?view=net-8.0
Używamy IMemoryCache/MemoryCache w projekcie od kilku miesięcy, działa bez problemów. Thread safe, czas życia każdego elementu ustawia się indywidualnie. Polecam.
Jakie jest zasowanie czegoś takiego w środowiskach z GarbageCollectorem?
_flamingAccount napisał(a):
Jakie jest zasowanie czegoś takiego w środowiskach z GarbageCollectorem?
Co masz na myśli, jakie to ma znaczenie? Żeby GC zebrał śmieci to musisz zwolnić wszystkie referencje do nich prowadzące, jeśli masz element w statycznej kolekcji to nigdy nie zostanie zwolniony a jak zrobisz WeakRef to zostanie zwolniony w losowym momencie. Co ma GC do cache?
Co ma GC do cache?
Zastanawiam się jaki jest worflow do takich rzeczy. Wiem ze w wysoko wydajnych/resposywnych srodowiskach, jest preferecja na to zeby allokować pamieć i ją zwalniać w ścisle określonych mometach. Takie cos sie nadaje, albo jako kolekcja do loggera, i wyswietlania logów z ostanich 5 min.
Ale tak w normlanym kodowaniu, nie możesz tych elementów po prostu zwolnic na event? To brzmi jak, nie chce mi się programowac, jedziemy na staticach, i sprzatamy pamieć raz na 5 min zeby było git.
Dlatego zastanawia mnie po co to jest, skoro można usnąć elementy normalnie, a timmer to najgorsza opcja tak dlugo jak nie pracuje sie z czasem.
Ale cache - pamiec podreczna - bynajmniej NIE sluzy do alokacji/zwalniania pamieci tylko do memoizacji...
_flamingAccount napisał(a):
Jakie jest zasowanie czegoś takiego w środowiskach z GarbageCollectorem?
GarbageCollector służy do tego, żeby nie zapchać pamięci. Cache służy do tego, żeby przez jakiś czas trzymać dane.
To pytanie brzmi trochę jak: jakie jest zastosowanie lodówki w domach z pralką?.
john_doe napisał(a):
nie mogę znaleźć czegoś podobnego dla .net.
Napisz swoją. Np. kolekcja z fixed capacity trzymająca Optionale w środku. Co sekundę (tick) pchasz do niej nulla. Oprócz tego co jakiś czas wpadają do niej twoje tymczasowe wartości. Odpowiednio manipulując capacity i zegarem ticków otrzymasz odpowiedni czas życia. Powodzenia!
loza_prowizoryczna napisał(a):
Napisz swoją. Np. kolekcja z fixed capacity trzymająca Optionale w środku. Co sekundę (tick) pchasz do niej nulla. Oprócz tego co jakiś czas wpadają do niej twoje tymczasowe wartości. Odpowiednio manipulując capacity i zegarem ticków otrzymasz odpowiedni czas życia. Powodzenia!
To nie tylko prowizoryczne, ale i niewydajne rozwiązanie. Do tego nie zapewnia opcji takiego samego czasu życia dla wielu elementów. Poza tym - skoro istnieje MemoryCache, implementujące to, o co pytał OP, będące thread-safe i w dodatku wchodzące w skład biblioteki standardowej, to po co pisać coś swojego?
ŁF napisał(a):
To nie tylko prowizoryczne, ale i niewydajne rozwiązanie.
Ponieważ?
Do tego nie zapewnia opcji takiego samego czasu życia dla wielu elementów.
Taka szybka zagwozdka - jak unieważnić z dowolnie małą precyzją czasową wiele elementów przy zagwarantowaniu jednoczesnego dostępu z wielu wątków?
Poza tym - skoro istnieje
MemoryCache, implementujące to, o co pytał OP, będące thread-safe i w dodatku wchodzące w skład biblioteki standardowej, to po co pisać coś swojego?
Żeby to później utrzymywać :) Poza tym od kiedy programista jest uwiązany do biblioteki standardowej i jej zachowań? Mono też niby C# ale czy współdzieli stdlib?
loza_prowizoryczna napisał(a):
Ponieważ?
W odpowiedzi zacytuję Ciebie
Co sekundę (tick) pchasz do niej nulla
Ale jeśli nie widzisz implikacji tego, co wymyśliłeś, to pozwól, że rozwinę temat.
Myślę, że znalazłoby się jeszcze kilka powodów, dla których takie rozwiązanie jest niewydajne, ale nie chce mi się już myśleć na ten temat.
Poza tym - skoro istnieje
MemoryCache(...) to po co pisać coś swojego?Żeby to później utrzymywać
To, jak rozumiem, to żart? Utrzymywanie kodu kosztuje czas i pieniądze, które mogłyby być przeznaczone na rozwój oprogramowania. Do tego jest to nudne, bo wymaga testów regresyjnych.
Poza tym od kiedy programista jest uwiązany do biblioteki standardowej i jej zachowań?
To, że możesz coś zrobić, nie oznacza, że musisz. Kryterium, kiedy robić coś samemu, a kiedy użyć gotowego rozwiązania, jest zdrowy rozsądek. Innymi słowy, jeśli miałbym kupić nowy samochód z gwarancją za 100k, albo budować własny przez kilka lat, bez gwarancji sukcesu i samemu go serwisować, to wybrałbym zakup nowego.
Taka szybka zagwozdka - jak unieważnić z dowolnie małą precyzją czasową wiele elementów przy zagwarantowaniu jednoczesnego dostępu z wielu wątków?
To zależy od implementacji, ale to drugie sprowadzi się to do nazwanego semafora, ewentualnie jakiegoś innego elementu IPC i przestawienia wartości zmiennej. Zrobienie zaś tego wydajnie z nanosekundową precyzją jest dla mnie zagadką - jak byś to zrobił?
ŁF napisał(a):
W odpowiedzi zacytuję Ciebie
Co sekundę (tick) pchasz do niej nulla
Odpowiem cytatem na cytat:
Odpowiednio manipulując capacity i zegarem ticków otrzymasz odpowiedni czas życia
I ma to znaczenie.
- Kolekcja jest ustalonego rozmiaru. Jeśli będziesz potrzebował wepchnąć do niej więcej elementów, to zrobisz to kosztem wypchnięcia przed czasem innych.
Tak to jest zasadne. Kolejka stałego rozmiaru ogranicza nas do relacji 1 element - 1 tick zegara. Ale to jest obejścia.
- Trzymanie nadmiarowych elementów to marnowanie pamięci.
Można to powiedzieć o wszystkim, nadmiarowych strukturach, indeksach dostępowych czy timestampach.
- Wydajne usuwanie z kolekcji - albo jeszcze gorzej, przesuwanie elementów - przy jednoczesnym wydajnym odwoływaniu się do elementów jest sprzeczne. Lista/linked list zapewni szybkie usuwanie, ale wolny dostęp do elementów; tablica zapewni szybki dostęp do elementów po indeksie, ale usuwanie będzie wolne; słownik szybko znajdzie element i szybko usunie go, ale policzenie hasha jest kosztowne, a struktura leżąca pod słownikiem, służąca do przechowywania danych, nie zapewni trzymania najstarszych elementów gdzieś na początku.
Jeśli upierasz się na schemacie prostej kolejki i jej poszczególnych implementacjach to i owszem. Ale jest jeszcze taka technika która rozwiązuje problem stałej długości kolekcji (powyżej). Być może zaproponowane przez ciebie struktury nie są tu odpowiednie?
- Jeśli będziesz chciał trzymać jeden element przez dobę, to będzie wymagać to kolekcji trzymającej 24 * 60 * 60 - 1 = 86399 nulli, w bajtach to będzie jeszcze * 8 (64b architektura, czyli wskaźniki mają 8B). Rozumiem, że niecały megabajt w czasach, kiedy względnie prosty komunikator potrzebuje minimum pół GB pamięci do działania, to nie jest dużo, jednak chyba się zgodzisz, że jest to dalece nieoptymalne rozwiązanie, kiedy z tego niecałego MB potrzebujesz faktycznie 8B?
Nie wiem jak w C# ale typy Optional (czy też Nullable, jak zwał tak zwał) w implementacji powinny być maksymalnie tanie. Poza tym pomijasz jeden prosty fakt - jeśli każdy null jest w istocie tym samym pustym wskaźnikiem to zwykła systemowa technika kompresji pamięci zredukuje ten problem do nieistniejącego.
To, jak rozumiem, to żart? Utrzymywanie kodu kosztuje czas i pieniądze, które mogłyby być przeznaczone na rozwój oprogramowania. Do tego jest to nudne, bo wymaga testów regresyjnych.
Jeśli ciągle stoimy na ramionach olbrzymów to nigdy nie nauczymy się latać.
Poza tym od kiedy programista jest uwiązany do biblioteki standardowej i jej zachowań?
To, że możesz coś zrobić, nie oznacza, że musisz. Kryterium, kiedy robić coś samemu, a kiedy użyć gotowego rozwiązania, jest zdrowy rozsądek. Innymi słowy, jeśli miałbym kupić nowy samochód z gwarancją za 100k, albo budować własny przez kilka lat, bez gwarancji sukcesu i samemu go serwisować, to wybrałbym zakup nowego.
Dlatego ciągle będziesz płacił za nówkę coraz więcej i więcej aż w końcu odkryjesz że cię na to nie stać i zaczniesz remontować złoma którego masz. A wtedy odkryjesz że nie potrafisz a mechanik też się ceni.
Taka szybka zagwozdka - jak unieważnić z dowolnie małą precyzją czasową wiele elementów przy zagwarantowaniu jednoczesnego dostępu z wielu wątków?
To zależy od implementacji, ale to drugie sprowadzi się to do nazwanego semafora, ewentualnie jakiegoś innego elementu IPC i przestawienia wartości zmiennej. Zrobienie zaś tego wydajnie z nanosekundową precyzją jest dla mnie zagadką - jak byś to zrobił?
Nie wiem, w idealnym scenariuszu masz N egzekutorów sprzętowych odpowiadających N elementom, wtedy problem jest trywialny. Normalnie jednak tak nie jest i wtedy zaczynasz bawić się w schedulery a to oznacza narzut i opóźnienia. Nie wiem bo RTOSy to nie moja zabawka.
Semafory rozwiązują problem jednoczesnego dostępu do pamięci z wielu wątków. Ten problem nie istnieje jednak jeśli dany obszar pamięci jest powiązany z ściśle z jednym wątkiem i jednym run loopem (pomijam przerzucanie wykonania wątku pomiędzy sprzętowymi rdzeniami, zakładam że twórcy hardware są na tyle ogarnięci z zewnątrz jest to niewidoczne).
loza_prowizoryczna napisał(a):
Odpowiednio manipulując capacity i zegarem ticków otrzymasz odpowiedni czas życia
I ma to znaczenie.
Cudownie, ale trochę nie rozumiem, do czego się tu odnosisz.
- Kolekcja jest ustalonego rozmiaru. Jeśli będziesz potrzebował wepchnąć do niej więcej elementów, to zrobisz to kosztem wypchnięcia przed czasem innych.
Tak to jest zasadne. Kolejka stałego rozmiaru ogranicza nas do relacji 1 element - 1 tick zegara. Ale to jest obejścia.
Większość problemów da się obejść, jednak podejście inżynieryjne podpowiada, żeby zwyczajnie nie używać rozwiązania, które powoduje problemy, które trzeba obchodzić.
- Trzymanie nadmiarowych elementów to marnowanie pamięci.
Można to powiedzieć o wszystkim, nadmiarowych strukturach, indeksach dostępowych czy timestampach.
Nie, nie można tego powiedzieć o wszystkim. Istnieje pewna minimalna ilość danych, oznaczająca minimalną entropię, a zapewniająca poprawne działanie jakiejś funkcjonalności i istnieją algorytmy potrafiące bardzo wydajnie działać na takiej strukturze danych. Zwykle używa się mniej oszczędnej struktury ze względu np. na architekturę procesora, jednak tutaj nie mowa o kilku zgubionych bajtach w jakimś modelu, tylko o potencjalnie kilku rzędach wielkości więcej zbędnych bajtów. To dlatego, że proponujesz algorytm, który potencjalnie trzyma niemal same zbędne dane, porównujesz to z jakimiś abstrakcyjnymi "nadmiarowymi strukturami" (a przecież sam właśnie zaproponowałeś taką nadmiarową strukturę). O co zaś chodzi Ci z dostępem przez indeks czy timestampach w kontekście marnowania zasobów, to nie mam pojęcia. Czy możesz wytłumaczyć?
- Wydajne usuwanie z kolekcji - albo jeszcze gorzej, przesuwanie elementów - przy jednoczesnym wydajnym odwoływaniu się do elementów jest sprzeczne. Lista/linked list zapewni szybkie usuwanie, ale wolny dostęp do elementów; tablica zapewni szybki dostęp do elementów po indeksie, ale usuwanie będzie wolne; słownik szybko znajdzie element i szybko usunie go, ale policzenie hasha jest kosztowne, a struktura leżąca pod słownikiem, służąca do przechowywania danych, nie zapewni trzymania najstarszych elementów gdzieś na początku.
Jeśli upierasz się na schemacie prostej kolejki i jej poszczególnych implementacjach to i owszem. Ale jest jeszcze taka technika która rozwiązuje problem stałej długości kolekcji (powyżej). Być może zaproponowane przez ciebie struktury nie są tu odpowiednie?
Nie proponuję żadnej struktury. Sam powiedziałeś o kolekcji. Zauważ, że każda optymalizacja komplikuje algorytm, wymaga czasu (a więc pieniędzy) na implementację, może wprowadzić błędy regresyjne, i wymaga większej wiedzy, żeby wprowadzić kolejne zmiany. Używając już przytoczonego przykładu samochodu - przypomina mi to lutowanie własnego radia do auta, zamiast kupienia gotowego.
- Jeśli będziesz chciał trzymać jeden element przez dobę, to będzie wymagać to kolekcji trzymającej 24 * 60 * 60 - 1 = 86399 nulli, w bajtach to będzie jeszcze * 8 (64b architektura, czyli wskaźniki mają 8B). Rozumiem, że niecały megabajt w czasach, kiedy względnie prosty komunikator potrzebuje minimum pół GB pamięci do działania, to nie jest dużo, jednak chyba się zgodzisz, że jest to dalece nieoptymalne rozwiązanie, kiedy z tego niecałego MB potrzebujesz faktycznie 8B?
Nie wiem jak w C# ale typy Optional (czy też Nullable, jak zwał tak zwał) w implementacji powinny być maksymalnie tanie. Poza tym pomijasz jeden prosty fakt - jeśli każdy null jest w istocie tym samym pustym wskaźnikiem to zwykła systemowa technika kompresji pamięci zredukuje ten problem do nieistniejącego.
Kompresja kosztuje, a pofragmentowana tablica słabo się kompresuje.
To, jak rozumiem, to żart? Utrzymywanie kodu kosztuje czas i pieniądze, które mogłyby być przeznaczone na rozwój oprogramowania. Do tego jest to nudne, bo wymaga testów regresyjnych.
Jeśli ciągle stoimy na ramionach olbrzymów to nigdy nie nauczymy się latać.
Jeśli zamiast zrobić remont w domu zajmiesz się wypalaniem gipsu i robieniem farby, to zamiast zrobić remont w tydzień czy miesiąc, zajmie Ci to lata. Na sam koniec będziesz mógł być z siebie dumny, bo od podszewki będziesz znał każdą technologię potrzebną do zbudowania domu, tylko po co? Od tego są specjalizacje, żeby każdy robił to, na czym zna się najlepiej. Od tego są gotowe produkty, żeby zaoszczędzić czas na robieniu ich samemu (potencjalnie dużo gorzej).
PS Mowa o programowaniu, a nie filozofii.
Poza tym od kiedy programista jest uwiązany do biblioteki standardowej i jej zachowań?
To, że możesz coś zrobić, nie oznacza, że musisz. Kryterium, kiedy robić coś samemu, a kiedy użyć gotowego rozwiązania, jest zdrowy rozsądek. Innymi słowy, jeśli miałbym kupić nowy samochód z gwarancją za 100k, albo budować własny przez kilka lat, bez gwarancji sukcesu i samemu go serwisować, to wybrałbym zakup nowego.
Dlatego ciągle będziesz płacił za nówkę coraz więcej i więcej aż w końcu odkryjesz że cię na to nie stać i zaczniesz remontować złoma którego masz. A wtedy odkryjesz że nie potrafisz a mechanik też się ceni.
Nówkę kupuję raz na kilka - kilkanaście lat i jeżdżę nią w czasie, kiedy Ty nadal budujesz swoje auto i do sklepu idziesz z kapcia (bo roweru też jeszcze nie zbudowałeś) i to boso (buty też samodzielnie miałeś zrobić, ale zabrakło Ci na to czasu przez prace nad samochodem i rowerem).
Ale ponieważ mowa o oprogramowaniu, to ono się nie zużywa. Ba! Raz dobrze napisane może być użyte wiele razy. Czas zaoszczędzony na niebudowaniu rozwiązań od zera oznacza krótszy czas implementacji, niższy koszt, w efekcie większe zadowolenie klienta i wyższą konkurencyjność. Dodam, że ta konkretna funkcjonalność w postaci MemoryCache jest dostępna za darmo, czyli mój nowy samochód jest za darmo i jeszcze regularnie otrzymuje nowe części, też za darmo.
Taka szybka zagwozdka - jak unieważnić z dowolnie małą precyzją czasową wiele elementów przy zagwarantowaniu jednoczesnego dostępu z wielu wątków?
To zależy od implementacji, ale to drugie sprowadzi się to do nazwanego semafora, ewentualnie jakiegoś innego elementu IPC i przestawienia wartości zmiennej. Zrobienie zaś tego wydajnie z nanosekundową precyzją jest dla mnie zagadką - jak byś to zrobił?
Nie wiem, w idealnym scenariuszu masz N egzekutorów sprzętowych odpowiadających N elementom, wtedy problem jest trywialny. Normalnie jednak tak nie jest i wtedy zaczynasz bawić się w schedulery a to oznacza narzut i opóźnienia. Nie wiem bo RTOSy to nie moja zabawka.
Mowa o skalowalnym, rzeczywistym, a nie idealnym scenariuszu. Chyba nie wyobrażasz sobie miliona takich sprzętowych egzekutorów? O RTOS nikt nie wspominał, więc nie wiem, po co używasz tego terminu, zwłaszcza, że mowa o C#, czyli pracy w środowisku zarządzanym, w dodatku z GC.
Kiedy biorę gotową bibliotekę np. do cache, to zanim jej użyję, robię testy jak sobie poradzi w typowych i skrajnych warunkach pracy. Implementacja mnie nie interesuje, jeśli algorytm działa wydajnie. Taki test trwa ułamek czasu potrzebnego na utworzenie rozwiązania od zera (i przetestowania go!).
Semafory rozwiązują problem jednoczesnego dostępu do pamięci z wielu wątków. Ten problem nie istnieje jednak jeśli dany obszar pamięci jest powiązany z ściśle z jednym wątkiem i jednym run loopem (pomijam przerzucanie wykonania wątku pomiędzy sprzętowymi rdzeniami, zakładam że twórcy hardware są na tyle ogarnięci z zewnątrz jest to niewidoczne).
Super, ale co to ma do rzeczy?
Taka szybka zagwozdka - jak unieważnić z dowolnie małą precyzją czasową wiele elementów przy zagwarantowaniu jednoczesnego dostępu z wielu wątków?
Zrobienie zaś tego wydajnie z nanosekundową precyzją jest dla mnie zagadką - jak byś to zrobił?
Przegapiłeś moje pytanie.
ŁF napisał(a):
Cudownie, ale trochę nie rozumiem, do czego się tu odnosisz.
Że zegar nie musi być precyzyjny co do sekundy tylko np. co do minuty lub godziny.
Większość problemów da się obejść, jednak podejście inżynieryjne podpowiada, żeby zwyczajnie nie używać rozwiązania, które powoduje problemy, które trzeba obchodzić.
Jak poczytasz szczegóły tego rozwiązania to też zobaczysz że stosuje pooling i (prawdopodobnie) własną wewnętrzną pętlę do śledzenia czasu. Jakich dodatkowych struktur do tego używa to nie moja broszka.
Nie, nie można tego powiedzieć o wszystkim. Istnieje pewna minimalna ilość danych, oznaczająca minimalną entropię, a zapewniająca poprawne działanie jakiejś funkcjonalności i istnieją algorytmy potrafiące bardzo wydajnie działać na takiej strukturze danych. Zwykle używa się mniej oszczędnej struktury ze względu np. na architekturę procesora, jednak tutaj nie mowa o kilku zgubionych bajtach w jakimś modelu, tylko o potencjalnie kilku rzędach wielkości więcej zbędnych bajtów.
Brawo, czyli właśnie doszedłeś do wniosku że cały ten cache, kolekcja, whatever może być jedynie frontem dla wielu podobnych takich list z różnymi zegarami i pojemnościami które rozwiązują twój niesamowity problem narzutu nulla (jakby to był problem
Nie proponuję żadnej struktury. Sam powiedziałeś o kolekcji.
Kolekcję tutaj rozumiem jako interfejs/protokół. Większość języków ma ich odpowiedniki. Strukturą jest lista wskaźników ograniczona kroczącym oknem synchronizowanym własnym zegarem.
Zauważ, że każda optymalizacja komplikuje algorytm, wymaga czasu (a więc pieniędzy) na implementację, może wprowadzić błędy regresyjne, i wymaga większej wiedzy, żeby wprowadzić kolejne zmiany. Używając już przytoczonego przykładu samochodu - przypomina mi to lutowanie własnego radia do auta, zamiast kupienia gotowego.
Z innej beczki, czytałeś Pana Samochodzika Nienackiego? Wiesz w czym tkwił sekret jego gruchota? ;)
- Jeśli będziesz chciał trzymać jeden element przez dobę, to będzie wymagać to kolekcji trzymającej 24 * 60 * 60 - 1 = 86399 nulli, w bajtach to będzie jeszcze * 8 (64b architektura, czyli wskaźniki mają 8B). Rozumiem, że niecały megabajt w czasach, kiedy względnie prosty komunikator potrzebuje minimum pół GB pamięci do działania, to nie jest dużo, jednak chyba się zgodzisz, że jest to dalece nieoptymalne rozwiązanie, kiedy z tego niecałego MB potrzebujesz faktycznie 8B?
Nie wiem jak w C# ale typy Optional (czy też Nullable, jak zwał tak zwał) w implementacji powinny być maksymalnie tanie. Poza tym pomijasz jeden prosty fakt - jeśli każdy null jest w istocie tym samym pustym wskaźnikiem to zwykła systemowa technika kompresji pamięci zredukuje ten problem do nieistniejącego.
Kompresja kosztuje, a pofragmentowana tablica słabo się kompresuje.
Jak wyżej - tablica wskaźników/referencji nie jest pofragmentowana. Pofragmentowana to może być sterta.
Jeśli zamiast zrobić remont w domu zajmiesz się wypalaniem gipsu i robieniem farby, to zamiast zrobić remont w tydzień czy miesiąc, zajmie Ci to lata. Na sam koniec będziesz mógł być z siebie dumny, bo od podszewki będziesz znał każdą technologię potrzebną do zbudowania domu, tylko po co?
Tak mój śp. dziadek postawił swój dom za komuny. Zrobił to w dwa lata (czyli może trochę dłużej niż dziś stawiają nowe domy) za ułamek ceny którą dziś trzeba by na to samo wydać. tylko po co? i był z tego cholernie dumny całe swoje życie bo większość jego kolegów wybrała/albo czekała na mieszkanie przydziałowe w bloku a ich dzisiejsi potomkowie psioczą na to że ich antenaci byli na tyle leniwi/niekumaci że woleli wybrać kurnik.
PS Mowa o programowaniu, a nie filozofii.
Programowanie jest sztuką a nie filozofią.
Nówkę kupuję raz na kilka - kilkanaście lat i jeżdżę nią w czasie, kiedy Ty nadal budujesz swoje auto i do sklepu idziesz z kapcia (bo roweru też jeszcze nie zbudowałeś) i to boso (buty też samodzielnie miałeś zrobić, ale zabrakło Ci na to czasu przez prace nad samochodem i rowerem).
Mam nadzieję że chociaż wymieniasz olej i sprawdzasz układ hamulcowy. Pytam bo zawsze mogę trafić na twoją nówkę na drodze więc z asekuracji.
Ale ponieważ mowa o oprogramowaniu, to ono się nie zużywa. Ba! Raz dobrze napisane może być użyte wiele razy.
Tak, a ci wszyscy prognozujący ciągły wzrost wakatów w IT pewnie opierają to o logarytmiczny rozwój algorytmiki.
Mowa o skalowalnym, rzeczywistym, a nie idealnym scenariuszu. Chyba nie wyobrażasz sobie miliona takich sprzętowych egzekutorów?
Czy ty kiedykolwiek programowałeś coś na GPU? Nie te rzędy wielkości ale liczba takich egzekutorów może być całkiem spora (a w enterprajs może nawet dobija setek tysięcy).
Super, ale co to ma do rzeczy?
Delikatnie zwracam ci uwagę że nie rozumiesz implementacji więc rzucasz coś co znasz.
Przegapiłeś moje pytanie.
Nie wiem, jak mogłeś przegapić odpowiedź.
loza_prowizoryczna napisał(a):
Że zegar nie musi być precyzyjny co do sekundy tylko np. co do minuty lub godziny.
Co ma precyzja zegara do tego, że zaproponowane przez Ciebie rozwiązanie jest niewydajne?
Większość problemów da się obejść, jednak podejście inżynieryjne podpowiada, żeby zwyczajnie nie używać rozwiązania, które powoduje problemy, które trzeba obchodzić.
Jak poczytasz szczegóły tego rozwiązania to też zobaczysz że stosuje pooling i (prawdopodobnie) własną wewnętrzną pętlę do śledzenia czasu. Jakich dodatkowych struktur do tego używa to nie moja broszka.
Co ma implementacja MemoryCache do tego, że zaproponowane przez Ciebie rozwiązanie jest niewydajne?
Nie, nie można tego powiedzieć o wszystkim. Istnieje pewna minimalna ilość danych, oznaczająca minimalną entropię, a zapewniająca poprawne działanie jakiejś funkcjonalności i istnieją algorytmy potrafiące bardzo wydajnie działać na takiej strukturze danych. Zwykle używa się mniej oszczędnej struktury ze względu np. na architekturę procesora, jednak tutaj nie mowa o kilku zgubionych bajtach w jakimś modelu, tylko o potencjalnie kilku rzędach wielkości więcej zbędnych bajtów.
Brawo, czyli właśnie doszedłeś do wniosku że cały ten cache, kolekcja, whatever może być jedynie frontem dla wielu podobnych takich list z różnymi zegarami i pojemnościami które rozwiązują twój niesamowity problem narzutu nulla (jakby to był problem
Nie nadążam za Twoją logiką. Co ma marnowanie zasobów, które sam zaproponowałeś poprzez trzymanie wielu zbędnych nulli, do implementacji "wielu list z różnymi zegarami i pojemnościami"? Rozmawiamy o Twoim oryginalnym pomyśle, a nie o pomysłach na jego poprawienie.
Kolekcję tutaj rozumiem jako interfejs/protokół. Większość języków ma ich odpowiedniki. Strukturą jest lista wskaźników ograniczona kroczącym oknem synchronizowanym własnym zegarem.
Skomentuję cytatami: napisałem "Trzymanie nadmiarowych elementów to marnowanie pamięci", odpisałeś "Można to powiedzieć o (...) nadmiarowych strukturach".
Z innej beczki, czytałeś Pana Samochodzika Nienackiego? Wiesz w czym tkwił sekret jego gruchota? ;)
Na pewno ogarniasz, że to fikcja literacka, nota bene stworzona przez przyciśniętego finansowo erotomana?
Jak wyżej - tablica wskaźników/referencji nie jest pofragmentowana. Pofragmentowana to może być sterta.
Jak więc nazwiesz tablicę wypełnioną w kilku procentach losowo rozrzuconymi wartościami? Jak nazwiesz tablicę wypełnioną takimi wartościami w 100% albo nie wypełnioną wcale?
Jeśli zamiast zrobić remont w domu zajmiesz się wypalaniem gipsu i robieniem farby, to zamiast zrobić remont w tydzień czy miesiąc, zajmie Ci to lata. Na sam koniec będziesz mógł być z siebie dumny, bo od podszewki będziesz znał każdą technologię potrzebną do zbudowania domu, tylko po co?
Tak mój śp. dziadek postawił swój dom za komuny. Zrobił to w dwa lata (czyli może trochę dłużej niż dziś stawiają nowe domy) za ułamek ceny którą dziś trzeba by na to samo wydać.
tylko po co?i był z tego cholernie dumny całe swoje życie bo większość jego kolegów wybrała/albo czekała na mieszkanie przydziałowe w bloku a ich dzisiejsi potomkowie psioczą na to że ich antenaci byli na tyle leniwi/niekumaci że woleli wybrać kurnik.
Czy potem Twój dziadek sam mieszkał w tym domu, czy wykorzystała go ponownie jego rodzina? Bo idąc dalej Twoją myślą, każdy powinien budować taki dom dla siebie samodzielnie.
A MemCache też ktoś napisał. Może to był Twój drugi dziadek ;-)
Programowanie jest sztuką a nie filozofią.
LOL, chyba nie zarabiałeś jeszcze programowaniem na życie 
Nówkę kupuję raz na kilka - kilkanaście lat i jeżdżę nią w czasie, kiedy Ty nadal budujesz swoje auto i do sklepu idziesz z kapcia (bo roweru też jeszcze nie zbudowałeś) i to boso (buty też samodzielnie miałeś zrobić, ale zabrakło Ci na to czasu przez prace nad samochodem i rowerem).
Mam nadzieję że chociaż wymieniasz olej i sprawdzasz układ hamulcowy. Pytam bo zawsze mogę trafić na twoją nówkę na drodze więc z asekuracji.
Owszem, robię to rękoma kogoś, kto zna się na tym dużo lepiej. A czy Ty zmieniasz olej i filtry samodzielnie? Co robisz z olejem przepracowanym?
BTW kupowanie nowego samochodu było przykładem. Sam jeżdżę autami używanymi ze średniej półki cenowej.
Ale ponieważ mowa o oprogramowaniu, to ono się nie zużywa. Ba! Raz dobrze napisane może być użyte wiele razy.
Tak, a ci wszyscy prognozujący ciągły wzrost wakatów w IT pewnie opierają to o logarytmiczny rozwój algorytmiki.
Nie widzę związku z moją wypowiedzią. BTW rynek IT ostatnio nieco wysechł.
Mowa o skalowalnym, rzeczywistym, a nie idealnym scenariuszu. Chyba nie wyobrażasz sobie miliona takich sprzętowych egzekutorów?
Czy ty kiedykolwiek programowałeś coś na GPU? Nie te rzędy wielkości ale liczba takich egzekutorów może być całkiem spora (a w enterprajs może nawet dobija setek tysięcy).
Przypomnę, że mowa o cache z inwalidacją elementów po pewnym czasie. Chcesz do tego użyć GPU? Przecież tylko udowadniasz to, co pierwotnie stwierdziłem - Twoje rozwiązanie jest niewydajne.
Super, ale co to ma do rzeczy?
Delikatnie zwracam ci uwagę że nie rozumiesz implementacji więc rzucasz coś co znasz.
Implementacji czego? W MemCache nie wnikam, bo nie mam takiej potrzeby, przyszło za darmo, spełnia wymagania odnośnie wydajności, wysyłam Twórcom buziaki i używam. Za to mam wrażenie, że rozumiem Twój oryginalny, prowizoryczny pomysł lepiej od Ciebie. A zamiast przyznać rację, że są lepsze rozwiązania, wymyślasz użycie GPU, kompresję pamięci, przedefiniowujesz pojęcia i przede wszystkim nie odnosisz się do meritum problemu.
Przegapiłeś moje pytanie.
Nie wiem, jak mogłeś przegapić odpowiedź.
Masz na myśli zaprzężenie miliona "egzekutorów" z GPU? Nie sądziłem, że to odpowiedź na serio.
ŁF napisał(a):
Co ma precyzja zegara do tego, że zaproponowane przez Ciebie rozwiązanie jest niewydajne?
To samo co wydajność zegara w CPU do popularności NodeJS/.NET. Pomyśl trochę.
Co ma implementacja
MemoryCachedo tego, że zaproponowane przez Ciebie rozwiązanie jest niewydajne?
Co ma twoje twierdzenie o MemoryCache wspólnego z wydajnością? Use case?
Nie nadążam za Twoją logiką. Co ma marnowanie zasobów, które sam zaproponowałeś poprzez trzymanie wielu zbędnych nulli, do implementacji "wielu list z różnymi zegarami i pojemnościami"? Rozmawiamy o Twoim oryginalnym pomyśle, a nie o pomysłach na jego poprawienie.
Sugerujesz że MemoryCache to pojedyncza struktura o prostym algorytmie?
Na pewno ogarniasz, że to fikcja literacka, nota bene stworzona przez przyciśniętego finansowo erotomana?
Dodatkowo na pasku SB, donoszącym na kolegów po fachu, bawiącego się kiedy inni musieli zapier**ć. O libido dyskutować nie warto bo każdy ma swoje. Ale Mate Rimac chyba musiał jakieś jego dzieła przeczytać i zrozumieć.
Jak więc nazwiesz tablicę wypełnioną w kilku procentach losowo rozrzuconymi wartościami? Jak nazwiesz tablicę wypełnioną takimi wartościami w 100% albo nie wypełnioną wcale?
Co to są losowo rozrzucone wartości? Dla ciebie ideał to tablica wskaźników ułożona sekwencyjnie? W jakim celu? I w ogóle jak?
Czy potem Twój dziadek sam mieszkał w tym domu, czy wykorzystała go ponownie jego rodzina? Bo idąc dalej Twoją myślą, każdy powinien budować taki dom dla siebie samodzielnie.
AMemCacheteż ktoś napisał. Może to był Twój drugi dziadek ;-)
Rodzina w nim dożywa dni spokojnej starości. Ja wolę ładniejsze widoki, rozumiem jednak że ty wolisz spokojną starość :)
LOL, chyba nie zarabiałeś jeszcze programowaniem na życie
Ciężko powiedzieć, lubię to co robię i jeszcze mi za to płacą więc się takimi pierdołami nie zajmuję.
Owszem, robię to rękoma kogoś, kto zna się na tym dużo lepiej. A czy Ty zmieniasz olej i filtry samodzielnie?
Tak?
Co robisz z olejem przepracowanym?
Utylizuję.
BTW kupowanie nowego samochodu było przykładem. Sam jeżdżę autami używanymi ze średniej półki cenowej.
Czyli jesteś już na etapie pośrednim. No cóż, jedni zakładają startupy, inni myślą że zrobią karierę w big korpo.
Tak, a ci wszyscy prognozujący ciągły wzrost wakatów w IT pewnie opierają to o logarytmiczny rozwój algorytmiki.
To ci wyłuszczę - jeśli coś się nie zużywa, łatwo powiela to co za cholerę robi ten wzrost w zatrudnieniu w IT? Przecież wszystkich na scrum masterów nie wezmą.
Nie widzę związku z moją wypowiedzią. BTW rynek IT ostatnio nieco wysechł.
Dużo rzeczy nie widzisz. Ale jakbyś przeczytał to byś może zrozumiał. Nawet coś o suszy tam jest i jak nią zarządzać.
Przypomnę, że mowa o cache z inwalidacją elementów po pewnym czasie. Chcesz do tego użyć GPU? Przecież tylko udowadniasz to, co pierwotnie stwierdziłem - Twoje rozwiązanie jest niewydajne.
Nie o tym był wątek więc nie rżnij głupa. Ale miło że jednak rozumiesz że precyzja zegara ma coś do rzeczy przy dostępie równoległym.
Implementacji czego? W
MemCachenie wnikam, bo nie mam takiej potrzeby, przyszło za darmo, spełnia wymagania odnośnie wydajności, wysyłam Twórcom buziaki i używam.
No właśnie, nie rozumiesz a używasz.
Za to mam wrażenie, że rozumiem Twój oryginalny, prowizoryczny pomysł lepiej od Ciebie. A zamiast przyznać rację, że są lepsze rozwiązania, wymyślasz użycie GPU, kompresję pamięci, przedefiniowujesz pojęcia i przede wszystkim nie odnosisz się do meritum problemu.
Skoro nie rozumiesz tego co znasz to jakim cudem wypowiadasz się na temat czegoś czego nie znasz i nie używasz?
Masz na myśli zaprzężenie miliona "egzekutorów" z GPU? Nie sądziłem, że to odpowiedź na serio.
Nie, mam na myśli że nie traktujesz Nie wiem jako odpowiedzi. A to dużo tłumaczy ;)
loza_prowizoryczna napisał(a):
ŁF napisał(a):
Co ma precyzja zegara do tego, że zaproponowane przez Ciebie rozwiązanie jest niewydajne?
To samo co wydajność zegara w CPU do popularności NodeJS/.NET. Pomyśl trochę.
Pomyślałem trochę i wychodzi mi, że nie ma nic wspólnego (i to pomijając fakt, że nie ma czegoś takiego jak "wydajność zegara w CPU"). A skoro nie ma nic wspólnego, to po co w ogóle o tym napisałeś?
Co ma implementacja
MemoryCachedo tego, że zaproponowane przez Ciebie rozwiązanie jest niewydajne?Co ma twoje twierdzenie o MemoryCache wspólnego z wydajnością? Use case?
Kulturalni ludzie nie odpowiadają pytaniem na pytanie. Więc odpowiem na Twoje, chociaż zaczyna mi to przypominać przepychankę i przestało być merytoryczną rozmową - Ty nie odnosisz się do argumentów, ignorujesz pytania i zaczynasz być nieuprzejmy (vide "pomyśl trochę"). A więc do rzeczy: nie potrzebuję znać i rozumieć implementacji MemoryCache, skoro interfejs spełnia wymagania, a implementacja jest wystarczająco szybka. Use case? Nie wiem, co to ma do rzeczy, ale odpowiem - u mnie kilkuminutowy lokalny cache circa tysiąca tłumaczeń. Natomiast Twój oryginalny pomysł, bez tych udziwnień, które dodałeś w trakcie rozmowy, jest w oczywisty dla mnie sposób niewydajny. Argumenty na poparcie tego podałem kilka postów temu, ale nie odniosłeś się do nich, natomiast zacząłeś rzucać pomysłami typu milion "egzekutorów" z GPU.
Nie nadążam za Twoją logiką. Co ma marnowanie zasobów, które sam zaproponowałeś poprzez trzymanie wielu zbędnych nulli, do implementacji "wielu list z różnymi zegarami i pojemnościami"? Rozmawiamy o Twoim oryginalnym pomyśle, a nie o pomysłach na jego poprawienie.
Sugerujesz że
MemoryCacheto pojedyncza struktura o prostym algorytmie?
Kulturalni ludzie nie odpowiadają pytaniem na pytanie... Jak już wyżej napisałem, nie interesuje mnie, co siedzi w MemoryCache, jeśli działa wydajnie. Ponownie nie odpowiedziałeś na zadane pytanie.
Na pewno ogarniasz, że to fikcja literacka, nota bene stworzona przez przyciśniętego finansowo erotomana?
Dodatkowo na pasku SB, donoszącym na kolegów po fachu, bawiącego się kiedy inni musieli zapier**ć. O libido dyskutować nie warto bo każdy ma swoje. Ale Mate Rimac chyba musiał jakieś jego dzieła przeczytać i zrozumieć.
I od tego czasu Rimac buduje samochody tylko dla siebie. Przecież nikt nie kupuje Bugatti (abstrahując od ich kosztu), w Twoim świecie każdy buduje samochód sam sobie.
Jak więc nazwiesz tablicę wypełnioną w kilku procentach losowo rozrzuconymi wartościami? Jak nazwiesz tablicę wypełnioną takimi wartościami w 100% albo nie wypełnioną wcale?
Co to są losowo rozrzucone wartości? Dla ciebie ideał to tablica wskaźników ułożona sekwencyjnie? W jakim celu? I w ogóle jak?
Ty tak serio?
I znowu nie odnosisz się do zadanych pytań, za to czepiasz się nieistotnych szczegółów. Zaczynam dochodzić do wniosku, że rozmowa z Tobą to faktyczna strata czasu. Widzisz, ja wiem, że mogę nie mieć racji, umiem używać merytorycznych argumentów i na takie odpowiadać, umiem przyznać rację i uczyć się na błędach. Ty byc może też to umiesz, ale jak na razie to co prezentujesz, to arogancja i brak kultury.
Czy potem Twój dziadek sam mieszkał w tym domu, czy wykorzystała go ponownie jego rodzina? Bo idąc dalej Twoją myślą, każdy powinien budować taki dom dla siebie samodzielnie.
AMemCacheteż ktoś napisał. Może to był Twój drugi dziadek ;-)Rodzina w nim dożywa dni spokojnej starości. Ja wolę ładniejsze widoki, rozumiem jednak że ty wolisz spokojną starość :)
Widzę, że albo nie załapałeś analogii, albo celowo ją zignorowałeś. W obu wypadkach
LOL, chyba nie zarabiałeś jeszcze programowaniem na życie
Ciężko powiedzieć, lubię to co robię i jeszcze mi za to płacą więc się takimi pierdołami nie zajmuję.
Ciężko Ci powiedzieć, czy zarabiasz programowaniem na życie? oO
Owszem, robię to rękoma kogoś, kto zna się na tym dużo lepiej. A czy Ty zmieniasz olej i filtry samodzielnie?
Tak?
Brawo. Serio. Ja też chciałbym mieć na to czas, ale na razie wolę pobawić się z moimi dziećmi.
Pytam bo zawsze mogę trafić na twoją nówkę na drodze więc z asekuracji.
Twierdzisz, że mechanik zrobi wymianę oleju i przegląd gorzej, niż Ty? Czy jak mam to rozumieć?
To ci wyłuszczę - jeśli coś się nie zużywa, łatwo powiela to co za cholerę robi ten wzrost w zatrudnieniu w IT? Przecież wszystkich na scrum masterów nie wezmą.
Czy według ci wszyscy juniorzy szpachlują zużyte oprogramowanie?
Otóż digitalizacja wkracza wszędzie, pojawiają się nowe rynki, stare produkty wychodzą z użycia, rywalizacja pomiędzy producentami oprogramowania wymusza wymyślanie nowych rozwiązań, a ciągły rozwój technologii tylko to napędza. Popyt na pracowników w IT jest większy, niż podaż, bo znacząca większość ludzi nie chce lub nie umie programować, między innymi stąd takie a nie inne pensje midów i seniorów. Oraz to, że raz stworzone oprogramowanie można używać i powielać teoretycznie w nieskończoność, czyli raz zainwestowany dolar może przynieść wiele dolarów zysku.
Nie widzę związku z moją wypowiedzią. BTW rynek IT ostatnio nieco wysechł.
Dużo rzeczy nie widzisz. Ale jakbyś przeczytał to byś może zrozumiał. Nawet coś o suszy tam jest i jak nią zarządzać.
Dużo rzeczy nie widzę według Ciebie, a jednak na pytania, które mogłyby mi pomóc zobaczyć, zwyczajnie nie odpowiadasz. Domyślam się, dlaczego tego nie robisz, ale nie chcę Cię obrażać.
(...) nie rżnij głupa.
Słoma wychodzi Ci z butów :-)
Przypomnę, że mowa o cache z inwalidacją
Nie o tym był wątek.
Zatem o czym był, jeśli tytuł to "Mapa, kolekcja samoprzedawniająca się"?
Ale miło że jednak rozumiesz że precyzja zegara ma coś do rzeczy przy dostępie równoległym.
Nie wiem, co to jest w tym kontekście "precyzja zegara", bo zegar odmierzający sekundy może być dużo bardziej precyzyjny od zegara odmierzającego milisekundy (w sensie odchylenia standardowego), może masz na myśli jego rozdzielczość? I nie, częstotliwość taktowania nie ma dużo do zrównoleglenia dostępu, czy mowa o sygnalizacji świetlnej na skrzyżowaniu (z wyłączeniem skrzyżowań indyjskich i chińskich ;-)), czy muteksie w najnowszym modelu procesora.
Implementacji czego? W
MemCachenie wnikam, bo nie mam takiej potrzeby, przyszło za darmo, spełnia wymagania odnośnie wydajności, wysyłam Twórcom buziaki i używam.No właśnie, nie rozumiesz a używasz.
Gdzie tu problem? Używasz telefonu, telewizora, windy, samolotu, laptopa znając tylko ogólne zasady ich działania, albo i to nie.
Za to mam wrażenie, że rozumiem Twój oryginalny, prowizoryczny pomysł lepiej od Ciebie. A zamiast przyznać rację, że są lepsze rozwiązania, wymyślasz użycie GPU, kompresję pamięci, przedefiniowujesz pojęcia i przede wszystkim nie odnosisz się do meritum problemu.
Skoro nie rozumiesz tego co znasz to jakim cudem wypowiadasz się na temat czegoś czego nie znasz i nie używasz?
Używając Twojego rozumowania, to żeby zdiagnozować katar, to muszę być lekarzem medycyny. Otóż jeśli braki w Twoim rozwiązaniu są oczywiste, to nawet taki laik jak ja, mający jedynie trzydzieści lat doświadczenia w programowaniu, jest w stanie je dojrzeć.
(..) mam na myśli że nie traktujesz
Nie wiemjako odpowiedzi. A to dużo tłumaczy ;)
?
Podsumowując - dyskusja z Tobą zaczęła być jałowa i najchętniej bym ją już skończył. Ponieważ jednak poniosły mnie emocje i odpisałem Ci, to niekulturalnie by było w tym momencie wyłączyć się z tego wątku. Zatem jeśli jeszcze napiszesz coś merytorycznego, jestem pierwszy do dalszej dyskusji.
ŁF napisał(a):
Pomyślałem trochę i wychodzi mi, że nie ma nic wspólnego (i to pomijając fakt, że nie ma czegoś takiego jak "wydajność zegara w CPU"). A skoro nie ma nic wspólnego, to po co w ogóle o tym napisałeś?
Pomyśl trochę dłużej, nie piszemy tutaj dysertacji więc czepianie się użycia wydajność zamiast prędkość pominę milczeniem. Jakbyś napisał o IPC to jeszcze, jeszcze. A co do zegara to dam ci taki mały tip: wiesz dlaczego niektóre stare gry mają zepsute mechaniki gdy są odpalane na Ghz CPU?
Kulturalni ludzie nie odpowiadają pytaniem na pytanie. Więc odpowiem na Twoje, chociaż zaczyna mi to przypominać przepychankę i przestało być merytoryczną rozmową - Ty nie odnosisz się do argumentów, ignorujesz pytania i zaczynasz być nieuprzejmy (vide "pomyśl trochę"). A więc do rzeczy: nie potrzebuję znać i rozumieć implementacji
MemoryCache, skoro interfejs spełnia wymagania, a implementacja jest wystarczająco szybka. Use case? Nie wiem, co to ma do rzeczy, ale odpowiem - u mnie kilkuminutowy lokalny cache circa tysiąca tłumaczeń. Natomiast Twój oryginalny pomysł, bez tych udziwnień, które dodałeś w trakcie rozmowy, jest w oczywisty dla mnie sposób niewydajny.
Kulturalni ludzie odpowiadają argumentami a nie bawią się w erystykę przechodzącą w ad personam. To że nie znasz a używasz to już ci napisałem, u mnie kilkuminutowy lokalny cache circa tysiąca tłumaczeń - świetnie, a teraz pobaw się w wyliczenie ile to zajmie pamięci przy moim rozwiązaniu przy założeniu zegara jednosekundowego.
Natomiast Twój oryginalny pomysł, bez tych udziwnień, które dodałeś w trakcie rozmowy, jest w oczywisty dla mnie sposób niewydajny.
Jw.
le nie odniosłeś się do nich, natomiast zacząłeś rzucać pomysłami typu milion "egzekutorów" z GPU.
Przypominam że to dot. dygresji na temat zapewnienia precyzyjnej inwalidacji cache z nanosekundową precyzją. Pamięć bywa zawodna, wiem.
Jak już wyżej napisałem, nie interesuje mnie, co siedzi w
MemoryCache, jeśli działa wydajnie. Ponownie nie odpowiedziałeś na zadane pytanie.
To skąd wiesz że nie siedzi w nim moje nieoptymalne rozwiązanie. Co do tego że nulle są zbędne - w takim razie uważasz że alokacja macierzy rzadkiej jest niewydajna i nie powinna być stosowana? W końcu większość ich elementów jest pusta.
I od tego czasu Rimac buduje samochody tylko dla siebie. Przecież nikt nie kupuje Bugatti (abstrahując od ich kosztu), w Twoim świecie każdy buduje samochód sam sobie.
W moim świecie handel dobrami ekskluzywnymi jest najprostszym sposobem transferu kapitału +/- prania brudnej forsy bez użerania z systemami skarbowymi różnych krajów. A Rimac dzięki temu że zaczął budować samochody tylko dla siebie to może brylować na salonach i fotografować się z elitami.
Ty tak serio?
I znowu nie odnosisz się do zadanych pytań, za to czepiasz się nieistotnych szczegółów. Zaczynam dochodzić do wniosku, że rozmowa z Tobą to faktyczna strata czasu. Widzisz, ja wiem, że mogę nie mieć racji, umiem używać merytorycznych argumentów i na takie odpowiadać, umiem przyznać rację i uczyć się na błędach. Ty byc może też to umiesz, ale jak na razie to co prezentujesz, to arogancja i brak kultury.
Ad personam jest słabe, postaraj się lepiej. Odwracanie argumentacji też ;)
Czy potem Twój dziadek sam mieszkał w tym domu, czy wykorzystała go ponownie jego rodzina? Bo idąc dalej Twoją myślą, każdy powinien budować taki dom dla siebie samodzielnie.
Specjalizacja jest dla insektów. Jesteś insektem?
Widzę, że albo nie załapałeś analogii, albo celowo ją zignorowałeś. W obu wypadkach
Niestety ale tak to już jest że obowiązek czytelnej komunikacji leży po stronie nadawcy, nie odbiorcy. No chyba że jest się propangandzistą.
Ciężko Ci powiedzieć, czy zarabiasz programowaniem na życie? oO
Ciężko bo mam jeszcze inne źródła dochodu? Ja uprawiam sztukę a życie toczy się swoim torem.
Czy według ci wszyscy juniorzy szpachlują zużyte oprogramowanie?
Nie, budują nowe osiedla z nadzieją że nikt się nie zorientuje przed czasem że nie ma nich nabywców.
Dużo rzeczy nie widzę według Ciebie, a jednak na pytania, które mogłyby mi pomóc zobaczyć, zwyczajnie nie odpowiadasz. Domyślam się, dlaczego tego nie robisz, ale nie chcę Cię obrażać.
Bo to w sumie jak w powiedzeniu "prowadził ślepy kulawego". Może prześmiewcze ale ja uważam że podróż jest ważniejsza od celu.
Słoma wychodzi Ci z butów :-)
Ja tam swoich korzeni się nie wstydzę
Nie o tym był wątek.
Zatem o czym był, jeśli tytuł to "Mapa, kolekcja samoprzedawniająca się"?
O tym:
Taka szybka zagwozdka - jak unieważnić z dowolnie małą precyzją czasową wiele elementów przy zagwarantowaniu jednoczesnego dostępu z wielu wątków?
Nie wiem, co to jest w tym kontekście "precyzja zegara", bo zegar odmierzający sekundy może być dużo bardziej precyzyjny od zegara odmierzającego milisekundy (w sensie odchylenia standardowego), może masz na myśli jego rozdzielczość?
Bingo! Czyli jednak coś wiesz o częstotliwości próbkowania, powoli już traciłem nadzieję :)
I nie, częstotliwość taktowania nie ma dużo do zrównoleglenia dostępu, czy mowa o sygnalizacji świetlnej na skrzyżowaniu (z wyłączeniem skrzyżowań indyjskich i chińskich ;-)), czy muteksie w najnowszym modelu procesora.
Do prawdziwego zrównoleglenia nie ale może wystarczy zwykła współbieżność?
Gdzie tu problem? Używasz telefonu, telewizora, windy, samolotu, laptopa znając tylko ogólne zasady ich działania, albo i to nie.
Tylko używając powyższych nie dywaguję o wyższości telefonu nad laptopem czy pagera nad telegrafem.
Używając Twojego rozumowania, to żeby zdiagnozować katar, to muszę być lekarzem medycyny. Otóż jeśli braki w Twoim rozwiązaniu są oczywiste, to nawet taki laik jak ja, mający jedynie trzydzieści lat doświadczenia w programowaniu, jest w stanie je dojrzeć.
Czyli chłopski rozum i argumentacja z autorytetu? Aż tak źle?
Podsumowując - dyskusja z Tobą zaczęła być jałowa i najchętniej bym ją już skończył. Ponieważ jednak poniosły mnie emocje i odpisałem Ci, to niekulturalnie by było w tym momencie wyłączyć się z tego wątku. Zatem jeśli jeszcze napiszesz coś merytorycznego, jestem pierwszy do dalszej dyskusji.
Przecież ja nie jestem twoim psychoterapeutą żebyś mi tłumaczył swój stan emocjonalny. Robisz albo nie, tu nie ma dyskusji.