This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/gerrit-log@lists.osmocom.org/.
Hoernchen gerrit-no-reply at lists.osmocom.orgHoernchen has posted comments on this change. ( https://gerrit.osmocom.org/c/libosmocore/+/19372 )
Change subject: libomsocoding: NEON viterbi acceleration
......................................................................
Patch Set 1:
(5 comments)
https://gerrit.osmocom.org/c/libosmocore/+/19372/1//COMMIT_MSG
Commit Message:
https://gerrit.osmocom.org/c/libosmocore/+/19372/1//COMMIT_MSG@7
PS1, Line 7: libomsocoding
> Actually, it's not really libosmocoding. […]
I know, but the user of this code is libosmocoding, so this speds up libosmocoding, and therefore provides a more precise description of what now has neon support.
https://gerrit.osmocom.org/c/libosmocore/+/19372/1//COMMIT_MSG@14
PS1, Line 14: performance impact, so it needs to be enabled manually.
> I don't get what do you mean here. […]
Just like the special rach case neon can be bad, i.e. on a cortex a8 with in-order dual issue pipeline neon performance is abysmal.
https://gerrit.osmocom.org/c/libosmocore/+/19372/1//COMMIT_MSG@11
PS1, Line 11: Although autodetection according to __ARM_NEON would work because this
: is only defined if the fpu is neon neon-fp16 neon-vfpv3 eon-vfpv4
: neon-fp-armv8 crypto-neon-fp-armv8 doing that would lead to a unknown
: performance impact, so it needs to be enabled manually.
> I don't like this kind of approach. […]
SS(S)E/AVX is a cpu feature set that differs depending on bits provided by the cpu in a reg (and the knowledge that x64 means at least SSE2), NEON is a compile time target specific fpu and fp api configuration that is eternally set in stone at compile time. Detection would therefore happen at compile time.
Mixing neon and the fpu is bad, as is neon on a dual issue in-order cortex a8, so there are valid reason why it should not just be enabled.
That being said it's the users or devices fault, I'm fine with just turning it on.
https://gerrit.osmocom.org/c/libosmocore/+/19372/1/src/Makefile.am
File src/Makefile.am:
https://gerrit.osmocom.org/c/libosmocore/+/19372/1/src/Makefile.am@53
PS1, Line 53: no, could as well be vfp with neon
> Is it a comment or a part of AM_CFLAGS?
Just a reminder why adding explicit flags for neon instead or reyling upon the cflags provided by the build environment is a bad idea.
https://gerrit.osmocom.org/c/libosmocore/+/19372/1/src/conv_acc_neon_impl.h
File src/conv_acc_neon_impl.h:
https://gerrit.osmocom.org/c/libosmocore/+/19372/1/src/conv_acc_neon_impl.h@26
PS1, Line 26: /* Some distributions (notably Alpine Linux) for some strange reason
> In my linux (ArchLinux) __always_inline is defined in /usr/include/linux/stddef.h. […]
This is a copy from the sse files and I see no reason to question this or waste time tracking it down..
--
To view, visit https://gerrit.osmocom.org/c/libosmocore/+/19372
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: libosmocore
Gerrit-Branch: master
Gerrit-Change-Id: I58ff2cb4ce3514f43390ff0a2121f81e6a4983b5
Gerrit-Change-Number: 19372
Gerrit-PatchSet: 1
Gerrit-Owner: Hoernchen <ewild at sysmocom.de>
Gerrit-Reviewer: Hoernchen <ewild at sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: fixeria <vyanitskiy at sysmocom.de>
Gerrit-Reviewer: laforge <laforge at osmocom.org>
Gerrit-CC: pespin <pespin at sysmocom.de>
Gerrit-Comment-Date: Thu, 23 Jul 2020 10:43:40 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: fixeria <vyanitskiy at sysmocom.de>
Comment-In-Reply-To: pespin <pespin at sysmocom.de>
Comment-In-Reply-To: laforge <laforge at osmocom.org>
Gerrit-MessageType: comment
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/gerrit-log/attachments/20200723/c0c52694/attachment.htm>