Question related to the PHP engine and ArrayBuffers
Personne n'a encore pris cette issue.
Évaluation
- Difficulté
- 5/5
- Temps estimé
- Plus d'une semaine
- Accessibilité débutants
- 10/100
Piste de recherche
Il s’agit d’une question de performance sans réponse concernant le moteur PHP, le comportement du JIT basé sur LLVM, les ArrayBuffers et un éventuel RFC. Aucun fichier, test ou point d’entrée n’est indiqué ; commencez donc par rechercher le contexte de l’extension et des composants internes de PHP décrit dans l’issue. Le travail serait considéré comme terminé avec une évaluation des performances soutenue par un mainteneur et une proposition de RFC clairement délimitée.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Description
Hi; you don’t know me but I would like to say that it was a sad thing for the PHP community to learn that you moved over to LLVM; but I hope you are doing well. Over to my question:
I learned today some background from the PHP internals and the process leading up to PHP version 7, and also the JIT feature in 7.4:
That PHP’s JIT performance suffers because of extra CPU cache misses when JIT is enabled. Based on this, Dmitri did some great work on optimizing the memory requirements for important data structures in PHP 7.
This reduced the memory requirements of PHP and contributed to a ca 200% performance increase for PHP - mostly attributed to reduced memory bandwidth needs.
Question:
Can an extension like this ever hope to compete in performance, compared to a native op-code based approach to implementing array buffers? If so; I will consider adopting it into an RFC for PHP.
(Also because I am curious, but irrelevant for this extension; but I know you have an opinion: Could potentially re-implementing for example most of the \str* functions as pure PHP - reduce the amount of CPU cache space needed and lead to a faster language in general?)
- Langage dominant
- C
- Étoiles
- 43
- Forks
- 5
- Métriques de merge des PR
- Aucune PR mergée en 30 j
Préparer son environnement
Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Autres issues de nikic/buffer
-
Difficulté 3/5 1-2 jours Accessibilité débutants 35/100
-
Q: Project StatusOuverte
Difficulté 3/5 1-2 jours Accessibilité débutants 25/100
-
Difficulté 3/5 1-2 jours Accessibilité débutants 18/100
Toutes les issues de nikic/buffer
Issues similaires
-
Crash in mdns componentOuverte
Difficulté 1/5 Moins d'une heure Accessibilité débutants 75/100
openvehicles/Open-Vehicle-Monitoring-System-3#1575 ·
Les mainteneurs répondent en général sous 4 jours
-
cryptsetup
Difficulté 2/5 1-3 heures Accessibilité débutants 76/100
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 2/5 1-3 heures Accessibilité débutants 72/100
tursodatabase/libsql#2312 ·
Les mainteneurs répondent en général sous 11 jours
-
Please tag a commitOuverte
Difficulté 1/5 Moins d'une heure Accessibilité débutants 75/100
-
Rename "Receipt" to "Recipe"Ouverte
Difficulté 2/5 1-3 heures Accessibilité débutants 70/100