PostgreSQL (j'ai pas regardé pour Mysql) utilise que du read(), write(), seek(), flush(). Pas de truc "bizarre".
Va jeter un oeil a http://www.tpc.org(...) et regardes combien de tests sont fait avec PostgreSQL, je t'evites de chercher: 0
PostgreSQL c'est bien pour les petites/moyennes BDD, ca tient pas la route pour les trucs haute-perfs, les trucs ou Oracle se promene.
Si je fait l'analogie avec postgresql, l'interface c'est SQL. Ben quand t'as SQL, il y a 50 façons de faire un SGBD et aussi des très performants.
Eh non.
Si tu as un acces plus bas niveau que SQL a la BDD, tu peux ecrire ton appli de maniere a ce qu'elle soit plus rapide, tout simplement car tu n'as plus a passer par les checks generalistes de cette couche haute, faite pour gerer les 345 cas dont tu te fous vu que tu n'es que dans 1 cas precis.
De plus, je ne vois pas pourquoi tu insistes sur le fait d'avoir les "détails" de la carte pour avoir de bonnes performances et/ou qu'un "language" de haut niveau est incompatible avec des bonnes performances. Lorsqu'un développeur fait un jeu sous windows, il ne s'occupe pas (du moins plus) des détails de la carte. Il passe par DirectX et son jeu tourne très vite ou pratiquement aussi vite que s'il l'avait fait spécifiquement pour une carte.
Parce qu'une API de haut niveau fait des choix afin de simplifier la programmation, choix qui se repercutent sur les perfs.
Quand t'as une fonction pour afficher des polygones, cette fonction n'a aucune idee des particularites de ce que tu lui donnes vu que c'est une fonction generaliste, donc elle va faire des tests sur ton polygone --> cycles cpus perdus, si t'as une API plus bas niveau, tu te fais chier a coder, mais t'evites ces tests car tu sais exactement ce qu'il faut faire --> pas de cycles cpu perdus
C'est EVIDENT qu'un API haut niveau est plus lent qu'un API bas niveau.
[^] # Re: Nouveaux drivers Nvidia disponibles
Posté par pasBill pasGates . En réponse à la dépêche Nouveaux pilotes Nvidia disponibles. Évalué à 2.
Va jeter un oeil a http://www.tpc.org(...) et regardes combien de tests sont fait avec PostgreSQL, je t'evites de chercher: 0
PostgreSQL c'est bien pour les petites/moyennes BDD, ca tient pas la route pour les trucs haute-perfs, les trucs ou Oracle se promene.
Si je fait l'analogie avec postgresql, l'interface c'est SQL. Ben quand t'as SQL, il y a 50 façons de faire un SGBD et aussi des très performants.
Eh non.
Si tu as un acces plus bas niveau que SQL a la BDD, tu peux ecrire ton appli de maniere a ce qu'elle soit plus rapide, tout simplement car tu n'as plus a passer par les checks generalistes de cette couche haute, faite pour gerer les 345 cas dont tu te fous vu que tu n'es que dans 1 cas precis.
De plus, je ne vois pas pourquoi tu insistes sur le fait d'avoir les "détails" de la carte pour avoir de bonnes performances et/ou qu'un "language" de haut niveau est incompatible avec des bonnes performances. Lorsqu'un développeur fait un jeu sous windows, il ne s'occupe pas (du moins plus) des détails de la carte. Il passe par DirectX et son jeu tourne très vite ou pratiquement aussi vite que s'il l'avait fait spécifiquement pour une carte.
Parce qu'une API de haut niveau fait des choix afin de simplifier la programmation, choix qui se repercutent sur les perfs.
Quand t'as une fonction pour afficher des polygones, cette fonction n'a aucune idee des particularites de ce que tu lui donnes vu que c'est une fonction generaliste, donc elle va faire des tests sur ton polygone --> cycles cpus perdus, si t'as une API plus bas niveau, tu te fais chier a coder, mais t'evites ces tests car tu sais exactement ce qu'il faut faire --> pas de cycles cpu perdus
C'est EVIDENT qu'un API haut niveau est plus lent qu'un API bas niveau.