İddialı fikirler!!! - sayfa 5

 

Andrey01 :

En basit şeyleri bilmediğiniz için yanılıyorsunuz.

Herhangi bir dizinin verileri doğrusal olarak bellekte bulunur. İlkinden sonuncusuna, x[15] elemanına atıfta bulunurken, ardından bu değişkeni hesaplamak için, derleyici dizinin başlangıcının adresini artı değişkenin adresi olacak ofset 15'i hesaplayacaktır. İki boyutlu bir dizide, örneğin x[2][5], önce ikinci satır için ofseti hesaplamanız ve ardından buna 5. eleman için ofseti, yani iki kat daha fazla işlemi eklemeniz gerekir.

x[2] [5] --> x[((2-1)* ArrayRange(x[0])+5)]

x[15] --> x(+15)

bunların hepsi derleyici düzeyindedir, ancak statik bir dizi için ArrayRange(x[0]) DAİMA değişmez, sürekli hesaplanması gerekmez, bir kez hesaplayıp derleme aşamasında kaydetmek yeterlidir

Montajcı mısın? neden bu sorunlar? montajcı ile meşgulseniz, ne yazık ki - Rus belgeleri, Pentium-I'den daha eski işlemciler için talimat boru hattının DOĞRU yüklenmesini görmedim ve işlemcinin DOĞRU yüklenmesi derleyici geliştiricileri tarafından bile değil, işletim sistemi ve işlemci mimarisi geliştiricileri

çarpma işleminin toplama işleminden daha uzun işlemci döngülerinde gerçekleştirileceğinden endişeleniyorsanız, ne yazık ki, 486. işlemci ile trenin terk edilmesi, önbelleklerin ve komut ardışık düzenlerinin yüklenmesi, aritmetik ve mantıksal işlemler yapmaktan daha uzun sürer.

Not: bir kez daha itiraz ediyorum - birincil kaynakları okumaya başlayın, burada https://www.mql5.com/ru/docs/basis/types/classes mql5 geliştiricileri veri hizalamanın nasıl DOĞRU şekilde düzenleneceğini açıklar, aynı bilgi herkes için mevcuttur derleyiciler, Windows sistem işlevlerinin çağrısını doğru kullanmak gibi bilgiler var, vb. - Bunu, işletim sisteminin ve işlemcilerin modern yeteneklerine karşılık gelen çok az Rusça belge olduğu gerçeğine yazıyorum, aksi takdirde eski şeyler - kolejlerde ve üniversitelerde öğretilen malzeme - bu aşamada gerçeğe karşılık gelmiyor. işletim sistemi ve donanımın geliştirilmesi

 
IgorM :

x[2] [5] --> x[((2-1)* ArrayRange(x[0])+5)]

x[15] --> x(+15)

bunların hepsi derleyici düzeyindedir, ancak statik bir dizi için ArrayRange(x[0]) DAİMA değişmez, sürekli hesaplanması gerekmez, bir kez hesaplayıp derleme aşamasında kaydetmek yeterlidir

Derleme aşamasında sadece ilk elemanın adresi hesaplanır. Diğer tüm öğeler, sayma modunda her seferinde farklı olan bir ofset aracılığıyla sayılacaktır.

İki boyutlu bir dizi ile, satır numarasıyla çarpılan sütunlarda ve satırlarda ve tabii ki sayma sürecinde iki ofset hesaplamanız gerekir. Derleyici ve derleyicinin bununla kesinlikle hiçbir ilgisi yoktur, bunlar sadece calc'ın doğru kullanımı için bellek adreslemesinin temelleridir. pratikte kaynaklar.

Buradan, tek boyutlu ve iki boyutlu diziler arasında bu kadar önemli bir performans kaybı olsa bile, nesneler gibi daha karmaşık durumlarda adresleme süresinin daha da yavaşlayacağını rahatlıkla anlayabilirsiniz.

 
Andrei01 :

Derleme aşamasında sadece ilk elemanın adresi hesaplanır. Diğer tüm öğeler, sayma modunda her seferinde farklı olan bir ofset aracılığıyla sayılacaktır.

İki boyutlu bir dizi ile, satır numarasıyla çarpılan sütunlarda ve satırlarda ve tabii ki sayma sürecinde iki ofset hesaplamanız gerekir. Derleyici ve derleyicinin bununla kesinlikle hiçbir ilgisi yoktur, bunlar sadece calc'ın doğru kullanımı için bellek adreslemesinin temelleridir. pratikte kaynaklar.

Buradan, tek boyutlu ve iki boyutlu diziler arasında bu kadar önemli bir performans kaybı olsa bile, nesneler gibi daha karmaşık durumlarda adresleme süresinin daha da yavaşlayacağını rahatlıkla anlayabilirsiniz.


Olanların özünü ve üretkenlik kaybını anlamada başarı

Derleyicileri optimize etme ve kendi veri erişim yapılarımı yazma konusunda hiçbir sorunum yok

Not: nesneler karmaşık durumlar değildir - bağlantı oluşturmak için yapılan tüm manipülasyonların tümü derleyici düzeyindedir, ne yazık ki, işlemci nesne olup olmadığına bakmaz, hizalanmış verilere göre ofsetleri hesaplamada sorun yaşamaz. “harika programcı” hafızadan tasarruf sağlar - verileri bayt türünde dizilere yazar, ancak derleyicinin belgelerine bakmaz, o zaman böyle bir kodun etkinliği yalnızca bu programcının kendinden memnun fizyonomisinin yansımasında görünür olacaktır. ayna, ama aslında sahte

 
IgorM :


her şey derleyici düzeyinde, ne yazık ki, işlemci bir nesne olup olmadığını umursamıyor, hizalanmış verilere göre ofsetleri hesaplamada hiçbir sorunu yok

Basit bir örnek kullanarak, size göreli tek boyutlu bir dizinin iki boyutlu dizisinin derleme değil, program yürütme sürecinde ne kadar yavaşlayacağı açıklanmıştır. Kendimi tekrarlamak için bir neden göremiyorum. Bu, aşağı yukarı optimal bir hesaplama kodu yazma göreviyle kendinizi fazla rahatsız etmediğinizi, belki de buna ihtiyacınız olmadığını gösterir. Bu durumda OOP sadece sizin için yaratılır. :)

 

Amip üzerinden düşünüyorsun :) .

"Küçük verimliliği unutmalıyız , diyelim ki zamanın yaklaşık %97'si: erken optimizasyon tüm kötülüklerin köküdür. Yine de bu kritik %3'lükteki fırsatlarımızı kaçırmamalıyız" (c) Donald Knuth

Bu forumda dördüncü kez alıntı yapıyorum.

 
Andrei01 :

Sadece basit bir örnek kullanarak, size göreli tek boyutlu bir dizinin iki boyutlu dizisinin derleme değil, program yürütme sürecinde ne kadar yavaşlayacağı açıklanmıştır. Kendimi tekrarlamak için bir neden göremiyorum. Bu, aşağı yukarı optimal bir hesaplama kodu yazma görevi ile kendinizi rahatsız etmediğinizi, belki de buna ihtiyacınız olmadığını gösterir. Bu durumda OOP sadece sizin için yaratılır. :)


optimal kod nedir? Derleyicilerin ve sanal makinelerin nasıl çalıştığı hakkında hiçbir fikriniz yok

programcının her bir derleyicide fiziksel bellek öğelerine erişimin ve adreslemenin nasıl olduğunu anlaması gerekmez (evet, hatta çapraz olarak ve bir sütunda değil - yapılacak hiçbir şey yok) - geliştiricilerin görevi budur, programcı koddan memnun değilse - kodunu optimize eder:

- kod boyutunu artırarak ve veri boyutunu azaltarak ve hesaplama hızını kaybederek

- koddaki verilerin boyutunu artırır ve daha fazla hız kazanır

- alternatif olarak farklı bir derleyici kullanır

TÜM SEÇENEKLER gitti!

OOP, ETKİLİ kod yazmak için başka bir daldır, OOP'nin etkinliği, bir programcının belirli bir mimari biçiminde bir matematiksel modeli derleyebilmesidir - böylece sınıfların fiziksel için farklı bir adresleme türüne sahip olduğunu icat ederseniz, kodunuzun çok işlevliliğini elde eder. verilere erişim - yanılıyorsunuz, bu mikroskobik ek veri miktarı - nesnenin bağlantı tablosu, bellekteki fiziksel verilere erişim süresini hiçbir şekilde artırmaz ve fazla veri, çok işlevlilikten daha fazla dengelenir

Şok oldum - OOP'ye sıçmaya başladınız, sonra çok boyutlu ve tek boyutlu dizilerde ele alma konusunda akıl yürütmeye geçtiniz - bunu bir yerde mi öğrettiniz yoksa hepsi spekülasyon ve fanteziler mi?

çok boyutlu dizilerle çalışmak uzun süredir donanım düzeyinde uygulanıyor - video kartlarıyla çalışırken aynı Z-tamponu, oh, evet, "koyun donanım geliştiricileri" - size danışmadılar ve bulamadılar size danışmadan çok boyutlu dizileri ele almanın ne kadar etkili olduğu - işte bu kadar programcılar çok boyutlu dizileri kullanmaktan çekinmezler ve tek boyutlu dizilerle çalışırken hayali verimlilik uğruna kodu artırmanın mutluluğunu aramazlar

 
Andrei01 :
Fakat bilginin güvenilirliği, onu kimin söylediğine mi bağlı? Görünüşe göre aklı başında herhangi bir kişi, bilginin öznel değil nesnel bir şey olduğunu anlamalıdır. :)
Ve konuyu anlamak için yola çıkan herhangi bir kişi, bu arada bilginin ve niceliğinin nesnel değil öznel bir şey olduğunu anlayacaktır. :))
 
Modern (özellikle 64-bit) programların verimliliği büyük ölçüde geliştirme ortamları ve derleyicileri tarafından belirlenir. Modern programlar, merkezi işlemcinin performansına ve kodlarının verimliliğine zaten daha az bağımlıdır. Bunun neden böyle olduğunu bilmek isteyen herkesi, başka türlü değil, E. Tanenbaum'un anıtsal eseri " Bilgisayar Mimarisi "ni okumaya, özellikle bölüm 5, "Intel IA-64" bölümüne yönlendiriyorum. Eski derleyicilerde yordamsal kod içeren herhangi bir hile, normal bir geliştirme ortamına geçişle karşılaştırıldığında böyle bir performans artışı sağlamayacaktır. Ne diyebilirim ki, aynı montajcıyı alın. Evet, bu bir şey. Kesinlikle sonsuza kadar yaşayacak. Ancak, çok çekirdekli işlemci, genişletilmiş komut setleri vb. gibi modern donanım kaynaklarını kullanarak normal IA-64 kodundan daha iyi performans gösterecek olan assembler'da IA-386 kodunu yazabileceğinizden şüpheliyim. Bu nedenle, sonuç şu şekilde olmalıdır: aynı - bunun üzerine yazmanız gerekiyor. Bize .NET verildiyse, üzerine yazmamız gerekir. Diğer binlerce programcının CIL kodunun performansını nasıl artıracağını, iş parçacıklarının nasıl paralelleştirileceğini vb. düşünmesine izin verin. MQL4 ile aynı, zamanı geçti, bize MQL5 verildi. MetaQuotes bunu destekleyecektir. Dillerinin performansını nasıl artıracaklarını düşüneceklerdir.
 
IgorM :


programcı koddan memnun değilse, kodunu optimize eder:

- kod boyutunu artırarak ve veri boyutunu azaltarak ve hesaplama hızını kaybederek

- koddaki verilerin boyutunu artırır ve daha fazla hız kazanır

- alternatif olarak farklı bir derleyici kullanır

TÜM SEÇENEKLER gitti!

Kod optimizasyonu , bir programcının, gerçekleştirilen temel işlemler (toplama, çarpma, bellek erişimi, adres hesaplama, vb.) açısından belirli bir kod parçasının ne kadar kaynak yoğun olacağına dair asgari düzeyde bir anlayışa sahip olmasını gerektirir. Bu olmadan, prensipte hiçbir optimizasyon mümkün değildir ve en iyi derleyici bile böyle talihsiz bir programcıya karşı güçsüz olmayacaktır. Bu bariz bir şey gibi görünüyor, ancak bunun birçokları için büyük bir haber olabileceğini görüyorum. :)

 
alsu :
Ve konuyu anlamak için yola çıkan herhangi bir kişi, bu arada bilginin ve niceliğinin nesnel değil öznel bir şey olduğunu anlayacaktır. :))

Pekala, farklı şeyleri patlayıcı bir karışım halinde karıştırmanız ve karıştırmanız gerekiyor. :)

Biri nesnel olan bilginin kaynağı, diğeri ise öznel olan alıcıdır, çünkü her zaman tüm bilgiyi değil, sadece bir kısmını algılayabilir.