Aleksejs Posted September 8, 2008 Report Share Posted September 8, 2008 The FLAME is on B!tCH :D :D :D Nu, nu.. Tātad vienā ringa stūrī codez, otrā Roze - who will win?! Tā laikam mentalitāte mums tāda... Bez pāriešanām uz personīgiem apvainojumiem un sofismu izmantošanas apgalvojumos jau nu nevar iztikt neviena normāla diskusija *.lv zonā. Link to comment Share on other sites More sharing options...
codez Posted September 8, 2008 Report Share Posted September 8, 2008 (edited) bubu, es domāju, ka programmētājam ar pietiekami augstu IQ (kura iztrūkums ir novērojams viena apelsīnkrāsa portāla izstrādātājim) ir saprotams, ka es nerunāju par pliku cron procesu, bet gan par principu, kurā kādi pietiekami sarežģīti aprēķini tiek veikti regulāri. Pēc šāda principa vienmēr protams ir vieglāk izveidot kodu, jo parasti tad aprēķini ir diferenciālā formā, kura vienmēr ir vienkāršāka par integrālu formu, taču kā jau teicu, šāds princips ir resursu rīma, jo tiek veikti ļoti daudz lieki aprēķini, kuru rezultāti tā arī nekad netiek izmantoti, bet nākamajā ciklā jau tiek pārrēķināti pa virsu. Aleksej, :) Edited September 8, 2008 by codez Link to comment Share on other sites More sharing options...
Aleksejs Posted September 8, 2008 Report Share Posted September 8, 2008 Godīgi atzīšos. Mat analīzi knapi nokārtoju, a kā pie Čerānes nokārtoju diferenciālvienādojumus man vēl aizvien ir liela mīkla... Taču pastāsti man prastam cilvēkam (kas pat nepretendē uz neprofesionālo apelsīnportāla programmētāju līmeni) - ko nozīmē "aprēķini diferenciālā formā" un ko nozīmē "aprēķini integrālā formā"? Un varbūt ka "parciāli diferenciāla aprēķinu forma" ir vēl labāka? Link to comment Share on other sites More sharing options...
Roze Posted September 9, 2008 Report Share Posted September 9, 2008 Nav jau brīnums, ka draugiem.lv vienā pieprasījumā slēdzās klāt 15 dažādām datubāzēm un regulāri novērojamas performances problēmas, ja šādi darbinieki tur kaut ko taisa. Agrāk nevarēju saprast, kā var būt performances problēmas tik mazai lapai. Tagad skaidrs. Un tagad pie lietas. Ja tev piemēram ir 100 000 patstāvīgi spēlētāji, tad, ik pēc piecām minūtēm (vai pat biežāk, ja gribētu normālu online) cron izsauktajam pieprasījumam būtu jāaprēķina 100 000 lietotāju dažādu datu izmaiņas. Tā vietā, lai simtiem reižu diennakts laikā rēķinātu katra jūzera visus datus, tos var rēķināt tikai dažas reizes dienā. Pat pie regulārā spēlētāja resursu ieguvums būtu ļoti liels, nemaz nerunājot, ka ir tādi, kuri ieeiet vienreiz nedēļā, vai varbūt vēl retāk. Spriežot pēc kādā konkrētā portālā izmantotas DB arhitektūras, arī DB klasteru sistēma dažiem varētu izklausīties, kā muļķīgākais apgalvojums, kuru nācies dzirdēt. Pirms sāc ņemties vēlreiz izlasi savu sākotnējo postu - "cron ir resursu rīma" .. Ja tu runā par lietojuma aplikāciju tad crontabam kā tādam ar šādu apgalvojumu nav pilnīgi nekāda sakara un tas ir aplams un ja tu reiz kaut ko saki lietotājam, kas uzdod kādu jautājumu, tad vajag atbildēt korekti nevis "es rakstu vienu, bet domāju citu".. Šādi varētu apgalvot ka arī echo arī ir rīma - <? while(1) { echo 1; } ?> ... Got it? "par principu, kurā kādi pietiekami sarežģīti aprēķini tiek veikti regulāri" un ja tu nedaudz vēl padomā - tad ja reiz ir nepieciešami aprēķini tad vai tev šķiet ka tos pārnesot pa taisno uz "live" sistēmu viss notiks ātrāk? crontabs ir mehānisms kā inicializēt darbību un faktiski nav svarīgi vai tas nāk no pārlūka vai crontaba.. Pretēji tam ka caurmērā normālai lietotāju experiencei lapa ir jārenderē <1 sec, tad "background processingam" šādi nosacījumi nav būtiski.. "jo tiek veikti ļoti daudz lieki aprēķini, kuru rezultāti tā arī nekad netiek izmantoti, bet nākamajā ciklā jau tiek pārrēķināti pa virsu" - un ja tu vēl biku biku padomātu, tad varbūt saprastu, ka var rēķināt tikai tos datus, kuri ir jārēķina - aka termins (data) queue.. jebšu atsaucoties uz tevis teikto "programmētājam ar pietiekami augstu IQ" nekas lieks un nekas viss nav jāparrēķina pa virsu.. Kas attiecas uz DB klasteriem labprāt paklausītos tavu teoriju (nopietni) .. Jo līdz šim viss kas ir dzirdēts piemēram no Oracle .lv pārstāvjiem lai nodrošinātu kaut vai esošo QPS jaudu cenas un risinājumi ir kosmiski <g> (fiber channel, rac clusteris ar nodem uz P5) .. Bet ja viss aprobežojas ar kaut kādu random terminu un ciparu saukšanu ( izmantojot šo "maģiju" ... "simtiem un tūkstošiem reižu" ), tad tas man nav interesanti.. p.s. kas attiecas uz performanci utt var teorētiski paskatīties http://www.audience.gemius.lv/pages/pageviews .. rupji rēķinot visiem kopā kaut kā nesanāk cik "neprofesionālo apelsīnportālam" .. secinājumus izdari pats.. Link to comment Share on other sites More sharing options...
rpr Posted September 9, 2008 Report Share Posted September 9, 2008 codez, varbūt vari parādīt reālu piemēru? Link to comment Share on other sites More sharing options...
yuppio Posted September 9, 2008 Author Report Share Posted September 9, 2008 Nu jā, augstākās matemātikas pielietošanas šādā veidā praksē arī man ir tumša bilde, kaut gan tieši to nākas pašlaik apgūt augstskolā :) Interesanti gan, codez, pie kādiem projektiem tad Tu pats strādā, ja jau visu tik ļoti labi pārzini (vai vismaz tādu iespaidu centies radīt) un ka "programmētājam ar pietiekami augstu IQ (kura iztrūkums ir novērojams viena apelsīnkrāsa portāla izstrādātājim)". Pateikt, ka citi neko nejēdz mēs protams visi lieliski mākam. Bet nu daļēji tev piekrītu, ka lai vai kā lielāko daļu šos procesus var mierīgi rēķināt pēc pieprasījuma, nevis pēc noteikta laika intervāla, jo ja piemēram spēlētājs ir nolīdis kāda spēles pasaules stūrī un viņa resursu apjoma ciparu neviens nedabū redzēt, tikmēr nav svarīgi cik liels viņš ir. Bet jebkurā gadījumā ir vietas, kur bez cron tipa risinājuma tāpat nevar izlīdzēties manuprāt. Link to comment Share on other sites More sharing options...
codez Posted September 9, 2008 Report Share Posted September 9, 2008 (edited) Piemērs spēlei: Ir pilsēta vai ciems, kurā ir iedzībotāju skaits b. Pieņemsim, ka iedzīvotāji vairojās. Pieņemsim, ka mēs esam izdomājuši šādu vairošanās likumu - katrā laika vienībā nāk klāt proporcionāls iedzīvotāju skaits. Respektīvi, ja ir 200 iedzīvotāji, tad laikā t pienāk, piemēram 2, bet, ja 100, tad 1. diferenciālā formā formula būtu: db/dt = C1*b, kur db/dt ir iedzīvodāju izmaiņa laikā, C1 - regulējoš koeficients (piemēram 0,001), b - pašreizējais iedzīvotāju skaits. Ja mēs rēķinātu šādā formā, tad ar cron ik pēc laika dt mums būtu jāizsauc un jāizrēķina jaunā b vērtība. b2=b1+db/dt=b1+C1*b1 Pārveodojam priekš integrēšanas db/b = C1*dt integrējam ln(b2)-ln(b1) = C1(t2-t1) ln(b2/b1) = C1(t2-t1) b2/b1 = exp(C1(t2-t1)) lūk vienādojums integrālā formā: b2 = b1* exp(C1(t2-t1)) Tagad iedzīvotāju skaitu b2, mēs varam izrēķināt jebkurā brīdī. t1 - laiks kad pēdējo reizi rēķinājām; t2 - pašreizējais laiks; b1 - b(t1) - iedzīvotāju skaits pēdējā aprēķinā; b2 - iedzīvotāju skaits pašlaik. Ja ir kādi maksimālie ierobežojumi (Bmax), piemēram dzīvojamo ēku daudzums vai vienalga kas, kas ierobežo iedzīvotājus skaitu, tad vienkārši izvadām min b2=min(Bmax,b1*exp(C1(t2-t1))) Šis protams ir triviāls piemērs, taču šādi var nointegrāt arī salīdzinoši sarežģitas funkcijas un rindas. Pierādījums, ka formula ir pareiza: Ja mēs rēķinam b3 2 soļos, tad rezultātam jābūt tādam pašam, kā rēķinot vienā solī: b2 = b1* exp(C1(t2-t1)) b3 = b2* exp(C1(t3-t2)) Ievietojam b2 b3 = b1*exp(C1(t2-t1))*exp(C1(t3-t2)) b3 = b1*exp(C1(t2-t1)+C1(t3-t2)) b3 = b1*exp(C1(t2-t1+t3-t2)) b3 = b1*exp(C1(t3-t1)) Iegūstam tādu pašu formulu, kā rēķinot vienā solī. Edited September 9, 2008 by codez Link to comment Share on other sites More sharing options...
v3rb0 Posted September 9, 2008 Report Share Posted September 9, 2008 :sarcasm on integrāļi webistiem, nepūlies pārliecināt, bet priecājies ka vari to, ko citi nē. Link to comment Share on other sites More sharing options...
codez Posted September 9, 2008 Report Share Posted September 9, 2008 (edited) "par principu, kurā kādi pietiekami sarežģīti aprēķini tiek veikti regulāri" un ja tu nedaudz vēl padomā - tad ja reiz ir nepieciešami aprēķini tad vai tev šķiet ka tos pārnesot pa taisno uz "live" sistēmu viss notiks ātrāk? Protams ātrāk, jo dati tiek rēķināti tikai tad, kad tie ir nepieciešami, nevis nepārtraukti, kā rezultāta 99% datu tiek jau nākamā ciklā pārrēķināti pa virsu nemaz neizmantoti. Pie tam sekunde sekundē ir live dati, nevis kādi 15, 5 vai 1 minūti veci dati. crontabs ir mehānisms kā inicializēt darbību un faktiski nav svarīgi vai tas nāk no pārlūka vai crontaba.. Pretēji tam ka caurmērā normālai lietotāju experiencei lapa ir jārenderē <1 sec, tad "background processingam" šādi nosacījumi nav būtiski.. Jā tikai tu aizmirsti par to, ka mūsdienu serveri ir ļoti jaudīgi un, šajā gadījumā runājot par spēli, tad tie bez problēmām paspēs veikt visus aprēķinus. Protams viss ir atkarīgs no programmētāja spējām. Pieņemsim, ja ir kādas simt resursu ieguves, tad katru reizi nessumēs visu resursa ieguvju devumu, bet glabās parametrus, kuri raksturo ieguvumu no visām kopā. Viltīgi kešojot dažādus starprezultātus var panākt tādu performanci par kādu es runāju - simtiem un tūkstošiem reižu. Man šādu sistēmu lietotjot pat salīdzinoši sarežģītiem aprēķiniem, nav nācies sastapties, ka aprēķini laika ziņā pat pietuvojušies ar šiem aprēķiniem nesaistītiem servera resursu ēdājiem. "jo tiek veikti ļoti daudz lieki aprēķini, kuru rezultāti tā arī nekad netiek izmantoti, bet nākamajā ciklā jau tiek pārrēķināti pa virsu" - un ja tu vēl biku biku padomātu, tad varbūt saprastu, ka var rēķināt tikai tos datus, kuri ir jārēķina - aka termins (data) queue.. jebšu atsaucoties uz tevis teikto "programmētājam ar pietiekami augstu IQ" nekas lieks un nekas viss nav jāparrēķina pa virsu.. Paņemsim manu piemēru par iedzīvotājiem ciemā. Pēc crontab metodes viņi jāpārrēķina visu laiku, jo tu nevari zināt, kurā brīdī kāds ieies paskatīties ciemu un tad būs jāattēlo dati. Ja piemēram grib kaut vai datus minūtes ietvaros, tad diennaktī var sanākt rēķināt šos datus 1440 reizes. Kaut patiesībā ciems dienas laikā vidēji tiek apskatīts 10-20 reizes un tā rezultātā jārēķina 10-20 reizes un pie tam iegūstot live datus. p.s. kas attiecas uz performanci utt var teorētiski paskatīties http://www.audience.gemius.lv/pages/pageviews .. rupji rēķinot visiem kopā kaut kā nesanāk cik "neprofesionālo apelsīnportālam" .. secinājumus izdari pats.. Nē nu tu salīdzināji. Protams, ka banānvalstī apelsīnportāls ir lielākais, to es neapstrīdu (malači), bet salīdzinošos lielumos pret citiem "normāliem" portāliem viņš tomēr ir salīdzinoši maziņš. Un no baumām, kuras dzirdētas par viņa virtuvi, mati ceļas stāvus. Edited September 9, 2008 by codez Link to comment Share on other sites More sharing options...
rpr Posted September 9, 2008 Report Share Posted September 9, 2008 piemērs labs, bet nu manuprāt, tagad atklājās, ka mēs jau runājam par vienu un to pašu. piemērs par resursu ievākšanu glabāt kā laiku jau vien norāda, ka resursu apjoms tiek rēķināts peč formulas, kur tiek izmantots laiks. un ja tā nav aritmētiskā progresija, tad tur baigo integrāli rēķināt nemaz nevajag. otra lieta jau ir tāda, ka vienam ciematam var augt, gan iedzīvotāji, gan resursi, gan armija, gan vēl citi rādītāji, kas savā starpā nav siastīti un ar vienu formulu nevarēs aprēķināt. līdz ar to sanāk, ka jāveido tāds garš masīvs ar formulām, kuras būs nepieciešams ģenerēt. līdz ar to sanāk, ka peiprasot lapu, ja tiek veikti vairāki aprēķini, tad lapa neielādēsies zem maģiskās 1s. bet lapa jau neielādēsies zem vienas sekudnes, ne jau dēļ tur 10 mazliet sarežģītākām formulām, bet tāpēc ka visus šos rezultātus vajag apstrādāt. sagatavot nepieciešamajā formātā, saglabāt vērtības tabulās utt. tur jau tas laiks aiziet. un lai to visu nooptimizētu, tad ik pēc kāda laiciņa tiek palaists krons. tā ka dzīvosim draudzīgi, jo visiem mums ir taisnība, tikai to visu vajag salikt kopā.. Link to comment Share on other sites More sharing options...
codez Posted September 9, 2008 Report Share Posted September 9, 2008 (edited) piemērs par resursu ievākšanu glabāt kā laiku jau vien norāda, ka resursu apjoms tiek rēķināts peč formulas, kur tiek izmantots laiks. un ja tā nav aritmētiskā progresija, tad tur baigo integrāli rēķināt nemaz nevajag. Man piemērs bija triviāls, bet noteikti būs arī sarežģītāki aprēķinu, kur integrālās formas formula nebūs tik intutīva. EDIT: Par šo vēl. Tavs aprakstītais variants ir: dx/dt = C integrējot x2-x1=C(t2-t1) x2=x1+C(t2-t1) šo formulu protams var dabūt arī neintegrējot, jo viņa ir tik vienkārša, ka to var intuitīvi izdomāt. Bet stipri šaubos, vai visur būs šādas linērās pārvērtības. Kā jau iepriekš parādīju, pat cita elementāra sakarība jau vairs nav lineāra. otra lieta jau ir tāda, ka vienam ciematam var augt, gan iedzīvotāji, gan resursi, gan armija, gan vēl citi rādītāji, kas savā starpā nav siastīti un ar vienu formulu nevarēs aprēķināt. līdz ar to sanāk, ka jāveido tāds garš masīvs ar formulām, kuras būs nepieciešams ģenerēt. līdz ar to sanāk, ka peiprasot lapu, ja tiek veikti vairāki aprēķini, tad lapa neielādēsies zem maģiskās 1s. Tāpat arī būs garš masīvs ar formulām, kuras jārēķina diferenciālā formā. Aprēķinu daudzums nemainās, mainās tikai biežums, kas ir arī galvenais ieguvums, nerēģinot regulāri, bet tikai tad, kad vajag. Un pat 100 šādas formulas nepārkāps 0,1 sekundi. bet lapa jau neielādēsies zem vienas sekudnes, ne jau dēļ tur 10 mazliet sarežģītākām formulām, bet tāpēc ka visus šos rezultātus vajag apstrādāt. sagatavot nepieciešamajā formātā, saglabāt vērtības tabulās utt. tur jau tas laiks aiziet. Datus jālasa no db arī, ja tie ir pirms tam sagatavoti. Praksē pierādījies, ka izmantojot dažādas kešošanas metodes, aprēķini nerada ievērojamu aizturi lapas ielādē. Edited September 9, 2008 by codez Link to comment Share on other sites More sharing options...
Roze Posted September 9, 2008 Report Share Posted September 9, 2008 Jā tikai tu aizmirsti par to, ka mūsdienu serveri ir ļoti jaudīgi un, šajā gadījumā runājot par spēli, tad tie bez problēmām paspēs veikt visus aprēķinus. Tā jauda ir ļoti nosacīta.. "Mūsdienās" aizvien lielākais bottlenecks salīdzinoši ar citām komponentēm ir disku IO .. Mēdz teikt, ka faktiski nakošais disks būs rams un rams būs networks (nu vai otrādi bija), jo pašreiz esošie disku risinājumi nedod iespēju tos aprēķinus veikt, bet ātrie datu nesēji ir ar salīdzinoši mazu kapacitāti un tās palielināšana ir nu diezgan dārga.. Man piemērs bija triviāls, bet noteikti būs arī sarežģītāki aprēķinu, kur integrālās formas formula nebūs tik intutīva.Mana sākotnējā posta nodoms faktiski nebija ieslīgt piemēru došanā kur un kā aprēķināt iedzīvotāju vairošanos, bet gan norādīt, ka izteiktais apgalvojums ir aplams (un aizvien ir), bet tad variants būtu apmēram šāds - pieņemsim, ka tev ir jāatrod kurā vietā/pakāpē pēc iedzīvotāju skaita ir konkrētais ciems attiecībā pret citiem 100, 1000, 100000 ciemiem... Jo nu piedomājot spēles mehāniku top100 ciemi varētu kļūt par pilsētām, pēdējie 100 par miestiem un resursu iegūšanas bonus mainās :) Šis gan ir samērā lineārs piemērs, jautrāki ir tie kur pasākums attīstās ģeometriskā progresijā.. Un no baumām, kuras dzirdētas par viņa virtuvi, mati ceļas stāvus.Baumas vienmēr ir savdabīgas / interesantas.. ( reku virtuve http://internetno.net/wp-content/uploads/2008/02/5.jpg :) )Ja nopietni tad nu kā ir tā ir.. Ja pie projekta strādā cilvēki ar dažādām zināšanām ne vienmēr ir iespējams izolēt vai radīt atdalītu smilškasti katram no programmētājiem, kas neafektētu pārējos.. Ja tev radīsies vai ir bijusi kādreiz iespēja strādāt pie projekta kuru labo un lauž vismaz padsmit koderi ar atsķirīgu skatu uz dzīvi un kvalitātes izpratni tad gan jau sapratīsi.. Link to comment Share on other sites More sharing options...
rpr Posted September 9, 2008 Report Share Posted September 9, 2008 codez, ok visu, var. katrā gadījumā, paldies par ideju. beidzot būs, kur integrāli izmantot reālā dzīvē. lai gan tos var izmantot arī sarežģītāku ģeometrisku figūru laukumu aprēķināšanā, praksē vēl nav nācies izmantot. varbūt šis piemēr būs biežāk pielietojams. jāiet pēc augstākās matemātikas grāmatas :D Link to comment Share on other sites More sharing options...
Recommended Posts