Sha512 - wydajność

Odpowiedz Nowy wątek
2020-02-19 12:18

Rejestracja: 1 rok temu

Ostatnio: 7 godzin temu

0

Potrzebuję w javie maksymalnie szybko przehashować wiele razy pewne dane.
Z javowych rozwiązań najszybsze jest Apache Commons Codec.
Czy ktoś zna jakąś inną opcję żeby to jeszcze przyspieszyć? Wykorzystanie jakiegoś innego języka na JVM może albo zawołanie jakiegoś C? Ktoś walczył z czymś takim kiedyś?

Pozostało 580 znaków

2020-02-19 13:11

Rejestracja: 3 lata temu

Ostatnio: 1 godzina temu

2

Robiłeś jakieś benchmarki? Na pewno hashowanie jest problemem? Jeśli Hashujesz stringi w Javie, to, niech mnie ktoś poprawi, trzeba je skonwertować do bajtów, i to może być bardziej kosztowne, niż sam hash.


Pozostało 580 znaków

2020-02-19 13:19

Rejestracja: 4 lata temu

Ostatnio: 15 godzin temu

1

Jak kolega wyżej wspomniał, zrób benchmark, spróbuj profilować aplikację żeby wychwycić co jest najwęższym gardłem.
Możesz też poeksperymentować z flagami:

-Xcomp
-Xbatch
-XX:CompileThreshold
Te flagi to akurat bardzo średni pomysł (to znaczy strata czasu na 99%). - jarekr000000 2020-02-19 13:47

Pozostało 580 znaków

2020-02-19 13:46
Moderator

Rejestracja: 15 lat temu

Ostatnio: 6 godzin temu

0

Zależy jak dużo masz tych danych. Wywołując kod natywny przez JNA/JNI należy liczyć się z narzutem rzędu 5-10 ns.
Ale kod natywny może być znacząco szybszy zwłaszcza w takich zadaniach jak hashowanie / szyfrowanie, które często mają wspomaganie sprzętowe, a nawet jeśli nie, to SSE/AVX potrafi robić niezłe cuda (a JVM cały czas nie umie w te klocki).

https://software.intel.com/en-us/articles/intel-sha-extensions

edytowany 3x, ostatnio: Krolik, 2020-02-19 13:49
Pokaż pozostałe 4 komentarze
GCC i LLVM są na podobnym poziomie. Ostatnio bawiłem się dużo optymalizacja kodu i za każdym razem udawało mi się pobić JVM 2x - 7x. - Krolik 2020-02-19 20:19
Z drugiej strony długo LLVM nie mogło dogonić GCC - na Phoronix są testy i w niektórych LLVM nadal sporo odstaje. Tak czy inaczej, kompilatory statyczne nie stoją w miejscu i moim zdaniem ostatnio bardziej uciekają JVM. - Krolik 2020-02-20 12:45
@Krolik - pomoc - właśnie pisze sobie w c (i w asm) klasycznego mandelbrota (rysowanie). TO co robi gcc w trybie -O3 na -march=native na ThreadRipperze (czyli mam sse do avx2) to powiedzmy nie jest zbyt yntelygentne. Dokładnie to samo co jvm kiedyś - czyli prawie żadne korzystanie z SIMD (instrukcje są wykorzystane i rejestry, ale prawie wszystkie operacje na scalar :/ ). TO żadna wektoryzacja. Masz coś więcej na temat - szukam co robie źle. - jarekr000000 2020-03-21 10:23
Bez kodu to raczej ciężko coś powiedzieć. Pamiętam, że w jednym przypadku zadziałało wydzielenie osobnego akumulatora tymczasowego i dodanie go na końcu do właściwego wyniku. Generalnie staraj się aby kod w pętli był jak najprostszy. Trzeba też uważać na aliasing i pointery. Aliasing może wprowadzać pozorne zależności, które uniemożliwiają zrównoleglenie. - Krolik 2020-03-21 12:37
@Krolik - problem był taki, że nie umiem w Makefile :-) zglosiłem i pomogli rozwiązać. Faktycznie GCC daje rade radę. https://4programmers.net/Forum/C_i_C++/337749-naiwnie_napisany_mandelbrot_w_asm_wychodzi_lepiej_od_gcc - jarekr000000 2020-03-22 16:35

Pozostało 580 znaków

2020-02-19 14:24

Rejestracja: 4 lata temu

Ostatnio: 3 godziny temu

Lokalizacja: Lublin

1
daniel_96 napisał(a):

wiele razy

Ile razy? Podejrzewam, że mowa tutaj o 10 - 100k iteracji na każdym z elementów?

Pozostało 580 znaków

2020-02-19 15:54

Rejestracja: 1 rok temu

Ostatnio: 7 godzin temu

0
qbns napisał(a):
daniel_96 napisał(a):

wiele razy

Ile razy? Podejrzewam, że mowa tutaj o 10 - 100k iteracji na każdym z elementów?

Dla jednego dużego requestu mowa o milionach iteracji

Pozostało 580 znaków

2020-02-19 16:00

Rejestracja: 4 lata temu

Ostatnio: 6 godzin temu

1

Jeśli naprawdę Ci na tym zależy i masz konkretny biznesowy problem do rozwiązania, to co powiesz na takie podejście:

  • postaw sobie dedykowany serwis do takiego haszowania i z dżawy wołaj ten serwis
  • skorzystaj z zabawek typu NVIDIA CUDA do obliczeń tych milionów haszy
edytowany 1x, ostatnio: yarel, 2020-02-19 16:00

Pozostało 580 znaków

2020-02-19 16:43

Rejestracja: 2 lata temu

Ostatnio: 2 dni temu

0
daniel_96 napisał(a):

Potrzebuję w javie maksymalnie szybko przehashować wiele razy pewne dane.
Z javowych rozwiązań najszybsze jest Apache Commons Codec.
Czy ktoś zna jakąś inną opcję żeby to jeszcze przyspieszyć? Wykorzystanie jakiegoś innego języka na JVM może albo zawołanie jakiegoś C? Ktoś walczył z czymś takim kiedyś?

jakiej jakości muszą być te hashe? Jakich kodeków z appache commons uzywałeś?

Pozostało 580 znaków

2020-02-20 13:25

Rejestracja: 1 rok temu

Ostatnio: 7 godzin temu

0
slsy napisał(a):
daniel_96 napisał(a):

Potrzebuję w javie maksymalnie szybko przehashować wiele razy pewne dane.
Z javowych rozwiązań najszybsze jest Apache Commons Codec.
Czy ktoś zna jakąś inną opcję żeby to jeszcze przyspieszyć? Wykorzystanie jakiegoś innego języka na JVM może albo zawołanie jakiegoś C? Ktoś walczył z czymś takim kiedyś?

jakiej jakości muszą być te hashe? Jakich kodeków z appache commons uzywałeś?

Nie rozumiem pytania o jakość.
Używam DigestUtils.sha512Hex
Jest to szybsze niż Guava i inne javowe opcje na hashowanie, ale nadal biznesowo za wolne

Pozostało 580 znaków

2020-02-20 13:31
Moderator

Rejestracja: 16 lat temu

Ostatnio: 3 godziny temu

2
  1. Aż boję się pytać, bo przewiduje że używacie tego SHA w jakiś bardzo zły sposób ;)
  2. Jak ma być szybko to musisz to robić przez jakąś natywną libkę, może polyglot z GraalVM ci pomoże w integracji.

Masz problem? Pisz na forum, nie do mnie. Nie masz problemów? Kup komputer...

Pozostało 580 znaków

2020-02-20 13:33

Rejestracja: 1 rok temu

Ostatnio: 7 godzin temu

0
Shalom napisał(a):
  1. Aż boję się pytać, bo przewiduje że używacie tego SHA w jakiś bardzo zły sposób ;)
  2. Jak ma być szybko to musisz to robić przez jakąś natywną libkę, może polyglot z GraalVM ci pomoże w integracji.

My używamy go bo takie ktoś z jednego ministerstwa wymyślił rozwiązanie

Pozostało 580 znaków

Odpowiedz

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0