Implementação personalizada da função ArcGIS


9

Gostaria de descobrir o que é necessário para criar uma implementação personalizada de uma função ArcGIS. Em particular, gostaria de implementar o GeoAnalyst.ISurfaceOp2.Visibility () para que ele funcione mais rapidamente. No momento, leva cerca de 3 segundos por chamada para Visibility (). Do meu entendimento limitado, o gargalo é a gravação de rasters temporários no sistema de arquivos. Se isso puder ser feito na memória, suspeito que o tempo de processamento diminuirá significativamente. Estou fazendo isso em um projeto .NET, mas soluções em qualquer idioma são bem-vindas.


Por que não apenas gravar os rasters temporários em um disco RAM? Então você não precisará codificar a visibilidade do zero, o que vem com seus próprios riscos e custos.
— whuber

Isso parece ótimo. Como eu faria isso? Não é isso que os estados do @Radar não são possíveis na resposta abaixo?
— Ross Fuhrman

4
Você instala um disco RAM no seu sistema; os detalhes variam de acordo com o sistema operacional. Então você aponta a pasta de rascunho do ArcGIS para ela. Você poderia se sair quase tão bem usando um SSD, especialmente se seus rasters forem enormes ou se não tiver muita memória RAM.
— whuber

Eu gosto da ideia do disco RAM. Um SSD é arriscado, pois não é ótimo para operações constantes de leitura / gravação, pois você pode desgastá-lo rapidamente.
— Radar

2
Um SSD baseado em flash sobreviverá de 1 a 5 milhões de gravações, @Radar, mas os SSDs de DRAM não irão se desgastar. Visite storagesearch.com para (lotes) mais informações.
— whuber

Respostas:


5

Esta resposta memoriza e expande parte da discussão nos comentários. Um disco RAM emula uma unidade de disco externa usando parte da RAM em um sistema de computação. Ele pode ler e gravar em velocidades comparáveis ​​ao cache na memória, menos um pouco de sobrecarga para os protocolos de conversão converterem comandos orientados a disco em comandos orientados a memória. Um disco RAM é criado executando um software especial no nível do sistema operacional, um "driver de dispositivo". Os discos de código aberto e RAM gratuitos estão disponíveis para muitos sistemas operacionais, incluindo o Windows.

Portanto, uma maneira de acelerar um gargalo devido à E / S do disco intermediário é configurar um disco RAM (comprando a RAM adicional, se necessário) e colocar a pasta de trabalho lá. (Geralmente, essa é uma configuração de software.)

Outra opção é instalar um dispositivo de estado sólido (SSD) DRAM de ponta , que é essencialmente um bloco de RAM em um pacote separado com uma interface eletrônica para agir como uma unidade de disco. Ele é instalado em um sistema de computação no lugar de uma unidade de disco e se comporta exatamente como outra unidade de disco sem nenhum software adicional, mas lê e grava quase tão rápido quanto a memória acessa. Eles são relativamente caros, mas provavelmente apenas um pequeno é necessário, mesmo para armazenamento raster intermediário muito grande.

Antes de executar qualquer uma dessas etapas, é importante criar um perfilo processo para verificar onde realmente está o gargalo. (O Windows foi fornecido com aplicativos de perfil e monitoramento cada vez mais poderosos nos últimos anos, disponíveis no Win 7 como o par Gerenciador de tarefas / Monitor de recursos e, é claro, muitos aplicativos semelhantes também estão disponíveis para outros sistemas operacionais.) Muitos sistemas são configurados automaticamente ou pode ser configurado para armazenar em cache as leituras e gravações do disco na RAM por curtos períodos. O armazenamento em cache funciona quase da mesma forma que um disco RAM, mas provavelmente é ainda mais rápido: o software pensa que está gravando arquivos intermediários no disco, mas o sistema operacional os grava temporariamente na RAM primeiro, sem acessar o disco, na esperança de que em breve os mesmos dados será lida novamente e excluída; nesse caso, uma gravação física nunca será necessária.

Dada a quantidade de computação necessária para qualquer cálculo de visibilidade total (em um algoritmo ingênuo, todas as células precisam ser inspecionadas quanto à visibilidade uma vez para cada ponto de vista), deve-se pelo menos suspeitar que a velocidade da computação, não a E / S do disco, possa ser o problema aqui. Se for esse o caso, os discos RAM ou SSDs serão um desperdício de tempo e dinheiro. Em vez disso, o esforço deve ser direcionado para analisar e melhorar o algoritmo subjacente .

Alguma discussão sobre se o desempenho do disco RAM ajuda o ArcGIS apareceu em outro segmento .


+1 Ótima resposta. Eu acho que o pessoal do GIS também deve ficar de olho no uso geral da unidade de processamento gráfico, ou GPGPU . Suspeito que a maioria dos jogos de tiro em primeira pessoa aproveite a GPU para determinar a visibilidade do objeto a partir da localização do atirador. Seria ótimo ver uma implementação OpenCL desse problema. Talvez se o GIS usasse mais a GPU, isso poderia chamar a atenção de crianças que cresceram jogando videogame.
— Kirk Kuykendall

Eu também quis mencionar que a GPU é otimizada para fazer coisas como determinação de superfície oculta , que é semelhante ao que ISurfaceOp2.Visibility faz.
— Kirk Kuykendall

Boas ideias, @Kirk. O manifold usa as GPUs NVIDIA (e o faz há vários anos). Há também pesquisas independentes nessa frente; Participei de alguns esforços de propostas de doações para desenvolver implementações de álgebra de mapas baseadas em GPU.
— whuber

Esta é uma excelente resposta. Fiz a criação de perfil sugerida e parecia que poderia haver um gargalo de E / S de disco. Então, implementei uma solução que usava um disco RAM (escolhi o IMDisk). No final, isso não reduziu o tempo para concluir o processo.
— Ross Fuhrman

Lamento ouvir que não houve melhora. A visibilidade é um cálculo dispendioso: em princípio, todas as células no DEM devem ser inspecionadas para cada observador e o processo de inspeção pode ter que observar uma linha inteira de células entre o observador e a célula do DEM: isso pode significar bilhões de cálculos por observador mesmo em uma grade modesta (megapixel). Se o tempo de computação for o problema, é provável que suas duas melhores opções (1) sejam paralelas ao trabalho: divida os observadores nas estações de trabalho, calcule as visibilidades, combine os resultados; e (2) escreva seu próprio código de visibilidade.
— whuber

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.