Comments (7)
@shibatch, I don't think it is a good idea to merge all this files just before the release.
On the other end, I am happy for you to change the names from helper
to veal
, a name change is no problem.
If I may, I also have a couple of considerations.
- I think that the fact that the architectural name of the vector extension is in the current "helper" names helps in understanding what instruction set you are using in the code, so I'd avoid replacing it with the
arch/bitwidth
pair and leave them in the formvealavx, vealavx512, vealadvsim
and so on (veal
orhelper
, whatever you choose). - unifying things is usually good, so I am happy for you to merge
helpersse2
andhelperavx2_128
into one single file. My concern is: will this new file work on any 128-bit wide vector extension from intel? What if you mix avx2 and sse2 intrinsic in there an someone need to run sse2 only code? Or am I missing something? - About merging
helperadvsimd
andhelperneon32
: they come from different architectures.
Advanced SIMD is the vector extension of the Armv8 architecture. The Armv8 architecture has 2 execution modes: AArch32 and AArch64. In AArch32 mode the hardware is able to execute binaries for the previous architecture, the Armv7 architecture. The registers and the instructions of Armv8 are an extension of the Armv7 capabilities, in a 64-bit address space when the execution mode is AArch64.
AArch64 Advanced SIMD has 128-bit wide vector registers, but is operates also in double precision and has a richer FP instruction set. For example, in AArch64 it is possible to compute the square root in one instruction (both in single and double precision), while in NEON, which is the vector extension of Armv7, it can be done only with an iterative algorithm, and in single precision, as the vector are 64 bits wide.
Now, merging this two helper files would result in a bunch of#ifdef
s to test whether or not the AArch64 Advanced SIMD on 64-bit registers are executed or the Armv7 one are. It is doable in principle, but I'd avoid doing it now just before the release.
from sleef.
veal means meat of calves
As a non-meat eater myself, I'm not a fan of the usage of this word actually 😅
Why not just use a more explicit word like vector
(or even a short version vec
) instead of an acronym that nobody will understand at a first sight?
from sleef.
As a non-meat eater myself, I'm not a fan of the usage of this word actually 😅
I am now gradually understanding your personality. 😆
Do you mean that the filename will be like vectorintel_128.h?
I think vector is still too generic.
I would like to hear other people's opinions.
from sleef.
Do you mean that the filename will be like vectorintel_128.h?
vector_avx2.h
... or sleef_vec_avx2.h
if you fear a clashing problem with includes...
also not sure about this idea of using arch/bit, while avx2
is more familiar to how C++ compiler are typically configured via command line switch, so it rings a bell more easily when looking at the code.
from sleef.
The problem for using the name avx2 is that that file would contain the functions for other extensions.
If we divide the helper files in such a way that each file corresponds to a combination of a bit length and an extension, there would be many helper files and thus this would be bug-prone.
from sleef.
We never adopted this naming conventions for the header files. @shibatch shall we close this issue?
from sleef.
We never adopted this naming conventions for the header files. @shibatch shall we close this issue?
Yes.
from sleef.
Related Issues (20)
- Failures on various archs for gcc 12 HOT 2
- Failures for s390x VXE2 with qemu HOT 2
- Some tests fail on AArch64 with LLVM 17 HOT 1
- Deprecated usage of MD5 API
- Fix RVV inline header generation HOT 3
- Test more OS-es in Github Actions HOT 7
- Add GNU make as potential generator in CI
- Please, create tag release HOT 3
- dft test gets stuck during initialisation when hardware vector length is very long HOT 2
- Failure on ppc64 when cross compiled with gcc-11 toolchain
- Inaccuracy for f32 erf on non-FMA instruction set
- New test failures in 3.6 HOT 7
- F64 exp returns infinity slightly too soon
- RISC-V architecture missing on https://sleef.org/ HOT 1
- Clang on Windows and GNU ABI
- RISC-V: exploit `-mrvv-vector-bits=zvl` when used HOT 1
- Missing unversioned symbolic link for GNUABI version in 3.6 HOT 3
- A few API functions were (accidentally?) removed in 3.6 HOT 11
- Integrate ARM-software/optimized-routines into sleef? HOT 2
- Improve portability of libm and quad testers
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from sleef.