[KovacsUr]

Idézet: h1ghland3r - Dátum: 2005. szept. 23., péntek - 14:56

Latjatok feleim van akit csak a repikaja erdekel. A C# vs. Java haboru a konyhaban dol el.     

Ne is mondd... A legutóbbi Microsoft-bulin egy rántott papíros szendvics és egy Norbi ápdét volt az ellátmány. Remélem, a Lurdy-házban újra a szokott színvonalú étel- és italválaszték vár minket.

[h1ghland3r]

Idézet: KovacsUr - Dátum: 2005. szept. 28., szerda - 18:26

Ne is mondd... A legutóbbi Microsoft-bulin egy rántott papíros szendvics és egy Norbi ápdét volt az ellátmány. Remélem, a Lurdy-házban újra a szokott színvonalú étel- és italválaszték vár minket.

Igen a Lurdyban enis lattam egyszer nagy mikroszoftos felhajtast. Ott aztan tenyleg lehetett nagy tapolas.

[Hasse]

Idézet: h1ghland3r - Dátum: 2005. szept. 30., péntek - 16:51

Igen a Lurdyban enis lattam egyszer nagy mikroszoftos felhajtast. Ott aztan tenyleg lehetett nagy tapolas.

Ilyen téren most a Rational/IBM a tuti, egy jó kis Gundeles ebéd után akár azt is megbocsájtja az ember, hogy az 5000 eurós tesztizéjük .NET támogatása a basicre korlátozódik csak.

Apropó, nem tudtok véletlenül open source scriptelhetõ black box funkcionális teszttoolt, amivel applikációkat is lehet tesztelni?

[KovacsUr]

Idézet: Hasse - Dátum: 2005. szept. 30., péntek - 19:44

Ilyen téren most a Rational/IBM a tuti, egy jó kis Gundeles ebéd után akár azt is megbocsájtja az ember, hogy az 5000 eurós tesztizéjük .NET támogatása a basicre korlátozódik csak.

Egy licenc kerül 5000 euróba... 300 felhasználó szimulálásához már kellene kb. 30 belõle

[h1ghland3r]

Idézet: Hasse - Dátum: 2005. szept. 30., péntek - 17:44

Ilyen téren most a Rational/IBM a tuti, egy jó kis Gundeles ebéd után akár azt is megbocsájtja az ember, hogy az 5000 eurós tesztizéjük .NET támogatása a basicre korlátozódik csak.

Apropó, nem tudtok véletlenül open source scriptelhetõ black box funkcionális teszttoolt, amivel applikációkat is lehet tesztelni?

Kerestunk anno, de Windows ala nem talaltunk, szerintem Unixon is leginkabb penzert van.

[h1ghland3r]

Idézet: KovacsUr - Dátum: 2005. szept. 30., péntek - 18:31

Egy licenc kerül 5000 euróba... 300 felhasználó szimulálásához már kellene kb. 30 belõle

Bakker 5000*30 euroert mar rendesen meg lehetne irni a kodot.

[TC2]

Idézet: KovacsUr - Dátum: 2005. szept. 28., szerda - 18:26

Ne is mondd... A legutóbbi Microsoft-bulin egy rántott papíros szendvics és egy Norbi ápdét volt az ellátmány. Remélem, a Lurdy-házban újra a szokott színvonalú étel- és italválaszték vár minket.

Hát igen...a döntéshozáshoz kellenek az alapok, ami alapján egy szoftverterméket, vagy egy beszállítót megítél az ember.  ....és ez mi más lenne, mint a kenõkaja ?! :D:D:D:D:D

[ed101]

Idézet: Haderach - Dátum: 2005. aug. 4., csütörtök - 8:51

ezzel a teszttel csak az a baj, amit mar az elozo linkelt cikkben is kiveseztek: a szintetikus tesztek itt semennyire sem mervadok...

Ez az egesz java/c++/gc/stb tepelodes nevetseges. Szenvedtek a sebessegen mikozben szo sem esik Partial Evaluation-rol, hogy egy dolgot emlitsek, amivel nagysagrendeket lehet gyorsitani. Es se a javanak se a c++-nak semmi koze a PE-hez, kiveve par szanalmas probalkozast.

Azonkivul miert is az a legfontosabb manapsag, hogy milyen gyors egy for ciklus?! Nem erdekesebb inkabb az, hogy milyen konnyen lehet megoldani problemakat? Lispben egy entitas adatbazisbol betoltese egy egy web-szerveren megjelenitese 60-80 sor, aminek a fele a modul system setup-ja! Es nem azert ennyi, mert egy komponens csinalja az egeszet...

Neumann-t istenitik, hogy mekkora okos volt, es egyik kitetele az volt, hogy code=data. Na nezzunk csak ra a mai programnyelvekre, hogy az ASM-en, es nehany egzotikus nyelven (Lisp, Slate, stb) kivul hol igaz ez? C++, Java?

Nem veletlen, hogy az igazan szamitasigenyes es komplex programokat (csillagaszat, stb) legtobb helyen Lisp-ben vagy mas reflexiv nyelvben irjak. Mivel bizonyos algoritmusoknak a futasi sebessege tobb nagysagrenddel tud gyorsulni az input adatok fuggvenyeben. (pl. egyes helyeken mas algoritmust hasznalhat) Ezt persze bele lehet if-elni a c/java programokba is, csak abbol lesznek azok az attekinthetetlen, kezzel optimalizalt bugos szarok, amikkel a munkahelyemen is kuzdeni kell...

Az erdeklodoknek tovabbi olvasmany: tunes.org
http://www.paulgraha...m/articles.html pl a Beating the Averages, Succintness Is Power, stb

PS: volt ido, amikor en is azt hittem, hogy a C++ qrva jo nyelv... es, hogy a Lisp valami vicc.

Vegezetul egy mai Lisp fordito (LispWorks, de CMUCL, vagy SBCL ugyanezt tudja es ingyenes)...

(defun fast-factorial (n)
  "A tail-recursive version of factorial."
  (declare (type fixnum N))
  (declare (optimize (speed 3) (safety 0) (debug 0) (space 0)))
  (the fixnum (fast-factorial-aux N 1)))

(defun fast-factorial-aux (N A)
  "Multiply A by the factorial of N."
  (declare (type fixnum N A))
  (declare (optimize (speed 3) (safety 0) (debug 0) (space 0)))
  (the fixnum (if (= N 1)
                  A
                (fast-factorial-aux (- N 1) (* N A)))))

CL-USER 43 > (disassemble 'fast-factorial)
20685412:
       0:      55               push  ebp
       1:      89E5             move  ebp, esp
       3:      FF7500           push  [ebp]
       6:      83ED04           sub   ebp, 4
       9:      8B7508           move  esi, [ebp+8]
      12:      897504           move  [ebp+4], esi
      15:      894508           move  [ebp+8], eax
      18:      B502             moveb ch, 2
      20:      B800010000       move  eax, 100
      25:      C9               leave 
      26:      FF25702D6C21     jmp   [216C2D70]      ; FAST-FACTORIAL-AUX
      32:      90               nop   
      33:      90               nop   
NIL

CL-USER 44 > (disassemble 'fast-factorial-aux)
206AEEA2:
       0:      55               push  ebp
       1:      89E5             move  ebp, esp
       3:      8B7D08           move  edi, [ebp+8]
       6:      81FF00010000     cmp   edi, 100
      12:      7505             jne   L1
      14:      FD               std   
      15:      C9               leave 
      16:      C20400           ret   4
L1:   19:      89FB             move  ebx, edi
      21:      81EB00010000     sub   ebx, 100
      27:      C1F808           sar   eax, 8
      30:      0FAFC7           imul  eax, edi
      33:      895D08           move  [ebp+8], ebx
      36:      B502             moveb ch, 2
      38:      C9               leave 
      39:      FF25702D6C21     jmp   [216C2D70]      ; FAST-FACTORIAL-AUX
      45:      90               nop   
NIL

[h1ghland3r]

Idézet: ed101 - Dátum: 2005. okt. 6., csütörtök - 11:22

Ez az egesz java/c++/gc/stb tepelodes nevetseges. Szenvedtek a sebessegen mikozben szo sem esik Partial Evaluation-rol, hogy egy dolgot emlitsek, amivel nagysagrendeket lehet gyorsitani. Es se a javanak se a c++-nak semmi koze a PE-hez, kiveve par szanalmas probalkozast.

Azonkivul miert is az a legfontosabb manapsag, hogy milyen gyors egy for ciklus?! Nem erdekesebb inkabb az, hogy milyen konnyen lehet megoldani problemakat? Lispben egy entitas adatbazisbol betoltese egy egy web-szerveren megjelenitese 60-80 sor, aminek a fele a modul system setup-ja! Es nem azert ennyi, mert egy komponens csinalja az egeszet...

Neumann-t istenitik, hogy mekkora okos volt, es egyik kitetele az volt, hogy code=data. Na nezzunk csak ra a mai programnyelvekre, hogy az ASM-en, es nehany egzotikus nyelven (Lisp, Slate, stb) kivul hol igaz ez? C++, Java?

Nem veletlen, hogy az igazan szamitasigenyes es komplex programokat (csillagaszat, stb) legtobb helyen Lisp-ben vagy mas reflexiv nyelvben irjak. Mivel bizonyos algoritmusoknak a futasi sebessege tobb nagysagrenddel tud gyorsulni az input adatok fuggvenyeben. (pl. egyes helyeken mas algoritmust hasznalhat) Ezt persze bele lehet if-elni a c/java programokba is, csak abbol lesznek azok az attekinthetetlen, kezzel optimalizalt bugos szarok, amikkel a munkahelyemen is kuzdeni kell...

Az erdeklodoknek tovabbi olvasmany: tunes.org
http://www.paulgraha...m/articles.html pl a Beating the Averages, Succintness Is Power, stb

PS: volt ido, amikor en is azt hittem, hogy a C++ qrva jo nyelv... es, hogy a Lisp valami vicc.

Vegezetul egy mai Lisp fordito (LispWorks, de CMUCL, vagy SBCL ugyanezt tudja es ingyenes)...

(defun fast-factorial (n)
  "A tail-recursive version of factorial."
  (declare (type fixnum N))
  (declare (optimize (speed 3) (safety 0) (debug 0) (space 0)))
  (the fixnum (fast-factorial-aux N 1)))

(defun fast-factorial-aux (N A)
  "Multiply A by the factorial of N."
  (declare (type fixnum N A))
  (declare (optimize (speed 3) (safety 0) (debug 0) (space 0)))
  (the fixnum (if (= N 1)
                  A
                (fast-factorial-aux (- N 1) (* N A)))))

CL-USER 43 > (disassemble 'fast-factorial)
20685412:
       0:      55               push  ebp
       1:      89E5             move  ebp, esp
       3:      FF7500           push  [ebp]
       6:      83ED04           sub   ebp, 4
       9:      8B7508           move  esi, [ebp+8]
      12:      897504           move  [ebp+4], esi
      15:      894508           move  [ebp+8], eax
      18:      B502             moveb ch, 2
      20:      B800010000       move  eax, 100
      25:      C9               leave 
      26:      FF25702D6C21     jmp   [216C2D70]      ; FAST-FACTORIAL-AUX
      32:      90               nop   
      33:      90               nop   
NIL

CL-USER 44 > (disassemble 'fast-factorial-aux)
206AEEA2:
       0:      55               push  ebp
       1:      89E5             move  ebp, esp
       3:      8B7D08           move  edi, [ebp+8]
       6:      81FF00010000     cmp   edi, 100
      12:      7505             jne   L1
      14:      FD               std   
      15:      C9               leave 
      16:      C20400           ret   4
L1:   19:      89FB             move  ebx, edi
      21:      81EB00010000     sub   ebx, 100
      27:      C1F808           sar   eax, 8
      30:      0FAFC7           imul  eax, edi
      33:      895D08           move  [ebp+8], ebx
      36:      B502             moveb ch, 2
      38:      C9               leave 
      39:      FF25702D6C21     jmp   [216C2D70]      ; FAST-FACTORIAL-AUX
      45:      90               nop   
NIL

No lassuk szepen sorban.

A Neumann-elv szamitogep-architekturalis alapvetes, semmi koze nem volt a programozasi nyelvekhez. A magas szintu nyelvekhez meg tutira nem, mert akkor meg azok nemigen leteztek. Vajh miert van NX bit szeruseg az osszes fejlett architekturaban? Azert mert a adat=program alapelv vegsokig kiaknazasabol mar csak a virus- es exploit irok profitaltak.

Az, hogy manapsag mi a fejlesztesi cel, az valtozo. Van, ahol a vegso termek sebessege, van, ahol a fejlesztes idot probaljak inkabb leszoritani. Igy aztan a for ciklus optimalizalasa lehet elsodleges cel, de lehet toklenyegtelen problema.

Es akkor megint kanyarodjunk vissza a Fortran temakorhoz (bar eleg maceras peldakent citalni, egy olyan vitaban, ahol fejlettebnel-fejlettebb programozasi nyelveket is lefikazunk  )! A fejemet merem ra tenni, hogy meg mindig a C/Fortran/Assembly programok uraljak a HPC-supercomputing teruletet. Valszeg a Lisp marginalis jelentosegu ezekhez kepest. A Fortran szerintem eppen a primitivsege miatt nepszeru. Sokkal tobb biztonsagos optimalizaciot engedhet meg maganak a forditoprogram. Mivel nincsenek pointerek, ezert a pointer aliasing problema fel sem merul. Az pedig nagyon sokszor akadalyozza a konzervativ optimalizaciot.

Lehet, hogy egy faktorialis problemat elegansan meg tudsz oldani Lispben, de manapsag mar nem ez a feladat a nagyszamitogepeknek. Masfelol felmerulnek olyan kerdesek HPC temakorben, amin altalaban az ilyen nyelvek elhasalnak, pl. a parhuzamos vegrehajtas tamogatasa. Nem ketlem, hogy esetleg a Lisp megvalositas tud ilyet, de komoly fenntartasaim vannak azzal kapcsolatban, hogy hogyan viszonyul ezeknek a teljesitmenye az MPI, SHMEM, OpenMP, franctudjamihez kepest. Mit produkal a te csodaLisp forditod egy 5-20-100-1000 node-bol allo clusteren? Az sem biztos, hogy meg tudja hajtani rendesen.

Az asztrofizikai meg egyeb hardcore szamitasi programok irasakor senki nem fog elpirulni, ha ossze kell ganyolni a programot if-ekkel. Sokkal komplikaltabb a problema maga, minthogy azon aggodjanak, hogy hasznalnak-e aritmetikai if-et, vagy nem, tegyenek-e bele goto-t, vagy nem (altalaban szoktak       ), es ha igen, akkor mennyi if-et agyaznak egymasba. Nem kezdo programozok szakterulete ez, a profik meg gondolom jol elboldogulnak vele.

[ed101]

Idézet

A Neumann-elv szamitogep-architekturalis alapvetes, semmi koze nem volt a programozasi nyelvekhez. A magas szintu nyelvekhez meg tutira nem, mert akkor meg azok nemigen leteztek....

Csak Computing Model-el vannak, amik tobbsege bizonyos szempontbol ugyanolyan (pl. Turing ekvivalens-e) mas szempontokbol meg teljesen mas (altalaban szubjektiv emberi dolgokban). Neumann elve, hogy kod=adat ugyanazt az elvi kaput nyitja ki a processor computing model-jeben es egy "magasszintu" nyelven. Nem reszleteznem, de pl ettol van eselyed compilert irni. Es a compiler itt nem egy C++ compiler, hanem akar egy project egy reszfeledatanak a megoldasahoz kifejlesztett DSL compilere. Es ha innen ugrunk egybol a vegkovetkeztetesre, akkor kod=adat-bol kovetkezik, hogy raszabhatod a programnyelvedet a problemara es nem forditva kell csinalnod (ahogy ma a tobbseg teszi). pl: Universal Composition

Idézet

Az, hogy manapsag mi a fejlesztesi cel, az valtozo. Van, ahol a vegso termek sebessege, van, ahol a fejlesztes idot probaljak inkabb leszoritani. Igy aztan a for ciklus optimalizalasa lehet elsodleges cel, de lehet toklenyegtelen problema.

En nem akartam a Lisp-et nyomni (nem is vagyok profi Lisp-es!), csak felhoztam peldanak, hogy attol, hogy a Computing Model-ed "magasszintu", attol meg ha kell le tudsz nyulni melyre... (lsd.: disassemblalt factorial lisp-ben...) Forditva viszont eselyed sincs. Es aki programozott eleget az belatta reg, hogy "melyre nyulni" ritkan kell. Es ha most valaki ugy gondolja, hogy persze, de ha szamit a meret, stb (mobil, mas embedded alkalmazasok), akkor az keressen ra az Embedded Smalltalk-ra pl. Vagy nezze meg, hogy hogyan van a Slate, vagy egyes Lisp implementaciok a sajat nyelvukon megirva. Ha kicsit stilizalni akarok: leereszkedni mindig konnyebb mint felemelkedni... 

Idézet

Valszeg a Lisp marginalis jelentosegu ezekhez kepest. A Fortran szerintem eppen a primitivsege miatt nepszeru. Sokkal tobb biztonsagos optimalizaciot engedhet meg maganak a forditoprogram.

Nem ment at, amit az elozo postban irtam... Szerinted mitol lesz gyorsabb egy program? Attol, hogy a fordito nehany integer es float muvelet sorrendjet atrendezi, vagy nehany valtozot regiszterben tart, szemben azzal, hogy a program felet le sem futtatja, mert a bemeno adatok alapjan nincs is azokra az agakra szukseg. En itt olyanokrol beszelek, hogy az oprendszeremen kikapcsolom a security-t es ettol minden x%-al gyorsabb lesz... Ma meg sci-fi-nek hangzik, pedig vannak emberek akik ilyenekkel jatszanak. Sajnos magyar egyetemeken pascal-t tanitanak, meg c-t...

Es, hogy ne tunjon sci-fi-nek amit beszelek, a Lisp-es regexp engine ugy mukodik, hogy a beadott regexp kifejezesbol (DSL program) fordit Lisp kodot, amit a Lisp fordito asm-re fordit es az a kod fogja feldolgozni vegul a beadott string-et.

Lisp regexp benchmark Perl-hez kepest

Felhivnam a figyelmet a Lisp-es oszlopban nehany helyen talalhato 0.0000 ertekre: ezek azok az esetek, amikor teljesen kioptimalizalt valamit.

Idézet

Lehet, hogy egy faktorialis problemat elegansan meg tudsz oldani Lispben, de manapsag mar nem ez a feladat a nagyszamitogepeknek...

Ott altalaban olyan emberek dolgoznak, akik megcsinaljak a sajat Computing Model-juket (hiszen, ha a CM passzol a problemahoz, akkor a problema megoldasa sokkal egyszerubb). Es elhiheted, hogy altalaban nem C-bol indulnak ki... Hozza kell tennem, hogy Lisp-hez nem ismerek (en!) ilyen komponenseket.

Idézet

Mit produkal a te csodaLisp forditod egy 5-20-100-1000 node-bol allo clusteren?

random google result

De fontos megjegyezni, hogy a fordito egyedul soha nem fogja neked megoldani a cluster kezelest... Ugy kell megoldanod a problemadat, hogy clusterezheto legyen. (Visszautalnek a megfelelo Computing Model fontossagara) Kerdes hol milyen konnyen tudod kialakitani azt.

Idézet

Az asztrofizikai meg egyeb hardcore szamitasi programok irasakor senki nem fog elpirulni, ha ossze kell ganyolni a programot if-ekkel. Sokkal komplikaltabb a problema maga, minthogy azon aggodjanak, hogy hasznalnak-e aritmetikai if-et, vagy nem, tegyenek-e bele goto-t, vagy nem (altalaban szoktak       ), es ha igen, akkor mennyi if-et agyaznak egymasba. Nem kezdo programozok szakterulete ez, a profik meg gondolom jol elboldogulnak vele.

En beszeltem sok sok profival... es egyik sem volt ezen a velemenyen. A goto agyatlan tiltasa C-ben ketsegkivul buta dolog. (Hiszen a programozas pont a vegtelen lehetosegekrol szol, miert ne lehetne neha eppen a goto a megoldas? Persze, itt a "C-ben" nem veletlenul bold...)

De az az "ossze kell ganyolni a programot if-ekkel" valojaban sokkal tobbet jelent, viszont en meguntam ezt a post-ot. Es mar kezd elmulni a megfazasom is, szoval megyek inkabb a szabadba...

Akit erdekel a tema, annak hagytam eleg linket... En a tunes.org-ot vegigolvastam vagy 3x, es ha eljon a 4. olvasas, meg mindig lesz benne ujdonsag szamomra.

PS: "minel tobbet tudsz, annal jobban latod mily' keves is az"

Szerkesztette: ed101 2005. 10. 07. 14:09 -kor

[Hasse]

Idézet: ed101 - Dátum: 2005. okt. 7., péntek - 14:59

En nem akartam a Lisp-et nyomni (nem is vagyok profi Lisp-es!), csak felhoztam peldanak, hogy attol, hogy a Computing Model-ed "magasszintu", attol meg ha kell le tudsz nyulni melyre... (lsd.: disassemblalt factorial lisp-ben...) Forditva viszont eselyed sincs. Es aki programozott eleget az belatta reg, hogy "melyre nyulni" ritkan kell. Es ha most valaki ugy gondolja, hogy persze, de ha szamit a meret, stb (mobil, mas embedded alkalmazasok), akkor az keressen ra az Embedded Smalltalk-ra pl. Vagy nezze meg, hogy hogyan van a Slate, vagy egyes Lisp implementaciok a sajat nyelvukon megirva. Ha kicsit stilizalni akarok: leereszkedni mindig konnyebb mint felemelkedni... 

E miatt a skalazhatosag miatt is valhatott kvazi ipari szabvannya a C++.

[Dead6nail]

Idézet: ed101 - Dátum: 2005. okt. 7., péntek - 14:59

Akit erdekel a tema, annak hagytam eleg linket... En a tunes.org-ot vegigolvastam vagy 3x, es ha eljon a 4. olvasas, meg mindig lesz benne ujdonsag szamomra.

PS: "minel tobbet tudsz, annal jobban latod mily' keves is az"

Sokat emlegetted a tunes.org-ot, ezért megnéztem. Õszintén szólva az egész kicsit "zavarosnak" tûnik. Az elsõ benyomásom az volt, hogy hülye vagyok. A második, hogy ez valami idegesítõ management szöveg. Pár fickó összedobott egy oldalt, ahova felraktak pár jelmondatot, hogy naon tudományosnak tûnjön, de ezenkívül más céljuk nincs. Ha te érted mit akarnak, légyszíves írj egy pár sort róla, mert érdekel a dolog.

Szerkesztette: Dead6nail 2005. 10. 09. 00:37 -kor

[j.cs.]

GC vs malloc  (meg csak a "conclusions"-t volt idom atnezni), friss anyag, az okt 16-20-i San Diego-i OOPSLA'05-on adjak elo a szerzok:

http://www.cs.umass..../gcvsmalloc.pdf

"We compare explicit memory management to both copying and non-copying garbage collectors across a range of benchmarks, and include non-simulated runs that validate our results. Our results quantify the time-space tradeoff of garbage collection: with five times as much memory, the Appel-style generational garbage collector matches the performance of explicit memory management. With only three times as much memory, it runs on average 17% slower than explicit memory management. However, with only twice as much memory, garbage collection degrades performance by nearly 70%. When physical memory is scarce, paging causes garbage collection to run an order of magnitude slower than explicit memory management."


Vagyis a GC gyorsabb lehet a kezi memoriamenedzsmentnel, ha lenyegesen nagyobb heap-et engedunk meg, mint amekkorara szuksegunk lenne (5x).

Szep munkanak tunik...

[ed101]

Idézet: Dead6nail - Dátum: 2005. okt. 8., szombat - 23:36

Sokat emlegetted a tunes.org-ot, ezért megnéztem. Õszintén szólva az egész kicsit "zavarosnak" tûnik. Az elsõ benyomásom az volt, hogy hülye vagyok. A második, hogy ez valami idegesítõ management szöveg. Pár fickó összedobott egy oldalt, ahova felraktak pár jelmondatot, hogy naon tudományosnak tûnjön, de ezenkívül más céljuk nincs. Ha te érted mit akarnak, légyszíves írj egy pár sort róla, mert érdekel a dolog.

nehez ugy... anno elkezdtem egy cikket errol a chip-be, de az jo reg volt es be sem fejeztem (reszben kulturalis okokbol, reszben meg kevesnek ereztem magam hozza). arra viszont emlekszem, hogy nekem is sci-fi volt a site elso olvasasra. nem beszelve arrol, hogy van ott azert sok kodos dolog is...

viszont arra is emlekszem, hogy csak a Glossary elolvasasa magaban sokat valtoztatott a vilagkepemen. kezdd talan azzal es ha tetszik, onnan lehet sokfele tovabbmenni.

[ed101]

Idézet: ed101 - Dátum: 2005. okt. 10., hétfõ - 12:20

viszont arra is emlekszem, hogy csak a Glossary elolvasasa magaban sokat valtoztatott a vilagkepemen. kezdd talan azzal es ha tetszik, onnan lehet sokfele tovabbmenni.

ja, es a Review subproject is erdekes abbol a szempontbol, hogy mi mindent atneztek/ismernek. ez a site nehany (<10) ember munkaja!

jo nagy lista van a programnyelvekrol is.

[Dead6nail]

Idézet: ed101 - Dátum: 2005. okt. 10., hétfõ - 14:20

nehez ugy... anno elkezdtem egy cikket errol a chip-be, de az jo reg volt es be sem fejeztem (reszben kulturalis okokbol, reszben meg kevesnek ereztem magam hozza). arra viszont emlekszem, hogy nekem is sci-fi volt a site elso olvasasra. nem beszelve arrol, hogy van ott azert sok kodos dolog is...

viszont arra is emlekszem, hogy csak a Glossary elolvasasa magaban sokat valtoztatott a vilagkepemen. kezdd talan azzal es ha tetszik, onnan lehet sokfele tovabbmenni.

Meg fogom nézni, mert érdekes lehet a dolog. Mindenesetre az ilyen ködös halandzsák mögött gyakran az áltudományosság rejlik. Ahogy Einstein mondta, ha valamit igazán értesz, akkor azt a nagymamádnak is eltudod magyarázni. Szóval a fenntartásaim még megvannak.

[h1ghland3r]

Idézet: ed101 - Dátum: 2005. okt. 7., péntek - 12:59

Csak Computing Model-el vannak, amik tobbsege bizonyos szempontbol ugyanolyan (pl. Turing ekvivalens-e) mas szempontokbol meg teljesen mas (altalaban szubjektiv emberi dolgokban). Neumann elve, hogy kod=adat ugyanazt az elvi kaput nyitja ki a processor computing model-jeben es egy "magasszintu" nyelven. Nem reszleteznem, de pl ettol van eselyed compilert irni. Es a compiler itt nem egy C++ compiler, hanem akar egy project egy reszfeledatanak a megoldasahoz kifejlesztett DSL compilere. Es ha innen ugrunk egybol a vegkovetkeztetesre, akkor kod=adat-bol kovetkezik, hogy raszabhatod a programnyelvedet a problemara es nem forditva kell csinalnod (ahogy ma a tobbseg teszi). pl: Universal Composition



En nem akartam a Lisp-et nyomni (nem is vagyok profi Lisp-es!), csak felhoztam peldanak, hogy attol, hogy a Computing Model-ed "magasszintu", attol meg ha kell le tudsz nyulni melyre... (lsd.: disassemblalt factorial lisp-ben...) Forditva viszont eselyed sincs. Es aki programozott eleget az belatta reg, hogy "melyre nyulni" ritkan kell. Es ha most valaki ugy gondolja, hogy persze, de ha szamit a meret, stb (mobil, mas embedded alkalmazasok), akkor az keressen ra az Embedded Smalltalk-ra pl. Vagy nezze meg, hogy hogyan van a Slate, vagy egyes Lisp implementaciok a sajat nyelvukon megirva. Ha kicsit stilizalni akarok: leereszkedni mindig konnyebb mint felemelkedni... 



Nem ment at, amit az elozo postban irtam... Szerinted mitol lesz gyorsabb egy program? Attol, hogy a fordito nehany integer es float muvelet sorrendjet atrendezi, vagy nehany valtozot regiszterben tart, szemben azzal, hogy a program felet le sem futtatja, mert a bemeno adatok alapjan nincs is azokra az agakra szukseg. En itt olyanokrol beszelek, hogy az oprendszeremen kikapcsolom a security-t es ettol minden x%-al gyorsabb lesz... Ma meg sci-fi-nek hangzik, pedig vannak emberek akik ilyenekkel jatszanak. Sajnos magyar egyetemeken pascal-t tanitanak, meg c-t...

Es, hogy ne tunjon sci-fi-nek amit beszelek, a Lisp-es regexp engine ugy mukodik, hogy a beadott regexp kifejezesbol (DSL program) fordit Lisp kodot, amit a Lisp fordito asm-re fordit es az a kod fogja feldolgozni vegul a beadott string-et.

Lisp regexp benchmark Perl-hez kepest

Felhivnam a figyelmet a Lisp-es oszlopban nehany helyen talalhato 0.0000 ertekre: ezek azok az esetek, amikor teljesen kioptimalizalt valamit.



Ott altalaban olyan emberek dolgoznak, akik megcsinaljak a sajat Computing Model-juket (hiszen, ha a CM passzol a problemahoz, akkor a problema megoldasa sokkal egyszerubb). Es elhiheted, hogy altalaban nem C-bol indulnak ki... Hozza kell tennem, hogy Lisp-hez nem ismerek (en!) ilyen komponenseket.



random google result

De fontos megjegyezni, hogy a fordito egyedul soha nem fogja neked megoldani a cluster kezelest... Ugy kell megoldanod a problemadat, hogy clusterezheto legyen. (Visszautalnek a megfelelo Computing Model fontossagara) Kerdes hol milyen konnyen tudod kialakitani azt.



En beszeltem sok sok profival... es egyik sem volt ezen a velemenyen. A goto agyatlan tiltasa C-ben ketsegkivul buta dolog. (Hiszen a programozas pont a vegtelen lehetosegekrol szol, miert ne lehetne neha eppen a goto a megoldas? Persze, itt a "C-ben" nem veletlenul bold...)

De az az "ossze kell ganyolni a programot if-ekkel" valojaban sokkal tobbet jelent, viszont en meguntam ezt a post-ot. Es mar kezd elmulni a megfazasom is, szoval megyek inkabb a szabadba...

Akit erdekel a tema, annak hagytam eleg linket... En a tunes.org-ot vegigolvastam vagy 3x, es ha eljon a 4. olvasas, meg mindig lesz benne ujdonsag szamomra.

PS: "minel tobbet tudsz, annal jobban latod mily' keves is az"

Az elso reszhez nem szolok semmit, at kellene olvasnom a Tunes.org-ot. Majd megnezem.

Halistennek a magyar egyetemeken pascal-t meg c-t tanitanak.... Tanithatnak ezt is, de akkor a vegzosok jo esellyel munkanelkulikent kolan meg kutyatapon elnenek es egesz nap nezhetnek a tevet otthon. Mar ne haragudj de itt most tiz ember (te mondtad) munkaja all szemben egy tobbszaz milliard dollaros uzlettel, es egy irgalmatlan meretu infrastrukturaval. Lehet, hogy ok a jovo, de abba szep jovobe el is kellene erni. Es ameddig tunes-os barataink whitepaper-t meg wiki-t gyartanak, az Internetnek mennie kell, es valamit a befektetok is szeretnenek latni a penzukbol, szuksegunk lesz meteorologiai elorejelzesekre, uj gyogyszerekre .... A kutatok foglalkozzanak a Tunes temaival (mar amennyiben tenyleg nem humbug), de az egyetemrol kieso vegzosoknek "sajnos" a jelenen es a kozeljovon kell dolgozniuk... Azert lassuk be a papir sokmindent elbir es azon az oldalon meg konkret (piaci-szakmai szempontbol ertekelheto) eredmenyek nemigen vannak. Tudomanyos eredmenyek lehetnek, de azok csak a kutatokat erdeklik.

Analog peldakent az jut eszembe, amikor valaki levezeti annak a lehetoseget, hogy fereglyukakon v. fekete lyukakon keresztul milyen klasszul lehetne idoben v. terben ugrani. Megsem veri senki sem az asztalt, hogy minden mozdithato urjarmuvel celozzuk be a legkozelebbi fekete lyukat es hajra....

Az, hogy a Lisp megveri a Perl sebessegben kb. olyan hir, minthogy nagyanyam finomabb porkoltet foz, mint en... Furcsa lenne, ha nem. Sot tipikusan a Perl-t majdnem ertelmetlen benchmarkolni (nem azert szeretik, mert szep es gyors, sot altalaban azert nem szeretik, mert lassu es ronda). De ha csinalok egy olyan benchmarkot, amiben azt nezem, hogy melyik nyelvhez hany csomag erheto el, akkor valszeg a CPAN egy sarkanyfarokcsapassal kiutne az Lispes-funkcionalis hobelevancot. Megintcsak egyoldalu megkozeliteset lathattuk a dolgoknak, ami ilyen nagyivu elkepzelesek eseten igencsak gyanus.

A masik bevagott linked meg abszolut lol. Kerestel google-ben es el sem olvastad (vagy ha elolvastad, akkor nem fogtad fol). Ekkora felkeszultseggel az ufokrol szoktak vitatkozni. Keresnek google-ben egy kepet es eldisputalnak arrol, hogy az kalap, frizbi v. urhajo ET-vel. Mindegy en elolvastam. Ez valami projekttervezet, megintcsak sehol nem latszanak eredmenyek. Az eroforras reszben egy 4-node-bol allo cluster megepiteset tervezik. Nem tudom, hogy hol toltotted az elmult par evet, de ha elcsattogsz barmelyik komolyabb gyarto oldalara akkor lathatod, hogy manapsag a tobb 10-100-1000 node-bol allo furtokre is vannak jol skalazodo alkalmazasok. Namost megneztem a cikk vegen a hivatkozasokat. A legujabb talan 99-es (ok maguk nem irtak datumot a cikkre, pedig jol jonne neha). A leirt tervezetbol en arra kovetkeztetek, hogy kb. 3-4 eves a cikk. Miert nem az eredmenyeiket mutatod, amikor leirtak, hogy 2 ev alatt vegeznek?

A franya reszletekkel is kellene foglalkozni es azt is leirni, hogy mi van most, mi lesz 1-2-5-10 ev mulva. Legalabb hozzavetolegesen.

Szerkesztette: h1ghland3r 2005. 10. 12. 08:15 -kor

[Nevergone]

Akkor sem nyitok új topicot, mert minek... 
Szóval, egy érdekes problémám lenne C nyelvben.

Adott egy konstans, amelyet az elõfordító dolgoz fel, és ezt kellene behelyetessítenem szövegként egy sztringliterálba. Valahogy így:

#define FOO 300
int main () {
  printf ("Ize"FOO"Ize"\n);
}

És ugye, én azt szeretném, ha a kimenet ez lenne: Ize300Ize
A probléma az, hogy az elõfordító így nem akarja az igazságot, mert ugye szám. Úgy elfogadná, hogy a konstans értékét idézõjelek közé tenném, csak az azért nem lenne jó, mert máshol pedig számolok vele, és akkor ott kellene elöbb számmá konvertálgatni mindig, brrr...

Van valami ötletetek, vagy törõdjek bele inkább...? 

[cx.core]

#define FOO 300
#define STR(x) #x
#define IZELIT(x) "Ize"STR(x)"Ize\n"
int main()
{
 printf(IZELIT(FOO));
}

Csunyan buta.

szerk.:

#define FOO 300
#define STR0(x) #x
#define STR(x) STR0(x)
int main()
{
 printf("Ize"STR(FOO)"Ize\n");
}

printf("Ize%uIze\n",FOO);

Ez miert nem jo amugy?

Szerkesztette: cx.core 2005. 10. 12. 16:41 -kor

[Nevergone]

Idézet: cx.core - Dátum: 2005. okt. 12., szerda - 17:31

printf("Ize%uIze\n",FOO);

Ez miert nem jo amugy?

Mert a printf -et csak egy gyors példának írtam ide, de olyan helyre kell, ahol nem lehet "így" formázgatni, mondjuk nem is lenne értelme. A függvénynek egy char* paramétere lehet, oszt' sanyi. Vagyis ebbõl kell kihozni, amit lehet. Ilyenkor mindig bánkódom picit, hogy az sprintf visszatérési értéke nem az új sztringre mutató pointer. Bár, ha mindegyik konstans (azaz már fordítási idõben tudható az értéke), akkor igazán lehetne valami normális módszer...