[meloon]

Mirki mam małą zagwozdkę jak obsłużyć strumień UDP który odbieram.

Mam sobie linię:

data, addr = self.sock.recvfrom(65000)

i odbieram z niej 1444 bajty takie jak niżej:
'\x00\x00\x00\x00\x01\x00\x00\x00\xe4\x08\x00\x00\t\x00\x00\x00\xbc\x02\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x07\x1b\x80"\x0f\xfb\x0f\xff\x0c\x04\n\x18\xf0\xc0\xf8\x10\x00...`
Mam w jednym stringu cały strumień 8bitowych charów a chciałbym to przekonwertować do tablicy, potem muszę te dane łączyć bajtami w uint16 i dalej przetwarzać. Nie ukrywam że zależy mi na efektywności czasowej, bo ramki przychodzą dość często. Macie jakiś pomysł na to?

#python #programowanie #programista15k

[D.....n]

@meloon:

1. > Nie ukrywam że zależy mi na efektywności czasowej,
2. Pisz w pythonie
3. Brak profitu

A serio to nie ogarniam. Po co robić z tego uint8, żeby potem zrobić uint16? Jakie ma być docelowe endianness? O co chodzi? Tak wiele pytań...

[meloon]

@Demolicjon: Efektywny czasowo w miarę możliwości, ręczne wyciąganie danych z 1444 bajtów na RPi 3b+ zabiera jakieś 8ms, muszę zejść niżej. Dane docelowo na wyjściu mają być tablicą uint16, pisałem dość skrótowo o uint8, mając na myśli bezpośrednie przetworzenie danych ze stringa, jak widać są one 8-bitowe. W strumieniu są dane pomiarowe z ADC wysyłane przez jakiś moduł FPGA.

[SharkyShark]

chcesz szybciej to przetwarzać to przejdź na c bądź c++

[meloon]

@SharkyShark: Spotkałem w Pythonie różne podejścia do obliczeń na tablicach które dają różnicę wymaganego czasu i myślałem, że coś tutaj uda się urwać. Tak już odchodząc od tematu optymalizacji, jak byście to przetworzyli?

[D.....n]

@meloon: Ale jakie ręczne wyciąganie danych? Ja nic nie rozumiem. Określ dokładnie co jest celem, bo na razie to mogę co najwyżej z fusów powróżyć.

[D.....n]

@meloon:

jak byście to przetworzyli?

const uint16_t *ptr = reinterpret_cast(buf);

[hitherto]

@meloon: czemu nie napisałeś jak to robisz że jest za wolno?

struct.unpack ? czy jakąś pętlą? szybciej niż unpackiem raczej nie zejdziesz.

[meloon]

@Demolicjon: @hitherto:
https://pastebin.com/Z7M4bG4P

Jak widać wolniej pewnie tego się nie dało przetworzyć.

[D.....n]

@meloon: Napisz prozą czego potrzebujesz, bo ten snippet jest mało sensowny:
- Bierzesz parami sąsiadujące bajty i masz overlap na tych parach.
- Z tego samego powodu przetwarzasz tylko połowę bufora.
- DataTransforms() jest zamotany - jak dwubajt jest większy niż 4096 (w ogóle dlaczego to jest napisane 0x800 * 2? żeby trudniej było się przedrzeć przez to?), no nagle jakieś odejmowanie od górnego limitu uint16?

[hitherto]

@meloon: o panie :-) to spokojnie unpack ze skompilowanym formatem przemieli Ci o rząd wielkości szybciej, jeśli nadal za wolno to ewentualnie do przetestowania xdrlib - nie wiem czy jest szybsze, dalej jest cython (choć nie wiem czy tu dużo zmieni) i języki kompilowane

[meloon]

@hitherto: @Demolicjon: @hitherto: Dane pochodzą z 12-bitowego ADC, niestety początek ramki ma pola o wartościach >4095, sam nie wiem dlaczego. Pythona prawie nie znam prawdę mówiąc, ale unpack już robi wystarczającą robotę, więc dziękuje za naprowadzenie takiego nooba jak ja ( ͡° ͜ʖ ͡°)