Zabava s VS .NET

[Petr Labaj]

Řekl bych, že to bude závislé na více faktorech, mimo jiné asi i na tom,
jak efektivně zpracovává daný procesor 32b a jak 64b kód.

Když jsem kdysi dávno (tak 8-10 let zpět) u jednoho svého projektu přecházel
na 64b, tak jsem si to taky měřil. Tam to vycházelo dost do mínusu, určitě
víc než 10%. Bylo to tenkrát na procesorech AMD, jiné jsem v té době
nepoužíval. Přejít jsem tehdy musel, protože jsem potřeboval větší pointery.
Bylo to na Linuxu, překladač samozřejmě GCC (verzi už nevím).

Od té doby všechno, kde je to možné, překládám pro 32b. Vím, že to pojede
na jakémkoli PC, ať už má OS 32, nebo 64b, kód bude menší, a podle mých
tehdejších měření i rychlejší.

PL

*********************************

From: "Josef Štengl" <ok1ced na nagano.cz>
To: "HW-news" <hw-list na list.hw.cz>
Sent: Thursday, September 18, 2014 2:28 PM
Subject: Re: Zabava s VS .NET


| ... a větší šíře a více registrů je jen další zpomalovátko že? :-)
| 
| Bohužel na zdroj si nepamatuji, takže neověřená informace, ale když  se objevily 64 bit procesory nějací nadšenci si dali 
| tu práci a změřili výpočetní rychlost více aplikací. Vyšlo jim průměrně asi +20% ve prospěch 64bit. V rozsahu asi -5% – 
| 30%, záleželo na aplikaci. Samozřejmě lze najít i extrémy, když se snažíte. Takže větší pointery jsou cena za rychlost a 
| možnost používání některých aplikací. Kolegové pomalu přecházejí na 64 bit a více paměti aby Altium bylo ochotno 
| vygenerovat netlist složitější desky.
| 
| Pravda, ty aplikace byly povětšinou v C/C++ a testovalo se na GNU/Linuxu ...
| 
| Další důvod je ten, že v paměti nemusím mít 32b a 64b verze stejné knihovny, když už používám 64 bit (je to dost otravné 
| zjišťovat, co musím mít 2x).
| 
| ced
| 
| 
| Dne 18.9.2014 v 13:11 Marek Sembol napsal(a):
| > Hlavne pro kompilaci do 64b z 99.999% neni duvod. 64b ma snad jedinou vyhodu ("nekonecnou" pamet), kterou vyuzije hodne
| > maloktery program. Na druhe strane kazda adresa je 64b => vetsi obsazenost cache => pomalejsi beh. Ja vim, to pomalejsi je
| > (zvlaste pro bezne aplikace) prakticky nemeritelen, ale...
| > M.
| >
| > 2014-09-18 13:01 GMT+02:00 <Halen na seznam.cz <mailto:Halen na seznam.cz>>:
| >
| >     Musíte kompilovat do 64b? Já bych se tomu vyhnul obloukem. Z vlastní zkušenosti doporučuji kompilovat do 32 bit.
| >     Visual studio express standardně nepodporuje kompilaci do x64 a další funkce (jako vytváření services)
| >
| >     Chybu by měl odstranit service pack 1 do Visual studia.
| >
| >     Honza
| >
| >     ---------- Původní zpráva ----------
| >     Od: Pavel Hudeček <edizon na seznam.cz <mailto:edizon na seznam.cz>>
| >     Komu: hw-list na list.hw.cz <mailto:hw-list na list.hw.cz>
| >     Datum: 17. 9. 2014 21:30:54
| >     Předmět: Zabava s VS .NET
| >
| >
| >         Dobrý den všem,
| >
| >         Tak nejprve jsem měl DLL vytvořené v Builderu a testoval ho ve VB 2008. To fungovalo, jen když jsem v builderu
| >         nechal udělat 64b. No budiž.
| >
| >         Pak problém: komponeny Indy UDP negenerují události, pokud jsou v DLL.
| >
| >         Pak byla nedávná diskuse, jaké použít vývojové prostředí s C pro Win.
| >
| >         Stáhnul jsem instalačku Visual studia 2010 express a nainstaloval VB a VC.
| >
| >         Zjistil jsem, že VC nemůžu donutit, aby generovalo 64b kód.
| >
| >         Strávil jsem celý den různými marnými pokusy, až jsem se nakonec dobral k instalaci jakéhosi SDK, které způsobí,
| >         že se tam oběví kromě Win32 i možnosti x64 a Itanium.
| >
| >         Jenže od té doby zas veškeré pokusy o kompilaci čehokoli končily hláškou
| >         Error 'LINK : fatal error LNK1123: failure during conversion to COFF: file invalid or corrupt'
| >
| >         Nakonec jsem musel odinstalovat framework 4.5 a nainstalovat 4.
| >
| >         OK, nyní to kompiluje a i 64b.
| >
| >         Jenže jakákoli snaha o výrobu DLL ve VC++  a použití ve VB se míjí účinkem.
| >
| >         Když např. zkusím tuto ukázku:
| >         http://msdn.microsoft.com/cs-cz/library/ms235636.aspx
| >         tak vše funguje, program ve VC volá DLL psané též ve VC
| >
| >         Když totéž DLL zavolám z VB, jako jsem to dělal s tím DLL z Builderu, tedy s použitím Declare, skončí to chybou
| >         BadImageFormatException was unhandled
| >         (tato hláška mi vznikala i s Builderem, pokud buildil 32b)
| >
| >         OK, asi se DLL vytvořené v .NET musí volat jinak.
| >
| >         Našel jsem tuto ukázku:
| >         http://www.dreamincode.net/forums/topic/121314-creating-a-dll-and-using-it-in-your-application/
| >         vše funguje, program psaný ve VB volá DLL psané ve VB
| >
| >         Když jsem ovšem zkusil udělat program, kde stejným způsobem importuji DLL MathFuncs z té ukázky pro VC, import se
| >         nezdaří, zobrazí se msgbox s chybou:
| >         A reference 'C:\ ... .dll' could not be added. Please make sure that the file is acessible, and that it is valid
| >         assembly or COM component.
| >         A tato hláška se zobrazí při pokusu o import jakéhokoli jiného DLL než z té ukázky ve VB.
| >
| >         Tak teď už teda fakt nevim...
| >
| >         PH
|