Hatalar, hatalar, sorular - sayfa 2161
Ticaret fırsatlarını kaçırıyorsunuz:
- Ücretsiz ticaret uygulamaları
- İşlem kopyalama için 8.000'den fazla sinyal
- Finansal piyasaları keşfetmek için ekonomik haberler
Kayıt
Giriş yap
Gizlilik ve Veri Koruma Politikasını ve MQL5.com Kullanım Şartlarını kabul edersiniz
Hesabınız yoksa, lütfen kaydolun
Kodu dikkatlice kontrol edelim. Gerçek sebebin ne olduğunu bulmak ilginç.
Güzel! Teşekkür ederim! ben de ilgileniyorum
Ve sqrt gerçekten çok hızlı. Bir nanosaniyeden daha az :)). Fantezi!
Statik bir dizi denedim - aynı şey.
sqrt kadar hızlı, bu işlevin bir dizi öğesini okumaktan 10 kat daha hızlı olabileceğine inanmakta zorlanıyorum.
Şu anda birçok eski optimizasyon tekniği artık çalışmıyor.
Ayrıca, örneğimde tuvalin boyutu küçültülmüşse, diyelim ki 50x50 (bunun için Size bir giriş parametresi var, 0 yerine 50 ayarlamanız gerekiyor),
ve dizi çok daha küçük (5000 eleman) olacak, ardından hız resmi belirgin şekilde değişecektir. Artık böyle güçlü bir kontrast yok.
Ama benim için net değil , öğelerine erişim hızı dizinin boyutuna mı bağlı ?
Hesaplamalarınızın saf bir kanıtı yok, çok dağınık koda dayalı varsayımlar yapıyorsunuz.
Kodunuzda bulunan ve sonuçlar üzerinde önemli bir etkisi olan bir ton yardımcı hesaplamayı ihmal ediyorsunuz.
Hesaplamalarınızın saf bir kanıtı yok, çok dağınık koda dayalı varsayımlar yapıyorsunuz.
Kodunuzda bulunan ve sonuçlar üzerinde önemli bir etkisi olan bir ton yardımcı hesaplamayı ihmal ediyorsunuz.
Sadece sqrt'yi bir diziden basit bir okumaya değiştirerek, genel hesaplama hızının 4 kat düştüğünü görüyorum. Ve her pikselin bu oldukça büyük hesaplamasında sqrt'nin toplam payının %10'u, hatta birkaç %'sini aşması pek olası değildir.
Açık bir anomali!
Bir dizi öğesine erişim süresinin sqrt zamanından 10 kat daha fazla olduğunu söylerken bile bir hata yaptım. Sqrt'nin çok hızlı olduğu ve genel yavaşlamanın çok büyük olduğu göz önüne alındığında çok daha fazlası.
Sadece sqrt'yi bir diziden basit bir okumaya değiştirerek, genel hesaplama hızının 4 kat düştüğünü görüyorum. Ve her pikselin bu oldukça büyük hesaplamasında sqrt'nin toplam payının %10'u, hatta birkaç %'sini aşması pek olası değildir.
Açık bir anomali!
nedenini açıkladım. 1990'ların matematik optimizasyonları artık çalışmıyor.
Ancak, gerçekten berbat koda dayanarak aşağıdaki ifadeleri yapmaya devam ediyorsunuz. Fabrika hatalı.
Bu teknik saflık düzeyinde, konuları tartışmayacağım.
nedenini açıkladım. 1990'ların matematik optimizasyonları artık çalışmıyor.
Ancak, gerçekten berbat koda dayanarak aşağıdaki ifadeleri yapmaya devam ediyorsunuz. Fabrika hatalı.
Bu teknik saflık düzeyinde, konuları tartışmayacağım.
Ne tür bir matematik optimizasyonundan bahsettiğini anlamıyorum. Ve herhangi bir açıklama yapmadım, sadece merak ettim - frenlerin kaynağı nedir.
Bu orijinal koddaki çöp ve optimizasyon nerede?
Bu daha çok yönlü kodu kullanabilirsiniz, ancak döngülerin ve dizilerin kullanılması nedeniyle görüntüyü çerçeveleme hızı neredeyse yarı yarıya azalır:
Matematik optimizasyonu: sqrt yerine dizileri kullanmaya çalışmak.
Dağınıklığı görmüyorsunuz ve bu, performans testi kurallarının yanlış anlaşılmasının köküdür. Önceden hesaplanmış diziye karşı hesaplamayı test ediyorsanız, gereksiz tüm öğeleri kaldırmanız gerekir. Kesinlikle her şey gereksiz.
Bir sürü açıklama yaptın. Metinleri alıcının yanından okuyabilmeniz ve onları yazarın çalışmayan korumalarından temizleyebilmeniz gerekir.
Matematik optimizasyonu: sqrt yerine dizileri kullanmaya çalışmak.
Evet Tanrı bu sqrt ile. Bu özel işlev durumunda, bunun bir anlamı olmadığını zaten anladım. Denemenin neresi yanlış? Ama şimdi biliyorum.
Bu arada, aynı örnekte, h[] dizisini kullanmak, sin() kullanmak yerine iyi bir hız kazancı sağlar.
Soru zaten bir başkasında:
Büyük bir dizinin hücrelerine erişim kullanılırken, bir görüntü çerçevesinin hesaplama süresi, yalnızca yüzde birkaç olması beklenirken neden birkaç kat artıyor?
Dağınıklığı görmüyorsunuz ve bu, performans testi kurallarının yanlış anlaşılmasının köküdür. Önceden hesaplanmış diziye karşı hesaplamayı test ediyorsanız, gereksiz tüm öğeleri kaldırmanız gerekir. Kesinlikle her şey gereksiz.
Biliyor musun Renat, senden bir tokat almak hiç de utanılacak bir şey değil, hatta bir onur sayılabilir.
Anladığım kadarıyla çöp, çıkarılabilen ve çıkarılması gereken gereksiz bir şeydir. Ancak bu durumda kaldırılacak bir şey yoktur, aksi takdirde kod çalışmayı durduracaktır.
" Önceden hesaplanmış diziye karşı hesaplamayı" test etmiyorum, ancak çerçeveleme oranını analiz ediyorum.
Evet ve benim durumumda test gerekli değil, çünkü zayıf dizüstü bilgisayarımda ve test etmeden saniyede 25 kare ile saniyede 6 kare arasındaki farkı görebilirsiniz.
Bir sürü açıklama yaptın. Metinleri alıcının yanından okuyabilmeniz ve onları yazarın çalışmayan korumalarından temizleyebilmeniz gerekir.
Sadece birkaç varsayımda bulundum, ancak açıklama yapmadım:
- "SQRT[x] dizisinden okumanın sqrt(x) işlevinden daha hızlı olduğunu varsaymak mantıklıdır."
- " Derleyicinin garip bir şekilde büyük bir diziye eriştiği ve döngünün her yinelemesinde diziyi "unuttuğu" ve her seferinde kendi tür hizmet indekslemeyi yürüttüğü varsayılabilir. "
Ama yine de kendi kendini yetiştirmiş bir programcı olmama rağmen, büyük deneyime sahip kendi kendini yetiştirmiş biri olduğum ve işlemci içinde meydana gelen süreçler hakkında bir şeyler anladığım gerçeğinden dolayı bir açıklama yapmaya cesaret ediyorum, çünkü bir zaman vardı Numega SoftIce benim en sevdiğim programdı, bu sayede montajcı düzeyinde tonlarca başkasının kodunu kürekledim.
- Sizi temin ederim ki, derleyicinizde dizilere erişim açısından (belki de sadece yeterince büyük bir dizi ile kendini gösterir), ekibiniz bu yönde bir çaba vektörü yaparlarsa kolayca bulabilecekleri bir algoritmik söve vardır. Ve örneğim size yardımcı olacaktır.
Hatta tartışabilirim. ))
Bir döngüdeki bir tablo üzerinde yineleme yaptığınızda, sonraki her erişimde, bu büyük olasılıkla işlemcinin önbelleğindedir. Bu nedenle daha hızlı çalışır.
Çağrılar arasında bazı kodlar varsa, büyük olasılıkla bir önbellek kaçırma olacaktır. Bu aynı zamanda büyük ve küçük bir masa ile çalışmanın farkını da açıklar.
Ayrıca, açık olmayan başka durumlar da var. Bu nedenle, kodun sadeleştirilmemiş son versiyonunu test etmek gerekir.
Beyler, işlev şablonlarında enum türünde bir işlevin çağrıldığını nasıl belirleyeceğimi söyleyin ???