> tu ne peux pas faire une BDD vraiment performante car ces interfaces sont trop haut niveau.
PostgreSQL (j'ai pas regardé pour Mysql) utilise que du read(), write(), seek(), flush(). Pas de truc "bizarre".
> Pour ca, il te faut un raw device, ou tu geres tout toi meme, tu sais a quoi ressemble le disque, etc... et tu as un controle total.
Il est reconnu que les systèmes de fichier sont maintenant suffisament performants pour se passer de ce type d'astuce. Il y a qu'Oracle pour faire de la "résistance" sur ce point (avec le désagrement d'allouer à l'avance de la place). De plus, il y a de plus en plus de disque (surement une majorité maintenant) qui ne fournissent pas les vrais valeurs de géométrie (entre autre pour éviter les problèmes avec certains bios). Et pour couroner le tout, ça devient rapidement du gros flan dès que tu utilises du raid ou lvm (c'est une couche supplémentaire mais les performances sont toujours là).
> Le probleme etant que si ils te filent le bas niveau, alors tu sais a quoi ressemble le HW.
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.
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.
Qu'il y ait des problèmes de brevet ou de secret industriel à exposer directement l'interface avec la carte, je comprend. Mais dire que pour des performances élevée il faut forcément attaquer le hard directement, là je comprend pas.
[^] # Re: Nouveaux drivers Nvidia disponibles
Posté par ptit_tux . En réponse à la dépêche Nouveaux pilotes Nvidia disponibles. Évalué à 4.
PostgreSQL (j'ai pas regardé pour Mysql) utilise que du read(), write(), seek(), flush(). Pas de truc "bizarre".
> Pour ca, il te faut un raw device, ou tu geres tout toi meme, tu sais a quoi ressemble le disque, etc... et tu as un controle total.
Il est reconnu que les systèmes de fichier sont maintenant suffisament performants pour se passer de ce type d'astuce. Il y a qu'Oracle pour faire de la "résistance" sur ce point (avec le désagrement d'allouer à l'avance de la place). De plus, il y a de plus en plus de disque (surement une majorité maintenant) qui ne fournissent pas les vrais valeurs de géométrie (entre autre pour éviter les problèmes avec certains bios). Et pour couroner le tout, ça devient rapidement du gros flan dès que tu utilises du raid ou lvm (c'est une couche supplémentaire mais les performances sont toujours là).
> Le probleme etant que si ils te filent le bas niveau, alors tu sais a quoi ressemble le HW.
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.
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.
Qu'il y ait des problèmes de brevet ou de secret industriel à exposer directement l'interface avec la carte, je comprend. Mais dire que pour des performances élevée il faut forcément attaquer le hard directement, là je comprend pas.