Hier ist ein Beispiel für einen Allokator, der auf allen Plattformen funktionieren sollte. Es basiert schamlos darauf:

https://sites.google.com/site/ruslancray/lab/bookshelf/interview/ci/low-level/write-an-aligned-malloc-free-function

Es gibt nicht viele Möglichkeiten, dies zu tun, und ähnlicher Code schwebt im Netz herum, sodass eine Erweiterung auf diese Weise wahrscheinlich in Ordnung ist. (Und außerdem wird kein Realloc implementiert.)

Wenn Sie diesen Code in numpy/core/include/numpy/ndarraytypes.h ablegen, sollte sichergestellt sein, dass frisch zugewiesene ndarrays auf allen Plattformen ordnungsgemäß ausgerichtet sind.

Dieser plattformunabhängige Code könnte möglicherweise unter POSIX durch posix_memalign() und unter Windows durch _aligned_malloc() . Es ist jedoch nicht möglich, posix_memalign() mit realloc() kombinieren. Daher ist es wahrscheinlich besser, es selbst zu implementieren.

#define NPY_MEMALIGN 32   /* 16 for SSE2, 32 for AVX, 64 for Xeon Phi */ 

static NPY_INLINE
void *PyArray_realloc(void *p, size_t n)
{
    void *p1, **p2, *base;
    size_t old_offs, offs = NPY_MEMALIGN - 1 + sizeof(void*);    
    if (NPY_UNLIKELY(p != NULL)) {
        base = *(((void**)p)-1);
        if (NPY_UNLIKELY((p1 = PyMem_Realloc(base,n+offs)) == NULL)) return NULL;
        if (NPY_LIKELY(p1 == base)) return p;
        p2 = (void**)(((Py_uintptr_t)(p1)+offs) & ~(NPY_MEMALIGN-1));
        old_offs = (size_t)((Py_uintptr_t)p - (Py_uintptr_t)base);
        memmove(p2,(char*)p1+old_offs,n);    
    } else {
        if (NPY_UNLIKELY((p1 = PyMem_Malloc(n + offs)) == NULL)) return NULL;
        p2 = (void**)(((Py_uintptr_t)(p1)+offs) & ~(NPY_MEMALIGN-1));   
    }
    *(p2-1) = p1;
    return (void*)p2;
}    

static NPY_INLINE
void *PyArray_malloc(size_t n)
{
    return PyArray_realloc(NULL, n);
}

static NPY_INLINE
void *PyArray_calloc(size_t n, size_t s)
{
    void *p;
    if (NPY_UNLIKELY((p = PyArray_realloc(NULL,n*s)) == NULL)) return NULL;
    memset(p, 0, n*s);
    return p;
}

static NPY_INLINE        
void PyArray_free(void *p)
{
    void *base = *(((void**)p)-1);
    PyMem_Free(base);
} 

Ich habe bereits einen Zweig, der einen ausgerichteten Allokator hinzufügt. Ich werde ihn ausgraben.

Wenn wir so etwas verwenden, werfen wir die Option weg, das Python-Tracemalloc-Framework und den spärlichen Speicher zu verwenden (es gibt kein align_calloc).
@njsmith Würdest du bereit sein, dich erneut mit Python-Entwicklern zu beschäftigen, um ihrem Slot noch einen weiteren Allokator hinzuzufügen, bevor 3.5 veröffentlicht wird? Sie haben Calloc bereits nur für uns hinzugefügt, wäre eine Schande, wenn wir es jetzt nicht verwenden könnten.

Vermutlich könnte man in den Kontextdaten von PyMemAllocatorEx in Ausrichtung übergeben? NumPy muss jedoch Python-Versionen ab 2.6 unterstützen, sodass das Problem in Python 3.5 möglicherweise nicht gelöst wird.

Ich denke, es ist eine gute Idee, sich vor 3.5 mit den Python-Entwicklern zu beschäftigen.
aber ich bin immer noch nicht davon überzeugt, dass wir einen guten Grund haben, ein ausgerichtetes zu verwenden
Allokator in naher Zukunft. Es kann unmöglich sein, dass struct {
double, double} erfordert tatsächlich eine bessere Ausrichtung als malloc auf win32 oder
SPARC, denn wenn das wahr wäre, würde nichts funktionieren.
Am 26. November 2014 um 09:10 Uhr schrieb "Julian Taylor" [email protected] :

Ich habe bereits einen Zweig, der einen ausgerichteten Allokator hinzufügt. Ich werde ihn ausgraben.

Wenn wir so etwas verwenden, werfen wir die Option zur Verwendung von Pythons weg
Tracemalloc-Framework und spärlicher Speicher (es gibt kein align_calloc).
@njsmith https://github.com/njsmith wären Sie bereit, sich zu engagieren
Python-Entwickler fügen erneut einen weiteren Allokator zu ihrem Slot hinzu, bevor 3.5 ist
veröffentlicht? Sie haben bereits Calloc nur für uns hinzugefügt, wäre eine Schande, wenn wir
konnte es jetzt nicht benutzen.

- -
Antworte direkt auf diese E-Mail oder sieh sie dir auf GitHub an
https://github.com/numpy/numpy/issues/5312#issuecomment -64534021.

Die Frage in Bezug auf f2py war, welche Ausrichtung Fortran benötigen würde, nicht die Mindestanforderung von C. Geschwindigkeit ist ebenfalls ein Problem. Sowohl die Indizierung als auch SIMD funktionieren besser, wenn die Daten richtig ausgerichtet sind.

Ein Grund für die Verwendung eines ausgerichteten Allokators könnte in der Tat die Geschwindigkeit und die Gewährleistung von SSE / AVX sein
Kompatibilität würde den numerischen Jitter beseitigen, der durch das Aufnehmen von Unterschieden entsteht
Codepfade für unterschiedlich ausgerichtete Daten.
.
f2py ist älter als der ISO C-Bindungsstandard in Fortran und so wie es ist
Works ist im Wesentlichen der De-facto-Standard für die Anbindung von Fortran
mit C, von allen ausgiebig genutzt. In Anbetracht dieser Erfahrung ist es
klar, dass die vom System malloc bereitgestellte Ausrichtung für die
Fortran-Compiler, die für uns in der Praxis wichtig sind.

Beachten Sie, dass Intel für AVX eine 32-Byte-Ausrichtung empfiehlt: https://software.intel.com/en-us/articles/practical-intel-avx-optimization-on-2nd-generation-intel-core-processors

@pitrou Für Xeon Phi wird eine 64-Byte-Ausrichtung empfohlen. Schauen Sie sich den Kommentar hinter der Definition von NPY_MEMALIGN in meinem Codebeispiel an.

Die Hauptkomplikation bei der Bereitstellung einer abgestimmten Zuordnung besteht darin, dass wir Geldautomaten können
entweder in die Tracemalloc-Infrastruktur einbinden oder die Zuordnung ausrichten,
Um dies zu beheben, ist eine gewisse Koordination mit CPython Upstream erforderlich (siehe

4663).

Am 5. Dezember 2014 um 16:44 Uhr schrieb "Sturla Molden" [email protected] :

@pitrou https://github.com/pitrou Und 64 Bit wird für Xeon empfohlen
Phi. Schauen Sie sich den Kommentar hinter der Definition von NPY_MEMALIGN in an
mein Codebeispiel.

- -
Antworte direkt auf diese E-Mail oder sieh sie dir auf GitHub an
https://github.com/numpy/numpy/issues/5312#issuecomment -65816753.

Das CPython-Problem befindet sich also unter http://bugs.python.org/issue18835.

Angesichts der Komplikationen mit realloc () ist es möglicherweise nicht realistisch zu erwarten, dass CPython dies im Zeitrahmen von 3.5 löst. Numpy sollte stattdessen möglicherweise einen eigenen ausgerichteten zugewiesenen Wrapper verwenden (der in der Lage sein sollte, auf die PyMem-API zurückzugreifen und trotzdem Tracemalloc zu nutzen).

Der Code für einen solchen Allokator ist oben enthalten. Ich verstehe das Argument von @juliantaylor nicht, aber er versteht das wahrscheinlich besser als ich.

Ich kann jedoch verstehen, was er mit Calloc meinte. Ein Calloc ist nicht einfach ein Malloc und ein Memset auf Null. Für ein Memset muss das Betriebssystem die Seiten abrufen, bevor sie benötigt werden. AFAIK gibt es kein PyMem_Calloc.

Tatsächlich hat CPython 3.5 PyMem_Calloc und Freunde.
Ich denke, @juliantaylor hat den Implementierungsfall der Verwendung von Betriebssystemfunktionen (posix_memalign usw.) in Betracht gezogen. Das klingt aber nicht nötig.

Übrigens, @sturlamolden , Ihr Snippet definiert PyArray_Malloc und Freunde neu, aber die Array-Zuweisung scheint PyDataMem_NEW zu verwenden. Verstehe ich etwas falsch?

Ein anderer Gedanke ist, dass eine ausgerichtete Zuordnung für kleine Arrays verschwenderisch sein kann. Vielleicht sollte es einen Schwellenwert geben, unter dem die Standardzuweisung verwendet wird?
Sollte die Ausrichtung auch konfigurierbar sein?

Die Allokatoren heißen in NumPy 1.9 PyArray_malloc und PyArray_free. In NumPy 1.10 hat sich viel geändert.

Bist du sicher? PyArray_NewFromDescr_int () ruft npy_alloc_cache () auf und npy_alloc_cache () ruft PyDataMem_NEW () auf.

Numpy verfügt über mehrere Zuordnungsschnittstellen, die nicht sehr offensichtlich sind
Namen. PyArray_malloc / free werden für "reguläre" Zuordnungen (z. B. Objekt) verwendet
Strukturen). Datenpuffer (ndarray -> Datenzeiger, temporäre Puffer im Inneren
ufuncs usw.) werden jedoch über PyDataMem_NEW zugewiesen.

Am Do, 15. Januar 2015 um 19:48 Uhr, Sturla Molden [email protected]
schrieb:

Die Allokatoren heißen in Numpy 1.9 PyArray_malloc und PyArray_free.

- -
Antworte direkt auf diese E-Mail oder sieh sie dir auf GitHub an
https://github.com/numpy/numpy/issues/5312#issuecomment -70149126.

Nathaniel J. Smith
Postdoktorand - Informatik - Universität von Edinburgh
http://vorpus.org

Es scheint, dass PyDataMem_NEW in NumPy 1.9 malloc aufruft.
https://github.com/numpy/numpy/blob/3975e095013119cfdbb9405ca95e6c723eb862d3/numpy/core/src/multiarray/alloc.c

@njsmith Ja, wir sollten eines Tages die Zuweisungsmakros rationalisieren ... Ich würde mit dem beginnen, mit dem Dimensionen für ndarray (IIRC) zugewiesen werden.

Ich habe PR # 5457 mit einem Patch erstellt. Feedback zum Ansatz wäre nett.

Soweit ich weiß, gibt es derzeit keinen Vorteil bei der Verwendung eines ausgerichteten
Allokator in numpy?

Am Freitag, den 16. Januar 2015 um 19:15 Uhr, Antoine Pitrou [email protected]
schrieb:

Ich habe PR # 5457 https://github.com/numpy/numpy/pull/5457 mit einem erstellt
Patch. Feedback zum Ansatz wäre nett.

- -
Antworte direkt auf diese E-Mail oder sieh sie dir auf GitHub an
https://github.com/numpy/numpy/issues/5312#issuecomment -70305997.

Nathaniel J. Smith
Postdoktorand - Informatik - Universität von Edinburgh
http://vorpus.org

Mit Numba haben wir festgestellt, dass AVX-Vektoranweisungen eine 32-Byte-Ausrichtung für eine optimale Leistung erfordern. Wenn Sie Numpy mit aktiviertem AVX kompilieren (erfordert bestimmte Compileroptionen, denke ich), sollte auch die Ausrichtung einen Unterschied machen.

Haben Sie aus Neugier irgendwelche realen Messungen? Ich frage dort b / c
sind so viele Faktoren, die in diese Dinge einfließen (unterschiedlicher Overhead / Geschwindigkeit
Kompromisse bei verschiedenen Arraygrößen, Details der Speicherzuordnungen - welche
verhalte mich auch bei verschiedenen Arraygrößen unterschiedlich - etc.), was mir schwer fällt
zu erraten, ob man am Ende eine End-to-End-Beschleunigung von 0,5% oder eine Beschleunigung von 50% erreicht.
End-to-End-Beschleunigung oder was.

Am Freitag, 16. Januar 2015, um 20:16 Uhr, Antoine Pitrou [email protected]
schrieb:

Mit Numba haben wir festgestellt, dass AVX-Vektoranweisungen 32 Byte erfordern
Ausrichtung für optimale Leistung. Wenn Sie Numpy mit aktiviertem AVX kompilieren
(erfordert bestimmte Compiler-Optionen, denke ich), Ausrichtung sollte a machen
Unterschied auch.

- -
Antworte direkt auf diese E-Mail oder sieh sie dir auf GitHub an
https://github.com/numpy/numpy/issues/5312#issuecomment -70315434.

Nathaniel J. Smith
Postdoktorand - Informatik - Universität von Edinburgh
http://vorpus.org

fwiw auf meinem i5-4210u Ich sehe keinen signifikanten Unterschied zwischen 16- und 32-Byte-ausgerichteten Daten in einem einfachen Load-Add-Store-Test. Die minimale Zykluszahl scheint um 5% niedriger zu sein, aber der Median und das 10. Perzentil sind identisch mit 1%

Ist das mit AVX?

@seibert hat einige AVX-Messungen mit Numba (dh Just-in-Time-Codegenerierung mit LLVM) mit Numpy-Arrays durchgeführt. Ich denke, er wird versuchen, sie erneut auszuführen, um genaue Zahlen zu erhalten :-)

Hier ist der Benchmark mit dem neuesten Numba-Master:

http://nbviewer.ipython.org/gist/seibert/6957baddc067140e55fe

Bei float32-Arrays (Größe = 10000), die eine a + b * fabs(a) -Operation ausführen, wird auf einer Intel Core i7-4820K-CPU mit 3,70 GHz (Ivy Bridge) ein Unterschied von 40% festgestellt.

(Wir sind ein wenig verwirrt darüber, dass der LLVM 3.5-Autovectorizer keinen Loop-Peeling-Code generiert, um Ausrichtungsprobleme zu beheben. Ich wäre nicht überrascht, wenn gcc oder clang dies korrigieren würden.)

Für andere Architekturen, auf die wir abzielen (wie AMD-APUs, die den HSA-Standard unterstützen), sind die Ausrichtungsanforderungen strenger. Die OpenCL-Entwickler schlagen vor, dass wir eine 256-Byte-Ausrichtung für Arrays haben, um die beste Leistung zu erzielen.

Ich weiß nicht, dass 40% eine übermäßige Strafe sind. Ich sehe Null auf einem i5-Haswell (der zugegebenermaßen eine wirklich schlechte avx-Leistung hat).
Könnte es sein, dass der JIT-Compiler zwei verschiedene Versionen der Schleife erstellt?
Haben Sie ein Profil auf Baugruppenebene (z. B. über Perf Record)?

Vielleicht tritt auch ein Turbo-Boost in die zweite Schleife ein, eine Deaktivierung oder Überwachung, die für PMU geeignet ist, könnte interessant sein

Da wir dieses System für das Benchmarking verwenden, haben wir TurboBoost im BIOS deaktiviert.

Die JIT wird nur einmal ausgeführt (sobald Numba eine Funktion für einen bestimmten Satz von Eingabetypen kompiliert hat, wird sie zwischengespeichert), und die JIT wird vor dem Benchmarking durch Zelle 6 im verknüpften Notizbuch ausgelöst.

Ich habe noch nie Perf Record verwendet, aber ich werde es mir ansehen. Wie haben Sie Ihre Benchmarks durchgeführt? (Ich würde tatsächlich erwarten, dass Haswell besser abschneidet als Ivy Bridge, wenn eine Fehlausrichtung eine ineffiziente Nutzung der verfügbaren L2-Cache-Bandbreite auslöst.)

Dieses Whitepaper von Intel enthält am Ende von Seite 6 weitere Informationen zum Ausrichtungsproblem:

https://software.intel.com/sites/default/files/m/d/4/1/d/8/Practical_Optimization_with_AVX.pdf

Die Verwendung von Intel AVX-Anweisungen für nicht ausgerichtete 32-Byte-Vektoren bedeutet, dass jede zweite Last über eine Cacheline-Aufteilung erfolgt, da die Cache-Zeile 64 Byte beträgt. Dies verdoppelt die Cache-Line-Split-Rate im Vergleich zu Intel SSE-Code, der 16-Byte-Vektoren verwendet. Eine hohe Aufteilungsrate der Cache-Zeilen in speicherintensivem Code führt höchstwahrscheinlich zu Leistungseinbußen. Aus diesem Grund wird dringend empfohlen, die Daten für die Verwendung mit Intel AVX auf 32 Byte auszurichten.

Haswell hat die doppelte L2-Cache-Bandbreite von Sandy / Ivy Bridge, daher ist es möglich, dass die Auswirkung von falsch ausgerichteten Arrays auf Haswell nicht signifikant ist ...

Mein einfacher Maßstab ist folgender:
https://gist.github.com/juliantaylor/68e578d140f427ed80bb
wäre interessant auf diesem i7 zu sehen

Ergebnisse auf einem Core i5-2500K (Sandy Bridge):
4644 6656 7704 10100

Bitte beachten Sie, dass ich zu Beginn des Benchmarks eine längere Aufwärmphase hinzufügen musste:

    for (i=0; i<10; i++)
        add(a, 1);

ist das ein Durchschnitt / Median / ...? das sieht ziemlich bedeutsam aus, scheint, dass Intel viel für den Haswell daran gearbeitet hat.

Es ist die nahezu stabile Ausgabe des Benchmarks nach einigen hundert Läufen in einer Schleife.

Ich habe eine gepackte SSE2-Implementierung hinzugefügt. Hier sind die Zahlen (i5-2500K):
4660 6492 7468 5108 10096
(32B ausgerichtetes AVX, 16B (nicht) ausgerichtetes AVX, 8B (nicht) ausgerichtetes AVX, ausgerichtetes SSE2, skalar)

Hier ist die aktualisierte Quelle: https://gist.github.com/pitrou/892219a7d4c6d37de201

Nahezu stabile Ausgabe eines Core i5-4200U (Laptop-Haswell-CPU):
4120 4152 4148 4260 7308

Zumindest hier ist falsch ausgerichtetes AVX nicht schlechter als SSE2 mit ähnlicher Ausrichtung.

Hier ist von meinem MBP (Quad-Core i7-3635QM, 2,4 GHz, Ivy Bridge):
5060 4932 5820 5704 5040

Ich musste avxintrin.h in immintrin.h ändern und mit Intel icc kompilieren, weil gcc 4.8.1 sich weigerte, den Code zu kompilieren (und so klirrte).

@sturlamolden , kann es sein, dass icc die Skalarschleife vektorisiert (das letzte Ergebnis in den Zahlen)?

(Beachten Sie, dass der Benchmark wahrscheinlich mehr Druck auf das Cache-Subsystem ausüben würde, wenn die Hinzufügung zwei separate Eingabearrays umfassen würde.)

Ich habe keine Ahnung.

@sturlamolden Dieser Code war sehr nützlich für die Schnittstelle mit einigen SSE2.

Ich hatte ein Problem unter Windows (alle Versionen von VC, einschließlich 2015), das diese Zeile nicht mag

memmove((void*)p2,p1+old_offs,n);    

da sie keine Zeigerarithmetik für void* . Als kurzfristige Lösung habe ich es auf char* , um zu rechnen. Dies ist wahrscheinlich nicht richtig - haben Sie eine bessere Idee, wie es unter Windows korrekt kompiliert werden kann?

Mein Fehler. Zeigerarithmetik auf void * ist illegal C. Casting to char * ist korrekt.
Das Codebeispiel wurde aktualisiert.

Wie erhalte ich 64-Byte-ausgerichtete Numpy-Arrays? Die 'ALIGNED'-Adressen von https://docs.scipy.org/doc/numpy-1.10.0/reference/generated/numpy.require.html scheinen unterschiedlich lang zu sein. Gibt es einen vom Benutzer konfigurierbaren Parameter für die Ausrichtungslänge?

Ich habe meinen eigenen (Python) ausgerichteten Allokator erstellt, der mit dem von Numpy bereitgestellten (nicht ausgerichteten) Speicher arbeitet.

import numpy as np

def empty_aligned(n, align):
    """                                                                                                                                     
    Get n bytes of memory wih alignment align.                                                                                              
    """

    a = np.empty(n + (align - 1), dtype=np.uint8)
    data_align = a.ctypes.data % align
    offset = 0 if data_align == 0 else (align - data_align)
    return a[offset : offset + n]


def test(n):
    for i in xrange(1, 1024):
        b = empty_aligned(n, i)

        try:
            assert b.ctypes.data % i == 0
            assert b.size == n
        except AssertionError:
            print i, b.ctypes.data % i, b.size

Vielleicht ist eine Python-Problemumgehung wie diese eine praktikable Lösung?

@eamartin Hier geht es um den internen C-Code des NumPy und den von f2py generierten Schnittstellencode zu Fortran (auch C-Code). Aus offensichtlichen Gründen kann die Implementierung von NumPy nicht von NumPy abhängen.

Sie können diesen Trick jedoch für Ihre Python-Projekte verwenden.

@sturlamolden : Es könnte @nachiket und anderen in einer ähnlichen Situation helfen.

@sturlamolden : Ich habe nicht genau genug gelesen, um zu erkennen, dass es sich um C-Interna handelt.

Das Anbieten besserer Ausrichtungsoptionen in den Python-Schnittstellen wäre jedoch hilfreich für die Entwicklung von Python-Schnittstellen zwischen Numpy und nativen Bibliotheken, für die Ausrichtungsanforderungen für Argumente gelten.

Ich bin nicht dagegen, bessere Ausrichtungsoptionen in den Python-Schnittstellen anzubieten 🙂

Die von mir vorgeschlagene "Python Aligned Allocator" -Lösung ist ein Hack. Ich denke, es wäre schön, die Ausrichtung in den Python-Schnittstellen anzubieten, aber der richtige Weg, dies zu tun, wäre, die Ausrichtung auf C-Ebene zu handhaben.

Diese Funktion wäre für mich sehr hilfreich. Ich verwende ein FPGA-Gerät (Altera A10GX), bei dem der DMA-Controller die Verwendung von 64-Byte-ausgerichteten Daten benötigt. Dies beschleunigt meinen Code um das 40-fache (!!!). Ich vermute, dass @nachiket das gleiche Problem hat wie ich. Ich habe etwas Ähnliches geschrieben wie @eamartin , aber das ist ein bisschen hacken.

Ich empfehle definitiv die 64-Byte-Ausrichtung:

1. Das ist die Cache-Zeilengröße
2. Es eignet sich für jede SIMD-Ausrichtung bis AVX512

Hier sind wir fast 5 Jahre später.

Irgendwelche Gedanken darüber, dies (insbesondere 64-Byte-Ausrichtung) zu einer Standardfunktion zu machen?

Dieser Cython-Code ist jetzt in NumPy. Dies ändert natürlich nichts an der Standardeinstellung.

Meine 2 Cent: Ein ausgerichteter Allokator würde bei der Schnittstelle mit Hardwaregeräten und Aufrufen auf Kernelebene helfen. Diese Schnittstellen können von der Ausrichtung der Puffer auf Seiten profitieren.

Durch das Zusammenführen von randomgen haben wir PyArray_realloc_aligned und Freunde gewonnen. Sollten wir diese Routinen in numpy/core/include ?

Das wäre sicherlich nützlich, @mattip. Wäre es möglich, auch von Python aus auf diese Funktionalität zuzugreifen?

Durch das Zusammenführen von randomgen haben wir PyArray_realloc_aligned und Freunde gewonnen. Sollten wir diese Routinen in numpy/core/include ?

Mein Code wurde abgezockt, oder? 😂

Es sieht so aus, als wäre ich kein Loger-Mitarbeiter für den Code, den ich für NumPy geschrieben habe 🧐:

https://github.com/numpy/numpy/blob/v1.17.2/numpy/_build_utils/src/apple_sgemv_fix.c
https://github.com/numpy/numpy/blob/v1.17.2/numpy/random/src/aligned_malloc/aligned_malloc.h

Vermutlich ging es irgendwann beim Übergang von randomgen zu numpy verloren. ich
Ich glaube, ich hatte eine Aufzeichnung, dass dies deine war.

Am Sonntag, 17. November 2019, 10:29 Uhr schrieb Sturla Molden [email protected] :

Es sieht so aus, als wäre ich kein Loger-Mitarbeiter für den Code, für den ich geschrieben habe
NumPy 🧐:

https://github.com/numpy/numpy/blob/v1.17.2/numpy/_build_utils/src/apple_sgemv_fix.c

https://github.com/numpy/numpy/blob/v1.17.2/numpy/random/src/aligned_malloc/aligned_malloc.h

- -
Sie erhalten dies, weil Sie kommentiert haben.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/numpy/numpy/issues/5312?email_source=notifications&email_token=ABKTSRLWKGXUFE4OK53SJMDQUEMJJA5CNFSM4AYDJQ42YY3PNVWWK3TUL52HS4DFVREVG3W3WUL3
oder abbestellen
https://github.com/notifications/unsubscribe-auth/ABKTSRM7IZIKPGKT4D2W4IDQUEMJJANCNFSM4AYDJQ4Q
.

Was war die ursprüngliche Quelle des Codes?

Der Link ist tot, wurde aber von einem ausgerichteten Malloc angepasst, der so aussah:

https://tianrunhe.wordpress.com/2012/04/23/aligned-malloc-in-c/

Es war ein Github-Posten aus Sturla. Es gab keine ursprüngliche Codedatei.

Am Sonntag, 17. November 2019, 12:04 Uhr schrieb Matti Picus [email protected] :

Was war die ursprüngliche Quelle des Codes?

- -
Sie erhalten dies, weil Sie kommentiert haben.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/numpy/numpy/issues/5312?
oder abbestellen
https://github.com/notifications/unsubscribe-auth/ABKTSRIVMQFEJ5EP227PXL3QUEXNDANCNFSM4AYDJQ4Q
.

https://github.com/numpy/numpy/issues/5312#issuecomment -64529217

Dies ist für das ausgerichtete Malloc.

Am Sonntag , 17. November 2019, 12:14 [email protected]
schrieb:

Es war ein Github-Posten aus Sturla. Es gab keine ursprüngliche Codedatei.

Am Sonntag, 17. November 2019, 12:04 Uhr schrieb Matti Picus [email protected] :

Was war die ursprüngliche Quelle des Codes?

- -
Sie erhalten dies, weil Sie kommentiert haben.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/numpy/numpy/issues/5312?
oder abbestellen
https://github.com/notifications/unsubscribe-auth/ABKTSRIVMQFEJ5EP227PXL3QUEXNDANCNFSM4AYDJQ4Q
.

Bekommt jeder, der 50 Codezeilen zu Numpy beiträgt, einen eigenen Copyright-Header? Ich könnte meine Beiträge durchgehen und sehen, ob welche zutreffen :-)

Es sieht so aus, als würde ich keinen Beitrag mehr für den Code leisten, den ich für NumPy geschrieben habe 🧐:

Du bist und wirst es immer sein :)

Bekommt jeder, der 50 Codezeilen zu Numpy beiträgt, einen eigenen Copyright-Header? Ich könnte meine Beiträge durchgehen und sehen, ob welche zutreffen :-)

Nee. Wir versuchen zu vermeiden, solche Dinge im Quellcode zu kodieren, da dies immer sehr unvollständig und schwer zu pflegen ist. Wir bitten die Leute, sich in THANKS.txt aufzulisten. Ich suche nach einer besseren Alternative dazu, da diese Datei häufig Zusammenführungskonflikte verursacht.