Onko jossakin Intelin CPU:ssa 128-bit Floating Point Unit

UseinVääräNeliöjuri

Onko joissakin uusissa Intelin peruskäyttöön tarkoitetuissa prosessoreissa 128-bit FPU?
Muutamissa Intelin Xeon prosessoreissahan on ollut yli 80-bittisiä CPU:ita jo pitkään. Entäs AMD?

Ison kokonaisluvun neliöstä olisi mukava saada tarkka neliöjuuri aina ihan oikein ilman ohjelmallista toteutusta. Ennen aina kerrottiin varmasti oikein toimivat lukualueet eri operatioissa. Nyt tuota perustietoa on lähes mahdoton löytää Googlella.

7

<50

Vastaukset

  • Ei se vaikuta muualle kuin suorituskykyyn se prosessorin tuki.

    Joka tapauksessa siinä olisi joku kirjasto kun tietotyyppien koot ovat melko hyvin standardoitu. Onko tuolle sitten tehty FPU kiihdytys niin vaikea sanoa.

    • voi Kilju-Peter-peseilijä cpu


  • Taitaa nykyisin vakio olla 256-bit fpu.Sitten "AMD's Zen CPU includes a 512 bit floating point processor" "Zen on koodinimi AMD:n suorittimien mikroarkkitehtuurille, jota käytettiin ensimmäistä kertaa yhtiön Ryzen-tuotesarjan prosessoreissa helmikuusta 2017 alkaen"

    • Nuo 256 ja 512 bit ovat käskyjen ja sisäisten väylien yms leveyksiä. Liukulukujen tarkkuus on kuitenkin vain se ikivanha vaatimaton 80 bit. Ihan kuten yli 30 vuotta sitten.

      Nyt kyse oli kyllä varmasti 128-bittisistä (quadruple precision, binary128) floating point luvuissta. Noita käsitteleviä FPU:ita oli joskus "oikeissa" tietokoneissa.

      Jostakin syytä en nyt löydä yhtään Intelin (ei edes Xeon) tai AMD prosessoria, jossa oli 128-bittisiä floating point lukuja laskeva FPU. Uudet prosessorit kyllä laskevat 80-bittisiä lukuja toinen toistaan nopeamin kaikkia mahdollisia kikkoja ja rinnakkaisuuksia hyödyntäen. Sama juttu tietsti myös kokonaislukujen kanssa. Nopeutta on tullut mielettömästi lisää.

      Ei ole tietystikään mikään ongelma lisätä tarvittaessa liukulujen tarkkuutta mielivaltaiseksi ihan vaan ohjelmallisilla ratkaisuilla, sillä liukuluvut muodostuvat kokonaisluvuista. Sinne tänne on on tietysti lisätty jotain HW-tukea ja uusia käskyjä.. Viisaat kokonaisuuden optimoijat varmasti tietävät mitä tekevät. Aikaa ja kilpailua on ainakin ollut riittävästi tehdä kaikki oikeasti tarpeelliset muutokset ja parannukset HW-tasolla.


    • Anonyymi kirjoitti:

      Nuo 256 ja 512 bit ovat käskyjen ja sisäisten väylien yms leveyksiä. Liukulukujen tarkkuus on kuitenkin vain se ikivanha vaatimaton 80 bit. Ihan kuten yli 30 vuotta sitten.

      Nyt kyse oli kyllä varmasti 128-bittisistä (quadruple precision, binary128) floating point luvuissta. Noita käsitteleviä FPU:ita oli joskus "oikeissa" tietokoneissa.

      Jostakin syytä en nyt löydä yhtään Intelin (ei edes Xeon) tai AMD prosessoria, jossa oli 128-bittisiä floating point lukuja laskeva FPU. Uudet prosessorit kyllä laskevat 80-bittisiä lukuja toinen toistaan nopeamin kaikkia mahdollisia kikkoja ja rinnakkaisuuksia hyödyntäen. Sama juttu tietsti myös kokonaislukujen kanssa. Nopeutta on tullut mielettömästi lisää.

      Ei ole tietystikään mikään ongelma lisätä tarvittaessa liukulujen tarkkuutta mielivaltaiseksi ihan vaan ohjelmallisilla ratkaisuilla, sillä liukuluvut muodostuvat kokonaisluvuista. Sinne tänne on on tietysti lisätty jotain HW-tukea ja uusia käskyjä.. Viisaat kokonaisuuden optimoijat varmasti tietävät mitä tekevät. Aikaa ja kilpailua on ainakin ollut riittävästi tehdä kaikki oikeasti tarpeelliset muutokset ja parannukset HW-tasolla.

      FPU toimii mikrokoodilla ja sitä koodia lienee paljon. Lähes samantasoista mikrokoodia syntyy nykyisin myös peruskäskyjen dekoodauksen yhteydessä ja monet käskyt saadaan suoritettua yhden kellojakson aikana. Kaikki toimii liukuhihnamaisesti. Suorituskykyä ja tarkkuutta voidaan lisätä älykkäillä algoritmeilla ja laskujärjestyksen optimoinnilla. Ei kannata tehdä mitään turhaa eikä laskea mitään liian tarkasti kellojaksoja tuhlaten. Tarkkuutta on sitten helppo lisätä, kun on päästy lähelle jotain mielenkiintoista nollakohtaa tms.


    • Anonyymi kirjoitti:

      FPU toimii mikrokoodilla ja sitä koodia lienee paljon. Lähes samantasoista mikrokoodia syntyy nykyisin myös peruskäskyjen dekoodauksen yhteydessä ja monet käskyt saadaan suoritettua yhden kellojakson aikana. Kaikki toimii liukuhihnamaisesti. Suorituskykyä ja tarkkuutta voidaan lisätä älykkäillä algoritmeilla ja laskujärjestyksen optimoinnilla. Ei kannata tehdä mitään turhaa eikä laskea mitään liian tarkasti kellojaksoja tuhlaten. Tarkkuutta on sitten helppo lisätä, kun on päästy lähelle jotain mielenkiintoista nollakohtaa tms.

      Voi olla, että kaikki raaka laskenta on saatu rinnakkaiseksi ja liukuhihnamaiseksi ja riittävän nopeaksi, eikä se ole enää mikään pullonkaula. Aika kuluu saatujen lukujen hitaaseen käsittelyyn yksitellen ja siirtelyyn päämuistiin ja kovalevylle ja siten taas takaisin uuteen laskentaan.


    • Anonyymi kirjoitti:

      Voi olla, että kaikki raaka laskenta on saatu rinnakkaiseksi ja liukuhihnamaiseksi ja riittävän nopeaksi, eikä se ole enää mikään pullonkaula. Aika kuluu saatujen lukujen hitaaseen käsittelyyn yksitellen ja siirtelyyn päämuistiin ja kovalevylle ja siten taas takaisin uuteen laskentaan.

      Näin on. Erittäin suuri osa energiasta, mitä keskusyksikkö käyttää, menee vain tiedon siirtelyyn paikasta toiseen.

      Vain pieni osa menee itse laskemiseen.


Ketjusta on poistettu 0 sääntöjenvastaista viestiä.

Takaisin ylös