Un resultado de medición de rendimiento bien conocido es que la función std::sort de la biblioteca estándar de C++ es mucho más rápida que la qsort equivalente de la biblioteca C. La mayoría de las personas, cuando escuchan esto por primera vez, afirman con vehemencia que esto no es posible, C es tan rápido (si no más rápido) que C++, que es un error de medición, que los algoritmos de clasificación utilizados son diferentes y así sucesivamente. Luego ejecutan el experimento y descubren que C++ es más rápido.
Comentarios
Es que std::sort también usa quicksort.
std::sort is most likely to use QuickSort, or at least a variation over QuickSort called IntroSort, which "degenerates" to HeapSort when the recursion goes too deep.
https://stackoverflow.com/questions/5038895/does-stdsort-implement-quicksort
Como cojones llega esta noticia a portada???
#2 Desmonta lo que dice para que la gente la vote errónea o irrelevante.
#2 cuál es el problema exactamente?
Ya pasó la época en que las noticias de programación eran para portada de menéame (y hace mucho). Y lo digo como programador, pero irrelevante.
Todos conocemos ya esto.
Voto cansina.
qsort y std:sort no utilizan la misma implementación del algoritmo. qsort no significa que sea quick sort.
#3 Que linka con -fpic?
Que mata moscas a cañonazos?
Que debería usar las mismas secuencias y no generarlas al azar cada vez?
Y solo me he mirado el código por encima.
#5 Es que esta además es errónea.
#7 más bien dice que a pesar de utilizar el mismo algoritmo la forma de llamar a la función de comparación y el funcionamiento del lenguaje en sí hace que en c la función de comparación se llame a través de una función de salto mientras que en c++ quede in-line.
#3 Es muy facil. Seguramente los datos que ha utilizado son números para hacer la comparación.
Cuando llamas a std:sort, es una funcion especializada para números y tiene optimizaciones. qsort no sabe del tipo de datos, porque es una implementación genérica. Por eso la std va mas rápido.
Se podría crear una libreria qsort_int solo para números enteros y no se notaría apenas diferencia. O probar a comparar con otros datos, como cadenas de vectores para comprobar que no deberia haber tanta diferencia.
El inline de las funciones puede influir algo, pero no demasiado. Porque un buen optimizador mete la función en la caché y la latencia es minima. A menos que lo ejecutes en modo depuración. Pero eso es otra historia.
#10 No debería haber mucha diferencia, a menos que la muestra de datos sea tan pequeña que el compilador la metió en la caché.
Entonces la latencia de acceder a los datos es comparable a la latencia de llamar a una función y se verán diferencias.
Pero en un caso mas realista, los datos están en la memoria principal o peor aún, distribuidos arbitrariamente como referencias de objetos o punteros, según la terminología de cada uno. Ahi no debería verse apenas diferencias.
#1
¿Y?
#8
Las secuencias de números son siempre las mismas ya que utiliza la misma semilla, 42.
Enlazar con -fPIC no tiene nada que ver con el rendimiento de estos tests.
Está claro que te has mirado el código por encima, tan por encima que ni te lo has mirado.
Pero qué pasa, ¿han venido todos los inútiles a votar negativo la noticia o qué?
#14 "Enlazar con -fPIC no tiene nada que ver con el rendimiento de estos tests"
Venga, hasta luego!
#16
Adiós, pero yo ya te lo dije antes y con razón