Avaliação do Tópico:
  • 0 votos - 0 Média
  • 1
  • 2
  • 3
  • 4
  • 5
duvidas em C
#11
vou tentar postar aqui mesmo e foda-se.



DISCLAIMER: não sou programador... então é 100% de certeza que o código está um lixo kkkk



o código está em https://paste.ofcode.org/35pjwe4pUbSaMWi2q3DZ47r



o gargalo começa na linha 33. Esse loop gira kk vezes, onde kk é o indice do vetor tempo. Por exemplo: se eu tenho um vetor de 10s, com sample rate de 100hz, então o vetor tem kk vai de 0 até 10/0.01 - 1. Normalmente eu trabalho com vetores de 10 a 180s. E ainda concateno vários vetores de tempo nesse tamanho aí. É ponto pra cacete pra um loop.



Enfim, se só rodasse uma vez o loop não era problema. O negócio fica lento um pouco mais pra baixo, na linha 38. Esse for loop é feito com o número de parâmetros a serem identificados. Esse número varia de 7 a 30. E aí meu sistema dinâmico tem suas equações de estado "calculadas" na função gradrespH. O problema maior ainda é que dentro dessa função gradrespH, é feito outro loop de kk vezes do vetor tempo.



Isso é necessário pq estou avaliando a sensibilidade da dinâmica do sistema para cada parâmetro a ser estimado. Eu já vi esse método rodando em C e era ridículo de rápido.



o código do gradresph está em https://paste.ofcode.org/QqkNPpAanP4Vtev3BTQGEW





Em resumo... tem que começar a mexer no gradresph. Se eu já conseguir acelerar esse for loop usando jit, numba ou qualquer outro artíficio maluco do numpy já vai ajudar. Se alguém puder dar uma luz...


[00:20] <rav3n> #hnet rlz pq vai de pasta de dente passada no saco ao determinismo q o machado de assis quebrou em umas 20 linhas de chat



http://internetisseriousbusiness.com/
Responder
#12
Única coisa que sei com C é /format c:/ espero ter ajudado.
Responder
#13
como eu n entendo mt bem o que faz, nao dá pra fazer o principal, q seria tentar algo realmente diferente (tipo preprocessar igual eu falei antes).



em todo caso, tu pode tentar ir otimizando aos poucos. se eu n tiver enganado, xrange é 1 pouco mais lento q range; tu copia o param pra paramp em toda iteraçao mas só edita o paramp no indice ip, entao nem precisava ter tantas copias do paramp.
Responder
#14
Do pouco que conheço de python 2, acredito que o xrange seja mais rápido que o range, porque ele cria um lazy range (generator), enquanto o range aloca a lista de valores de uma vez.



Sugestões para o código:

- Veja se é possível e faz sentido usar classes para agrupas parâmetros da função. É muito parâmetro, rsrsrs

- Evite fazer qualquer aritmética diretamente em python, se você tiver alguma função de biblioteca que a faça. Por exemplo, o seu primeiro loop é um while em função de kzi, que é incrementado no fim com kzi+=1. Parece besta, mas essa aritmética com while é de 10 a 100 vezes mais lenta do que fazer um for kzi in xrange(0,Nzi).

- Diminuir a quantidade de linhas de código também pode aumentar o desempenho em linguagens interpretadas, tipo python. Por exemplo:

Código:
if kzi == 0:

                    iParX = NparID

                    iParX0 = NparID

                else:

                    iParX = NparID + np.count_nonzero(parFlagX0[:,0:kzi])

                    iParX0 = NparID + np.count_nonzero(parFlagX0[:,0:kzi])

pode virar:

Código:
iParX0 = iParX = NparID if kzi == 0 else NparID + np.count_nonzero(parFlagX0[:,0:kzi])

- Começe otimizando essas coisas do loop mais interno, aninhado, para os mais externos.
Responder
#15
Já testei trocar o while por for. Tinha lido isso. Mas o gargalo não é o while. Sequer dá diferença no tempo total de execução do programa.



O cprofile mostra que se gasta muito tempo nas funções de integração. A função de integração “integra-te.ruk4” é bem simples. O problema é que ela é chamada um caralhão de vezes, dentro de um for loop. A função é rápida, mas a quantidade de chamadas é insana.



Então eu entendo que, de alguma forma, eu teria que descer o nível desse for loop que chama a função de integração

Vou setar um repositório no github e mudar alguns arquivos pra um exemplo de um livro que tenho. Aí não dá problema... vou precisar de um tempinho, mas aí coloco o projeto completo


[00:20] <rav3n> #hnet rlz pq vai de pasta de dente passada no saco ao determinismo q o machado de assis quebrou em umas 20 linhas de chat



http://internetisseriousbusiness.com/
Responder
#16
O seu maior problema é a complexidade desse algoritmo, tem muito for um dentro do outro, pelo o que observei brevemente.

Não é possível que você esteja repetindo o mesmo cálculo várias e várias vezes? Não sei, talvez os parâmetros se repitam.

Você pode utilizar programação dinâmica, que nada mais é do que armazenar os parâmetros e o resultado dos cálculos e antes de fazer novos cálculos buscar se o resultado já existe.



Se quiser apenas traduzir o código para C me parece tranquilo, mas trabalhoso. Vai precisar implementar varias funções que está chamando via bibliotecas, ou encontrar bibliotecas semelhantes em C. Outro problema é que em Python você não precisa se preocupar com overflow de variáveis inteiras, em C sim (não sei se é o seu caso).



Se tiver alguma dúvida mais específica sobre a tradução Python -> C estamos aí. Mas a primeira coisa que eu faria seria definir os tipos de cada parâmetro do seu método (int? unsigned? double? vetor? uma estrutura?, etc.)
Responder
#17
Com aquele tanto de parâmetros nas funções que são chamadas, acho tiver estar havendo overlap, mas em python é tão fácil memoizar que não custa experimentar em um benchmark. Se um link ensinando a fazer: [url="https://www.python-course.eu/python3_memoization.php"]Clique aqui[/url]
Responder


Saltar Fórum:


usuários a ver este tópico: 1 Visitante(s)