[firebase-br] Curiosidade. Firebird 2.5 x 3.0

[Marcelo Fortes]

Oi Carlos desculpe acabei não lendo seu post e respondi o do Douglas
primeiro também ando com tempo curto para as listas infelizmente
<:-(.

Em 3 de março de 2010 09:27, Carlos H. Cantu <listas em warmboot.com.br> escreveu:
> Marcelo, sua resposta está cheia de erros, que vou tentar detalhar a
> seguir...

Vamos ver se consigo me fazer entender e se houver algo a retificar
terei prazer em reconhecer meu erro e corrigir.

>
> MF> Estranho, isso é o que a versão 3.0 "deveria" fazer!
>
> Não, a versão 3 terá suporte a SMP, mas isso não implica em dizer que
> uma única query poderá ser distribuída entre vários processadores.
> Isso também não significa que esse recurso não será implementado em
> alguma versão futura.
>
Exatamente esta primeira Implicação que me funde a cuca. Na minha
humilde opinião este nível de granularidade era o que deveria ser de
se esperar se for SMP, Salvo se por motivos de economia de recursos
não iniciar vários sub-processos dividindo-os entre X processadores
Vale lembrar a máxima que para um sistema SMP não basta simplesmente
por, por exemplo
Um algoritmo de Qicksort dentro do escopo de uma thread e pronto. tem
que se pensar até em como reimplementar o QuickSort.

> MF> uma coisa que o InterBase, desde a versão 7.0 faz muito bem diga-se de passagem.
> MF> REAL SMP!!!!
>
> Sugiro que vc leia os testes de TPC realizados pela IBSurgeon onde
> foram testados Yafill, InterBase e Firebird, não estaria falando isso.
>

Houve uma resposta ao primeiro teste TPC da IBSurgeon. Houve um
segundo teste mas estranhamente não foi muito divulgado, se não me
falha a memória no primeiro teste só aconteceu em máquinas
uniprocessadas, eu não recordo bem, poso estar errado aí outros
problemas foi o resultado de um PLAN de uma query tão ruim que
desistiram de testar com o InterBase. O Charlie Caro fez umas
ressalvas de como a Query estava montada. Que favorecia ao Firebird se
não me engano mandou para IBSurgeon um contorno destas Querys.
Lembrem-se que o IB ainda não era perfeito demorou um pouco para que o
SNP dele ficasse mais estável da 7.0 tiveram mais uns 3 sub-releases.

> MF> Não por suas qualidades ou seus pecados técnicos, nas por que não é
> MF> software livre "detalhe Firebird é Open Source mas não é Livre" mas
> MF> todo mundo faz questão de Esquecer esse detalhe.
>
> Agora estou surpreso, porque o Firebird não é livre?
>

Pelo mesmo motivo que eu expliquei ao Douglas. Ele é livre no contexto
tem o código fonte aberto e qualquer um pode baixar o binário e usar
sem pagar nada se não quiser, porém em uma versão de uma de suas suas
licenças ela dá abertura para que, por exemplo, Eu usar parte do seu
código fonte num projeto meu e não retornar nada para a comunidade
Firebird.

Tem que se ter uma idéia clara do que é uma licença "FreeSoftware" e
uma Licença "OpenSource".  Você mesmo Já perguntou para um Engenheiro
de Software do Firebird se pela natureza OpenSource do Firebird Alguém
da Borland pudesse usar parte do código do Firebird no InterBase,
compilar embalar e vender, (E podia!!! a licença deixava isso
passar!!!! não era Free era Open!!!). O desenvolvedor respondeu "é uma
coisa com a qual temos que conviver".

> MF> Bem Super server se dá melhor com multi processamento porquê, cada
> MF> instância de conexão com o banco é criado um novo cache e uma nova
> MF> instância para manipular a nmemória e os registros de base de dados,
>
> Isso quem faz é o Classic, não o SuperServer.
>

Desculpe foi um erro meu aí troquei as bolas como comentei antes.

> MF> obviamente se a máquina tiver mais de um processador ou Core "núucleo
> MF> de processamento", ela vai tentar via sistema operacional distribuir
> MF> cada um dessses processo + ou - independentemente tirando proveito
> MF> destes "X" processadores ou núcleos, porém é um alternativa não
> MF> escalável pois cada conexão vai comer "X" de memória para cada
> MF> conexão.
>
> Não sei exatamente qual o seu parâmetro para considerar algo escalável
> ou não, mas na grande maioria dos grandes casos de uso do Firebird,
> incluindo aí bases muito grandes e centenas de conexões simultâneas,
> usam o Classic.
>

Verdade mas ao custo de agregar muito mais hardware (memória) para
suportar a quantidade de conexões. Escalabilidade pode se referir a
várias situações, no caso me refiro (Quantidade de conexões X Espaço
de memória física )

> MF> A idéia do pessoal do Firebird é comparar as performances das
> MF> distintas arquiteturas para ver quem se sobressai melhor. Coisa que na
> MF> minha humilde opinião é uma perda de tempo, deveria-se sepultar de vez
> MF> a arquitetura ClassicServer e apagar todo este trambolho dos fontes e
> MF> fazer todas as rotinas pertinentes SMP usando um layer posix para as
> MF> arquiteturas Unix.
>
> A idéia é que as diferentes arquiteturas deixem de existir no futuro,
> unificando tudo em uma só. Se você reparar bem, é isso que vem
> acontecendo. O SuperClassic é um híbrido entre a Classic e a
> SuperServer, enquanto no FB 3, teremos um modelo onde todas as
> vantages da SuperClassic serão fundidas com o cache compartilhado
> (que atualmente só existe no SuperServer).

Isso dá uma abertura para um ótimo debate, senão vejamos, todas as
arquiteturas deixarem de existir no futuro você disse e logo após
unificando tudo numa só, sua um pouco contraditório Carlos!

E logo após você diz que no FB 3 teremos um modelo com as vantagens do
Super Classic, Mas que vantagens são essas cristo? se o FB 3 vai ser
um aprimoramento do Super Server ?
A não ser que na versão 3.0 o modelo  OSRI original do InterBase da
época do Jim Starkey venha a ser refeita algo assim como o Vulcan e
seus módulos em forma de .dlls

Então tente me entender aqui para ver se chegamos a um denominador comum.

Se cada módulo rodar separadamente como na arquitetura OSRI,  e contar
com a arquitetura de cada nova conexão, ser um novo processo e não uma
nova thread como no SuperServer e  ter um cache compartilhado Como no
SuperClassic e cada instância de conexão e interface ao banco Banco
for SMP. Então eu entendi o que vai ser o FB 3.0. No que tange a ter
todas as tecnologias numa só.

Mas não é exatamente isso que se lê no Roadmap de desenvolvimento, lá
se fala de uma clara evolução natural do SuperServer e torná-lo SMP
tirando proveito dor recursos que o sistema operacional oferece para
esse tipo de tarefa.
(Para quem está acompanhando a conversa e tem dúvidas sobre Multi
Processamento Simétrico este texto ajuda a elucidar :
http://pt.wikipedia.org/wiki/Symmetric_multiprocessing)

Eu imagino que a idéia na cabeça dos desenvolvedores seja comparar no
futuro as duas arquiteturas 2.5 e 3.0 ver qual se sobressai em
performance em ambientes multi-processados, quem economiza mais
recursos além do quê, performance não é tudo ainda que o foco seja
tirar proveito das arquiteturas atuais de processadores e sistemas
operacionais que tirem proveito deles.


>
> Firebird não roda só em Unix, vc sabe disso.
>

Sei muito bem. O problema que me refiro é a restrição imposta.
Compreendo que o time de desenvolvedores é menor, faltam recursos de
se ter hardware rodando outros sabores de Unix e tempo para portar mas
o que eu quero dizer aí é que o firebird peca por excluir outros U*IX
Livres no mínimo.
Conversando com o Jim Starkey uma vez ele falou que um dos objetivos
do Vulcan era a independência de Compilador C++ evitar usar recursos
muitos esotéricos suportados somente pelo GCC/G++ e MSVCC para não
esbarrarem com problemas com cpompiladores de outros sistemas Ex: Sun
Forte C++ e não ter dor de cabeça para portar pro Solaris em
arquitetura SPARC

> MF> Mas não as mentes iluminadas do leste europeu preferem remover a
> MF> compatibilidade com arquiteturas já comprovadas como UnixWare,
> MF> (provavelmente só, por que, é da SCO) mas manter HP-UX somente das
> MF> última versão por que somente esta última é Posix SMP compatível.
>
> O projeto não tem intenção alguma de suportar uma arquitetura em
> detrimento de outras. Acontece que, como você deve saber, ele depende
> de voluntários. Se houver algum voluntário que precise de suporte a
> UnixWare e quiser ser responsável por gerar as builds e fazer as
> adaptações necessárias no código, será bem vindo.
>

Não carlos, as partes dos fontes referente a build nessa e outras
arquiteturas simplesmente foram removidas !!!

> Se existe versões para Solaris, MacOS, etc. é porque alguém precisa
> delas, e se dispôs a fazer as builds e adaptações necessárias.
>
> Dizer que o FB deveria suportar isso ou aquilo é fácil, agora colocar
> a mão no código e fazer com que isso aconteça, já é uma outra
> história, não? Afinal, uma das premissas do Open Source é que
> "qualquer um pode baixar os fontes e altera-lo da forma que quiser".

Verdade e só que você encontra muita resistência em encontrar um
conjunto de makefiles que me ajudem a dar um build digamos no UnixWare
já que o citamos aí, mesmo se eu pegar os headerfiles e o resto do
fonte necessário para dar um build do Firebird no Unixware
Além do quê, Carlos Henrique NÃO é simples questão de dizer que
deveria suportar isso ou aquilo o problema é que havia esse suporte
estava lá e simplesmente foi removido e é quase impossível
reintroduzir esse port denovo infelizmente :-(  entendeu o que eu quis
dizer?

A resistência eu penso é a manutenibilidade da coisa. Por exemplo o
Firebird da suporte para HP-UX mas somente uma das últimas versões do
HP-UX usa threads padrão posix (Antes a HP usava um sistema de threads
proprietária pro Unix dela) então no source tree do firebird vc
encontra X interfaces de threads, Posix, Windows, e X implementações
para outros sistemas que diferem. É meio bagunçado deveria haver uma
interface única para caa implementação acredito que as coisas estejam
indo para este rumo eu vi o que o Dmitry Yemanov separou muitas
chamadas de API em subdiretórios pelo menos eram dois umm Windows e
Outro Unix

Desculpe a pressa ou algum erro de grafia espero que tenha elucidado
meu ponto de vista, se houver algo que não ficou claro fico feliz em
responder.

Obrigado por responder ao meu post ;-) estamos aí.

Força, Sucesso e Felicidade!!!

Marcelo Fortes.
> []s
> Carlos H. Cantu
> www.FireBase.com.br - www.firebirdnews.org
> www.warmboot.com.br - blog.firebase.com.br
>
>
> ______________________________________________
> FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
> Para saber como gerenciar/excluir seu cadastro na lista, use: http://www.firebase.com.br/fb/artigo.php?id=1107
> Para consultar mensagens antigas: http://firebase.com.br/pesquisa
>