[Ytse]

idézet:

---

The University of Texas at Austin and IBM Research, based on support from the Defense Advanced Research Projects Agency (DARPA), will collaborate to produce an adaptive, high-performance microprocessor that could revolutionize computing. The university team has conceived a new architecture, called TRIPS (Tera-op Reliable Intelligently-adaptive Processing System), that is designed to provide supercomputer performance on a single chip. Researchers at IBM's Austin Research Lab are working closely with The University of Texas at Austin team to develop a number of the relevant technology innovations necessary to realize such systems, and engagements are underway to ultimately commercialize the results.

The TRIPS architecture is designed to provide supercomputer performance on a single chip, ultimately scaling to deliver more than one trillion operations per second by 2010. In addition, the system will offer unprecedented flexibility to work well with many different types of software applications including desktop, signal processing, graphics, server, and scientific applications. This flexibility may allow a single TRIPS chip to serve several different processor markets, instead of current approaches that use unique and specialized processors for each market.

The fundamental innovation in the TRIPS design is its "block-oriented execution." Instead of operating on only a few computations at a time, the TRIPS processor operates on large blocks of computations mapped to an array of execution units on the chip. This approach allows many more instructions to execute in parallel, thus offering higher performance. These computation arrays include support for "polymorphism," which adapts them to match the type of software application currently running on the hardware. The IBM Research team is focused on the optimization of commercial computing applications for this novel architecture. The IBM team is also exploring new circuit and chip-design methodology innovations to enable this class of highly-configurable future chips.

The team will work for 30 months to develop a prototype microprocessor and system containing up to four processor cores, each capable of executing 16 operations per clock cycle, and a uniquely partitioned cache structure designed to offer higher performance than traditional approaches. The chip will contain over 250 million transistors, and will operate at 500 MHz. The goal is to demonstrate the feasibility of a full-scale industrial development that could offer a 10 GHz chip capable of executing over a trillion instructions per second. The joint University of Texas at Austin / IBM Research team is consulting with IBM Microelectronics on initial chip-design considerations, and it is expected that IBM Microelectronics will be the physical-design and fabrication partner for the TRIPS chip.

This research collaboration is being facilitated by an IBM Shared University Research (SUR) Award of a Linux-based IBM eServer xSeries computing cluster, which will help provide the bandwidth and computational capabilities required to accurately simulate and verify the advanced TRIPS processor design. The Linux cluster also will enable researchers to model large server workloads running on a multi-chip TRIPS system, improving the understanding of system-level design requirements of diverse supercomputing environments. IBM's SUR program awards computing equipment to colleges, universities and institutions of higher education around the world to facilitate research projects in areas of mutual interest.

Construction of the TRIPS prototype system is supported by a total of $11.1 million in funding from DARPA. The University of Texas at Austin scientists expect to have TRIPS prototype chips and systems running in their laboratory by December 2005.[/quote]

Tud errõl valaki részletekkel, esetleg linkekkel szolgálni? Ez a TRIPS dolog nekem nagyon VLIW-szagú, sõt még a Crusoe is eszembe jut róla.

[Vajonész]

ftp://ftp.cs.utexas.edu/pub/dburger/paper...SCA03_trips.pdf

[SFIJ]

Ytse igaz nem néztem meg Vajonész linkjét, de szerintem a kulcsszó a dologban a polymorphism. Ez számomra valamilyen hálózatba rendezett közepesen bonyolult procikból álló lazán csatolt(?) rencer lesz.

[Rive]

SFIJ, majdnem beletaláltál

Ha jól nézem, akkor ez egy jókora marék mátrixba rendezett VE, egyedi várakoztatóállomásokkal, csoportos regiszterkészletekkel és gyorsítótárakkal megbolondítva.

A VE-hozzárendelés az, ami meglehetõsen rugalmas: fõként erre vonatkozik a polimorphism.

Érdekes...
[url="http://"http://ftp.cs.utexas.edu/pub/dburger/papers/ISCA03_trips.pdf"]http://ftp.cs.utexas...SCA03_trips.pdf[/url]

[ 2003. szeptember 02.: Rive szerkesztette a hozzászólást ]

[Michell]

idézet:

---

Ezt írta Rive:
SFIJ, majdnem beletaláltál

Ha jól nézem, akkor ez egy jókora marék mátrixba rendezett VE, egyedi várakoztatóállomásokkal, csoportos regiszterkészletekkel és gyorsítótárakkal megbolondítva.

A VE-hozzárendelés az, ami meglehetõsen rugalmas: fõként erre vonatkozik a polimorphism.

Érdekes...[/quote]

Amikor multiproc rendszerek tervezési kérdéseivel foglalkoztam annó, akkor úgy látszott a (z ön)rekonfigurálható hálózatú megoldásoknak van igazán értelme.
De :
1. akkor a kapcsolóhálózat még nem volt értelmesen kivitelezhetõ.
2. kérdés ekkora végrehajtóegységszámnál van-e már értelme.

És persze milyen programozással tudják kihasználni. (Egyébként kezdeményként volt valami nyelv már akkor ilyesmire.)

[SFIJ]

idézet:

---

Ezt írta Rive:
SFIJ, majdnem beletaláltál

Ha jól nézem, akkor ez egy jókora marék mátrixba rendezett VE, egyedi várakoztatóállomásokkal, csoportos regiszterkészletekkel és gyorsítótárakkal megbolondítva.

A VE-hozzárendelés az, ami meglehetõsen rugalmas: fõként erre vonatkozik a polimorphism.

Érdekes...[/quote]

Most hogy vegigolvastam a doksit ez valami olyasmi amirol en data-flow architektura neven tanultam meg a mult szazad vegen. Szep is, jo is, de az zicher hogy az egyszeri PC user asztalan soha sem lesz ilyen. Baromi lyo az ilyen ketyere barminemu jelfeldolgozasra de alapbol kifexik barminemu rekurziotol vagy iterativ algoritmustol, szoval minden olyantol ami nem oldahto meg linearis programozassal.

[SFIJ]

idézet:

---

Ezt írta Michell:


Amikor multiproc rendszerek tervezési kérdéseivel foglalkoztam annó, akkor úgy látszott a (z ön)rekonfigurálható hálózatú megoldásoknak van igazán értelme.
De :
1. akkor a kapcsolóhálózat még nem volt értelmesen kivitelezhetõ.
2. kérdés ekkora végrehajtóegységszámnál van-e már értelme.

És persze milyen programozással tudják kihasználni. (Egyébként kezdeményként volt valami nyelv már akkor ilyesmire.)[/quote]

Occam?

[Rive]

idézet:

---

Ezt írta Supposed Former Infatuation Junkie:
Most hogy vegigolvastam a doksit ez valami olyasmi amirol en data-flow architektura neven tanultam meg a mult szazad vegen. Szep is, jo is, de az zicher hogy az egyszeri PC user asztalan soha sem lesz ilyen. Baromi lyo az ilyen ketyere barminemu jelfeldolgozasra de alapbol kifexik barminemu rekurziotol vagy iterativ algoritmustol, szoval minden olyantol ami nem oldahto meg linearis programozassal.[/quote]

Nagyon-nagyon multithread, konkurrens környezetbe szánják

Ami nekem nem tetszik, vagy nem értem: az egyes utasításblokkok betöltése után a lefoglalt erõforrások várnak az induláshoz szükséges adatok megérkezésére, vagy van valami prefetch? Elég fura...

[ 2003. szeptember 01.: Rive szerkesztette a hozzászólást ]

[SFIJ]

idézet:

---

Ezt írta Rive:


Nagyon-nagyon multithread, konkurrens környezetbe szánják

Ami nekem nem tetszik, vagy nem értem: az egyes utasításblokkok betöltése után a lefoglalt erõforrások várnak az induláshoz szükséges adatok megérkezésére, vagy van valami prefetch? Elég fura...

[ 2003. szeptember 01.: Rive szerkesztette a hozzászólást ][/quote]

Volt benne valami OoO-ra utalo megjegyzes, ergo az fut, ami tud. De nagyon durva valami alt celra ami nem kezeli a rekurziot. Generaciozni, 'szinezni' kell az adatokat amin dolgozol

[Rive]

idézet:

---

Ezt írta Supposed Former Infatuation Junkie:
Volt benne valami OoO-ra utalo megjegyzes, ergo az fut, ami tud. De nagyon durva valami alt celra ami nem kezeli a rekurziot. Generaciozni, 'szinezni' kell az adatokat amin dolgozol [/quote]

A rekurzióval szerintem semmi gondjuk, csak ugyanaz a kód függõ adatokal ne futhasson két példányban: ne legyenek egymástól függõ utasításblokkok egyidõben végrehajtás alatt.

Gondoskodni kell a megfelelõ számú konkurrens folyamatról, hogy mindig legyen elegendõ függõségek nélküli utasításblokk

Gondolom, tudják, mit csinálnak, de írhatnának valamivel többet - nagyon 'levegõs' ez így nekem

[ 2003. szeptember 01.: Rive szerkesztette a hozzászólást ]

[SFIJ]

idézet:

---

Ezt írta Rive:


A rekurzióval szerintem semmi gondjuk,[/quote]

Rive, Rive ejjnye mar no. Page 3, chapter 2.1

[ 2003. szeptember 01.: Supposed Former Infatuation Junkie szerkesztette a hozzászólást ]

[Rive]

idézet:

---

Ezt írta Supposed Former Infatuation Junkie:
Rive, Rive ejjnye mar no. Page 3, chapter 2.1[/quote]

Ejjnye no

Ugyanazon a lapon, kicsit késõbb:

idézet:

---

For all modes of execution, the compiler is responsible for statically scheduling each block of instructions onto the comutational engine such that inter-instruction dependencies are explicit. [/quote]

Az architektúrának semmi gondja a rekurzióval: azokat a fordító kezeli le, statikusan, a programozónak semmi dolga ezzel.

Emellé:

idézet:

---

The deallocation logic may be configured to allow a block to execute more than once, as is useful in streaming applications in which the same inner loop is applied to multiple data elements. [/quote](4/2.3)

Ez elég hasznos lehet, nem?

[ 2003. szeptember 02.: Rive szerkesztette a hozzászólást ]

[SFIJ]

idézet:

---

Ezt írta Rive:
(4/2.3)

Ez elég hasznos lehet, nem?

[ 2003. szeptember 02.: Rive szerkesztette a hozzászólást ][/quote]

Rive

a) iteracio =/= rekurzio
Az iteraciot meg muszaj tamogatni, anelkul DSP algoritmus nem vagyon Az iteracioval kapocslatban tenyleg okorseget irtam, 3-mal ezelott ugyhogy azert jogos a pont.
B) nem allitottam hogy lehetetlen a rekurzio, hanem aszondtam, hogy szornyen gazdasagtalanul implementalhato.

[ 2003. szeptember 02.: Supposed Former Infatuation Junkie szerkesztette a hozzászólást ]

[Rive]

idézet:

---

Ezt írta Supposed Former Infatuation Junkie:
B) nem allitottam hogy lehetetlen a rekurzio, hanem aszondtam, hogy szornyen gazdasagtalanul implementalhato.[/quote]

Én se azt állítottam, hogy teljeskörûen támogatják, hanem azt, hogy gondoltak rá, és olyan helyre tervezték a procit, ahol lesz más dolga addig, amíg a rekurzív szálon kevés a munka

Azt hiszem, itt a hatékonyságot kifejezetten a teljes processzorra vizsgálják, nem pedig egy-egy szál esetében. Ennek megfelelõen a a lehetõségek határáig leegyszerûsítették az egyes szálakat gyorsító részeket, és inkább az összteljesítményre gyúrnak...

[ 2003. szeptember 03.: Rive szerkesztette a hozzászólást ]

[Vajonész]

Miért olyan fontos a rekurzió?
Komolyabb programoknál eddig sem használták.

[Rive]

idézet:

---

Ezt írta Vajonész:
Miért olyan fontos a rekurzió?
Komolyabb programoknál eddig sem használták.[/quote]

... Izé...

Belõlem ilyen kijelentést talán pirosra izzított fogókkal lehetne kihúzni, de te tudod

Gondolok most itt pl. a szakértõi rendszereknél (is) használt logikai alapokon nyugvó programozási elveket hasznosító fordítókra, és az általuk produkált, néha elrettentõen nagy erõforrásigényû programokra

[ 2003. szeptember 03.: Rive szerkesztette a hozzászólást ]

[Elric]

A velemenyem az, hogy az architektura szep, sot egyenesen gyonyoru, de igen sok gondjuk lesz vele, mert nagyon bonyolult. Az otlet az alkalmazkodo architekturarol ebben a formaban igen erdekes. A Sun UltraSPARC-V-je lesz kisse hasonlo. Persze toredeke komplexitasban, nagysagban es igy potencialis teljesitmenyben.

Tobb erdekesseg is volt benne szamomra, ami azert nem annyira meglepo. A 4x4-es matrix eseteben is a D-morph mukodes alatt, altalaban 4-es, 5-os IPC-t ernek el, ez konform az iparral, de bazi gyenge eredmeny, lassuk be. Persze jobbat nem is lehet csinalni. A T- es S-morph allapotban mar sokkal jobb az eredmeny, de ezt is varnank.

Az architektura alfaja es omegaja megint (mint minden ilyen treszlegesen testreszabhato rendszernel) a compiler lesz, ami szerintem messze nem trivialis. A kovetkezo meg az OS, mert a 3 morph mod kezelese es a kozottuk valo valtogatas nem lesz trivialis. Raadasul szegeny compiler-nek is valamelyikhez kell optimalizalnia.

Michell, igazad van, de szerintem ez nem lesz onkonfiguralo, azt integralt CPU szinten megcsinalni, szinte lehetetlen.

SFIJ, miert kellene ennek a PC-s felhasznalok asztalara mennie? Aztan meg nem is ertem miert nem lehet evvel az architekturaval rekurziot csinalni? Hyperblock-ok megkotik ugyan a kezemet, de annyira azert nem.

Rive, szerintem mindegyik modban OOO a mukodes, vagyis nem fog eroforrasokat lock-olni, az meg, hogy egy nagy ablakban varakozik egy blokk, vegulis nem akkora gaz. Sot en a fuggo blokkokat sem erzem teljesen problemasnak, mert irjak is, hogy az altalam "szuper-spekulativ" vegrehajtasnak nevezett valamihez nagyon hasonlo koncepciot is tamogat a cucc.

SFIJ, valoban igaz, hogy nem tul praktikus a hyperblock rendszer a rekurziora, de azert azt NAGYON nem allitanam, hogy "szornyen gazdasagtalan".

Vajonesz, szerintem egy kicsit gondolkodj el azon, amit irtal. Anelkul, hogy meg akarnalak bantani, egyszeruen csak annyit tudok mondani: DOBBENETES es nem is igaz.
Elric

[Vajonész]

idézet:

---

Ezt írta Rive:

"...logikai alapokon nyugvó programozási elveket hasznosító fordítókra... "
[/quote]

Itt mire gondolsz?
A logikai programozási nyelvek fordítói általában a rekurziót a fordítás során feloldják.

[Rive]

idézet:

---

Ezt írta Vajonész:
Itt mire gondolsz?
A logikai programozási nyelvek fordítói általában a rekurziót a fordítás során feloldják.[/quote]

Hm. Ebben én nem kis mértékben kételkedem.

A logikai nyelveket imperatív alapokon megközelítõ fordítók tudtommal küzdenek néhány nem elhanyagolható hiányossággal, az ilyen jellegû optimalizációk csak korlátozottan használatosak.

[ 2003. szeptember 03.: Rive szerkesztette a hozzászólást ]

[Rive]

idézet:

---

Ezt írta Elric:
Rive, szerintem mindegyik modban OOO a mukodes, vagyis nem fog eroforrasokat lock-olni, az meg, hogy egy nagy ablakban varakozik egy blokk, vegulis nem akkora gaz. Sot en a fuggo blokkokat sem erzem teljesen problemasnak, mert irjak is, hogy az altalam "szuper-spekulativ" vegrehajtasnak nevezett valamihez nagyon hasonlo koncepciot is tamogat a cucc.

Elric[/quote]

Hm. Az 5/3.2-re nem fordítottam elég figyelmet

Így már nem tudok belekötni Bár, még próbálkozom ám