Příspěvky

4261

Vývoj / Re:Pametova a vypocetni narocnost JVM vs .NET

« kdy: 17. 09. 2016, 10:19:50 »

Ano, potíž je ovšem v tom, že pro dvojici (int, bool) nebo (UserId, Salary) už žádnou knihovnu nenajdete - to si budete muset napsat kolekci sám (a i tak budete zbytečně alokovat na heapu UserId a Salary).

Ostatně vy v C# také jako první budete muset udělat to, že opustíte obecná řešení v obecných knihovnách, protože ta obecnost optimalizaci brání.

Právě, že ne.

Ale jistě že ano. Protože až to budete optimalizovat, první, co musíte udělat, je zamyslet se nad tím, jestli náhodou tisíciprvkový seznam dvojic UserId a Salary, nad kterým provádíte dlouhé výpočty, není nesmysl.

4262

Server / Re:Porovnání SQLite vs. MySQL

« kdy: 17. 09. 2016, 09:23:02 »

insert into abc (klic, status) values (1, 'OK');
update abc set status = 'ERROR' where klic = 1;
select status from abc where klic = 1;
Výsledek 'OK'.

Nejjdednodušší bylo databázi smazat a vytvořit znovu. Nedokázal jsem zjistit, proč to databáze dělala. Nestávalo se to často, ale při tom množství instalací bylo každou chvíli něco rozbitého.

V tomhle je ale dost podstatné, jak to bylo s transakcemi, které z toho vašeho příkladu nejsou vidět. Pokud UPDATE byla jedna transakce a SELECT jiná, která běžela ještě před potvrzením té první, je to správný výsledek.

4263

Vývoj / Re:Paměťová a výpočetní náročnost JVM vs .NET

« kdy: 17. 09. 2016, 09:14:20 »

Je to pole referencí a kdo bude tvrdit něco jiného tak ukazuje že Javě naprosto nerozumí!

Ještě jednou, v Javě se pojem „reference na objekt“ nepoužívá, protože se k objektu jinak než přes referenci nedostanete, takže se říká jenom „objekt“.

Ono ale při problémech s využitím procesorové cache je naprosto zásadní jak jsou data v paměti uložena!

Právě proto jsem psal, že budu řešit, jak mají být data uložena, a ne to, jak vypadá nějaké pole.

Naimplementujte si třeba velkou matici intů v jednorozměrném poli

Typická webová aplikace je plná velkých matic intů.

Přemýšlet o cache se dnes prostě z hlediska výkonu na reálném hardware vyplácí!

K reálnému hardware potřebujete ještě reálný software. A takového moc není, napsaného v Javě, který by pracoval s velkými maticemi intů a řešil problémy s procesorovou cache. A pokud takový je, jeho autoři snad vědí, jak mají optimalizovat.

Každopádně je velmi zábavná argumentace, že důvod, proč není moc webhostingů podporujících WAR, je ten, že se webhosteři bojí, že by tam měli plno aplikací pracujících s velkými maticemi intů, které budou špatně používat procesorovou cache.

4264

Vývoj / Re:Paměťová a výpočetní náročnost JVM vs .NET

« kdy: 17. 09. 2016, 09:00:20 »

A že ta nejdůležitější a nejzákladnější zásada pro efektivní využití cache je naskládat objekty za sebe a neskákat zbytečně po pointerech?

Kdybyste nereagoval na komentář, kde jsem tohle psal, možná by to bylo i vtipné.

4265

Vývoj / Re:Pametova a vypocetni narocnost JVM vs .NET

« kdy: 17. 09. 2016, 08:58:07 »

Ano, potíž je ovšem v tom, že pro dvojici (int, bool) nebo (UserId, Salary) už žádnou knihovnu nenajdete - to si budete muset napsat kolekci sám (a i tak budete zbytečně alokovat na heapu UserId a Salary).

Ne, v tom žádná potíž není, protože to nikdy nebudu potřebovat. A i kdyby náhodou někdy bylo potřeba optimalizovat takový kód na použití procesorové cache, bude to stejně takové práce, že proti tomu je napsání jedné specifické kolekce brnkačka. Ostatně vy v C# také jako první budete muset udělat to, že opustíte obecná řešení v obecných knihovnách, protože ta obecnost optimalizaci brání.

4266

Vývoj / Re:Pametova a vypocetni narocnost JVM vs .NET

« kdy: 16. 09. 2016, 22:17:03 »

Java bohužel nemá lepší třídu ve standardní knihovně.

V Javě není žádný problém s používáním knihoven. Omezovat se jen na standardní knihovnu je nesmysl.

4267

Vývoj / Re:Pametova a vypocetni narocnost JVM vs .NET

« kdy: 16. 09. 2016, 21:46:36 »

Příkladem je seznam čísel, když v Javě použijete generický ArrayList pro uložení 1000 intů.

Jak už jsem psal, napsat špatný program lze v libovolném jazyce.

Analogická věc v .NET Core zabere zhruba 4032 bajtů

Ne, to není analogická věc. Analogická věc k tomu příkladu z .NET by bylo v Javě použití třídy třeba jodd.util.collection.IntArrayList, com.google.common.primitives.Ints.IntArrayAsList nebo podobné (nějakou takovou má každá knihovna s utilitami).

4268

Vývoj / Re:Paměťová a výpočetní náročnost JVM vs .NET

« kdy: 16. 09. 2016, 20:49:22 »

To je pole referencí, ne?

V Javě je to pole objektů, Java nerozlišuje objekt a referenci.

Efektivnější využití procesorové cache?

Pokud mám problém s využitím procesorové cache, budu řešit efektivnější využití procesorové cache, a ne vytváření pole objektů tak, aby všechny objekty byly v paměti za sebou (už jenom proto, že do té cache se moc objektů nevejde).

Ale hlavně to nijak nesouvisí s dotazem, protože webhoster neovlivní, jak bude nějaká aplikace zacházet s cache procesoru, ať ta aplikace bude napsaná v čemkoli.

Nemusí se to pole potom ještě projít a zavolat pro každý objekt konstruktor? I kdyby se ty objekty vytvořily za sebou, pořád budou v paměti jinde než to pole.

Ano, ale tohle je v Javě pole objektů. V Javě jako jazyku se umístění v paměti neřeší, protože paměť z Javy nevidíte.

Možná budou blízko a možná to nevadí.

V drtivé většině případů to nevadí.

Javu moc neznám, ale v C bych pole ukazatelů nepoužil, pokud by šlo o výkon.

Pokud by šlo o výkon, pole nepoužil bych v Javě pole objektů. Pokud bych zjistil, že v konkrétní implementaci kompilátoru a JVM je problém s procesorovou cache, řešil bych ten konkrétní problém – například s využitím toho, jak jsou v paměti uloženy fieldy objektu.

4269

Vývoj / Re:Pametova a vypocetni narocnost JVM vs .NET

« kdy: 16. 09. 2016, 20:00:17 »

Asi nejde o paměťové nároky, ale o lokálnost. Jak se dá například v Javě vytvořit pole objektů, tak aby bylo zaručeno, že jsou v paměti za sebou?

Netuším, jak by to, zda pole objektů je nebo není v paměti za sebou, mohlo způsobit, že bude Java hosting náročnější na zdroje a webhosterovi se nevyplatí.

A jinak pole objektů, které budou v paměti za sebou, se v Javě vytvoří tak, že se vytvoří pole objektů.

Kód: [Vybrat]

Object[] poleObjektu = new Object[x];

4270

Vývoj / Re:Pametova a vypocetni narocnost JVM vs .NET

« kdy: 16. 09. 2016, 18:39:40 »

Na masivní degradaci výkonu stačí i kolekce obsahující pouhé tisíce prvků. Přístup Javy totiž mrhá cachí a komplikuje práci prefetcheru.

Napsat špatný program lze v jakémkoli jazyce. Pokaždé přijdete s něčím novým, nicméně ještě jste nepřišel s ničím, co by dokazovalo vaše původní tvrzení, že absence uživatelských hodnotových typů v Javě způsobuje výrazně větší paměťové nároky Java aplikací.

Myslím, že ASP.NET MVC podporuje drtivá většina webhostingů - tj. myslím si, že téměř všechny webhostingy to zvládnou.

Takže můžu vzít libovolnou aplikaci napsanou v C# využívající ASP.NET MVC a libovolné další .NET knihovny (třeba iTextSharp , Saxon EE .NET) a nasadit ji na kterýkoli hosting, který podporuje ASPX, třeba Active24, ASPone, web4u?

4271

Vývoj / Re:Pametova a vypocetni narocnost JVM vs .NET

« kdy: 16. 09. 2016, 16:48:45 »

Oboje se pak značně projeví ve chvíli, kdy máte mnoho instancí - například v kolekcích.

Nemyslím si, že by webová aplikace, která má v kolekcích uloženy stovky MB dat, byla typická.

Webové aplikace se normálně píší v C#. Například, když použijete ASP.NET MVC, tak vaše aplikace nemusí mít ani jeden ASPX soubor.

Právě proto jsem se ptal na ty webhostingy, které umí hostovat webové aplikace napsané v C#. Protože to je to, co tu porovnáváme.

4272

Vývoj / Re:Pametova a vypocetni narocnost JVM vs .NET

« kdy: 16. 09. 2016, 15:42:19 »

Není pravda, že potřebujete Windows.

Kolik asi bude uživatelů, kteří chtějí spouštět webové aplikace na omezené verzi Mono pod Linuxem? A kolik z nich bude chtít sdílený webhosting?

Kromě toho aplikace pro .NET Framework mohou být méně náročné na paměť díky hodnotovým typům, které pod JVM neexistují.

Za prvé tohle na paměťové náročnosti aplikace vůbec nepoznáte, za druhé Java hodnotové typy má.

Co je to obecný .NET?

Obecný .NET je aplikace napsaná v kterémkoli jazyce pro .NET, třeba v C#. Předpokládám, že takovou aplikaci si na běžném sdíleném ASPX hostingu nespustím.

4273

Vývoj / Re:Pametova a vypocetni narocnost JVM vs .NET

« kdy: 16. 09. 2016, 08:46:14 »

Nepravda. Už jenom pro to, že pro .NET potřebujete Windows. Java není out-of-box pro sdílený hosting navržená, takže si hoster musí udělat vlastní řešení. Navíc o takové řešení má málokdo zájem, protože pro menší věci použije Google App Engine, Heroku a podobné, pro větší věci použijí VPS nebo vlastní hardware. Takže o sdílený hosting na Javě (předpokládám, že myslíte hostování WAR) by byl malý zájem – takže zároveň není kam rozpustit fixní náklady, tedy to nebude levné, a o to menší zájem by o to byl.

Pro obecný .NET nějaký takový existuje? Jsou sdílené webhostingy pro ASPX, ale to je podobné, jako PHP. A pak to jsou různé VPS nebo cloudová řešení jako Azure.

4274

Software / Re:Boj s kvalifikovaným certifikátem

« kdy: 16. 09. 2016, 08:04:18 »

Odkaz na stazeni issuer certifikatu je obvykle v tzv. AIA casti certifikatu.

Máte pravdu. Nevíte, zda to e-mailoví klienti nebo prohlížeče PDF při ověřování podpisů používají? Webové prohlížeče intermediate certifikáty nestahují (což je docela pochopitelné, protože by to blokovalo navázání HTTPS spojení – ale zase by si mohl prohlížeč certifikát uložit do nějaké cache).

Este nikto z uzivatelskeho hladiska neodpovedal na 1)
1) V mailovom klientovi vidim podpisanu prilohu s takou "pecatou". Pred zmenou prilohy to neochrani. Utocnik moze podpisanu prilohu odstranit a dat tam druhu nepodpisanu.

Tazatel se neptal na podepsané přílohy, ale na podepsaný e-mail. Testovací podepsaný e-mail z MS Outlooku vypadá takhle:

Kód: [Vybrat]

multipart/signed                    (podepsaný e-mail)
- multipart/mixed                   (e-mail)
- - multipart/alternative           (tělo e-mailu)
- - - text/plain                    (tělo e-mailu jako čistý text)
- - - text/html                     (tělo e-mailu jako HTML)
- - application/pdf                 (příloha)
- application/pkcs7-signature       (podpis)

Takže podepsaný je celý e-mail, jak tělo e-mailu tak příloha. Pokud by útočník přílohu v e-mailu vyměnil, nebude podpis e-mailu sedět.

4275

Software / Re:Boj s kvalifikovaným certifikátem

« kdy: 15. 09. 2016, 22:17:27 »

Ten, kdo podpis ověřuje, musí intermediate certifikát mít – buď z podpisu, nebo ve svém úložišti certifikátů. Bez toho nedokáže podpis ověřit (pokud nebude ručně hledat intermediate certifikát na internetu). Měl by tedy být součástí podpisu, stejně jako by měl inetermediate certifikáty posílat třeba  HTTPS server. Ale jak se v tomhle chová který e-mailový klient jsem nikdy nezkoumal.