[aczutuse]

Czemu w #kotlin nie ma se wersji int 4 bajtowego tyku jes 32 bajtowy?
Po co pamięć zapychać?
#programowanie

[Pan_latarka]

@aczutuse: https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/-byte/

[eloar]

@aczutuse: https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/-int/ wg dokumentacji Int ma 32bit, czyli... 4 bajty

[ly000]

@aczutuse: co xd

[aczutuse]

@eloar: heh

[MilionoweMultikonto]

@aczutuse: u mnie każdy bajt ma gigabajt, kto bogatemu zabroni

[AntyKuc]

Czemu w #kotlin nie ma se wersji int 4 bajtowego tyku jes 32 bajtowy?

@aczutuse: W pracy też w taki sposób się komunikujesz?

[aczutuse]

@AntyKuc: czu wyzywa ech

[ponton]

@aczutuse: słaby bajt

[Krolik]

@eloar: A tak serio - nowe Kotlin / Java / Scala obsługują już liczby 128-bitowe natywnie? Czy dalej trzeba rzeźbić je z dwóch longów ręcznie albo używać paskudnego BigInteger? Dla kolegi pytam.

[eloar]

@Krolik: nie znajduję aby natywnie te języki obsługiwały liczby 128bit, co ma sens

[Krolik]

@eloar: brak obsługi 128 bitów w języku nie ma sensu kiedy procki normalnie takie liczby obsługują

[eloar]

kiedy procki normalnie takie liczby obsługują

@Krolik: normalnie? niektóre architektury obsługują liczby 128bit natywnie. Dlatego GCC wprowadziło __int128 i __float128 w 4.6 (dawno, marzec 2011). Dla języków takich jak Java dostępność tego jest zbyt wąska aby było zasadnym wprowadzenie tego typu do VM do ogólnego stosowania. Szczególnie w Kotlin przeznaczonym do pracy na platformach uruchamianych głównie na architekturze innej niż x8664

tu dużo wiedzy w temacie i w sumie to

[Krolik]

@eloar: x86/amd64 obsługuje, Apple Silicon (seria M) też, ARMy w smartfonach też dość nieźle choć wymagają zwykle dwóch instrukcji zamiast jednej, ale dla programisty wysokopoziomowego nie ma to znaczenia. Nawet dla procków, które jedynie dysponują arytmetyką 64-bitową, emulacja 128 bitów jest o rząd wielkości tańsza niż Javowe BigInteger. Nie wspomnę już o tym, że w niektórych nowoczesnych językach masz też typy 256 i 512-bitowe i też działają na wszystkim.

Niestety jeśli

[eloar]

ARMy w smartfonach też dość nieźle

@Krolik: z tego co znalazłem to nie tak dobrze z obsługą w ARM. Z reszta co to znaczy, że obsługują? jakie operacje?

Dlatego jeśli używasz Javy/Kotlin to skazujesz się na używanie wyłącznie tego, co pobłogosławili twórcy Javy. To nie jest język dla dorosłych ludzi tylko dzieci siedzących w piaskownicy

@Krolik: dlatego do tego są biblioteki jak bardzo potrzebujesz liczb 128b, choć nie wiem do

[Krolik]

dlatego do tego są biblioteki jak bardzo potrzebujesz liczb 128b, choć nie wiem do czego to potrzebne, że niezbędne wsparcie natywne.

@eloar: No biblioteką w Javie nie bardzo się da, bo Java nie umożliwia dodawania własnych typów prostych ani przeciążania operatorów. W Javie nie masz jak wydajnie reprezentować liczb 128 bitowych. Biblioteką co najwyżej zrobisz sobie równoważną arytmetykę na longach, ale.. w co włożysz wynik jak nie masz typu zmiennej zajmującego

[eloar]

Choćby mnożenie 64x64 -> 128:

@Krolik: a to obsługują mnożenie 64b a nie arytmetykę 128b w tym mnożenie 128b

Ludzie po prostu jadą wtedy z BigInteger

@Krolik: albo BitSet. Dalej nie wiem do czego chcesz powszechnie używać liczb 128b poza cryptologią, a do tego raczej nikt Java bezpośrednio nie używa

[Krolik]

@eloar: Ech, klasyczny argument "nie potrzebujecie tego". Nikt nie używa w Javie bo ich nie ma.

1. Apache Cassandra w pewnym momencie przeszła na 64-bitowe hashe, bo 128-bitowe były zbyt powolne przez narzut BigInteger. Ale gdyby 128-bitowe były dostępne natywnie, to używałaby 128-bitowych, bo dają mniej kolizji na dużych zbiorach danych.
2. Liczby 64-bitowe nie są wystarczające do zapisu np. czasu z precyzją mikrosekundową, bo brakuje zakresu.
3. Co do kryptografii,