[SP-pm] ordenando arquivos.

[Thiago Yukio Kikuchi Oliveira]

>
>
> Se a função qsort da cstdlib ordena tudo em memória, você vai afirmar que
> "C não dá conta de fazer o sort pois faz tudo em memória."? Eu acredito que
> não, pois exatamente existe uma diferença entre o que é a linguagem (Perl) e
> as funções nativas (ou a biblioteca padrão que já vem com ela, se preferir
> assim).
>

Bem, isso é apenas uma questao de semântica. O importante é que concordamos
que a função sort do Perl (que é usada no script exemplo do André) carrega
tudo em memória! :)


>  Cara, eu gosto muito de C/C++... mas que deve-se tomar cuidado com
> afirmações deste tipo. A menos que você tenha alguma otimização
> especificamente em C/C++ (ou seja, saiba o que está fazendo), minah
> tendência é de duvidar um pouco dessas afirmações.
>
> Anyway, eu acho que um sorting de 1 TB está mais para IO-bound (ou memory
> bound) do que CPU-bound.
>

Concordo, ao final o gargalo sempre será o IO.


>
>

>> Por exemplo, estou utilizando o nsort que é feito em C e utiliza threads
>> para o sorting. Ele ordena 1TB em 33 minutos em um PC comum com multicore.
>>
>
> Você já testou isso, ou você está apenas repetindo o que está escrito no
> site do nsort?
>

Eu nunca testei com um arquivo de 1TB, e com certeza deve ser em um servidor
com HDDs de estado sólido.

Porem utilizo diariamente em arquivos de 15GB e dependendo da concorrencia
do IO (as vezes processo mais de uma corrida ao mesmo tempo) o nsort demora
de 10-20 minutos (o gnu sort demora mais de 1 hora). Além disso os HDDs são
de 7200 RPMs.



> No mais, isso não me diz - quase - nada... você não deu mais nenhuma
> informação sobre o ambiente. O que é um "PM comum com multicore"? São
> quantos cores? Qual o clock? Como é feito o IO? Local, rede? Se for em rede,
> qual o tipo de rede de interconexão? etc.
>

Bem, eu não tenho um benchmark para mostrar, e na verdade estou apenas
compartilhando ao que sinto na prática. Alem disso não trabalho pra a
Ordinal (empresa do nsort).

Mas no site deles tem um benchmark:
http://www.ordinal.com/white/whitepaper.html
-------------- Pr?xima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://mail.pm.org/pipermail/saopaulo-pm/attachments/20110726/38a4d7c3/attachment.html>