[HN Gopher] Tachyum's Prodigy CPU Specs
___________________________________________________________________
Tachyum's Prodigy CPU Specs
Author : rbanffy
Score : 124 points
Date : 2022-06-13 11:18 UTC (11 hours ago)
(HTM) web link (wccftech.com)
(TXT) w3m dump (wccftech.com)
| mhh__ wrote:
| Also assuming this is VLIW, time to play the NOP-counting game
| when the internal ISA either gets reversed or documented.
|
| Hypothetically you can do all kinds of things in software wrt to
| speculation and changing ISA on the fly.
| freemint wrote:
| 5GHz of NoOps this chip is gonna have good BogoMisp values.
| jfindley wrote:
| This sounds fairly obviously fake. 128 cores at a TDP of 950W
| means only ~7.4W per core, which would be a massive improvement
| on the i9-9990XE - which can only do 5Ghz - and requires 18.4W
| per core. A tiny, hitherto unknown company with only a handful of
| engineers managing to outperform Intel by this huge of a margin
| strains credulity past breaking point.
|
| They also talk about air-cooling four of the 600W model in a 2U
| chassis! I'm not convinced how possible it is to handle 600W for
| any reasonable socket size with air cooling at all - the watts
| per mm2 ratios are going to be very high - but the idea that you
| can air-cool 2.4kW from the CPUs alone (and at these speeds there
| are going to be a lot of other very warm components in there) in
| a 2U chassis is simply crazy.
| phire wrote:
| Or the cores are much, much simpler than Intel's cores, and
| designed for higher clock speeds.
| rbanffy wrote:
| They seem to be in-order VLIW cores, so yes, they are much
| simpler than any other server CPU.
| timpattinson wrote:
| IBM had 5GHZ in 2014. [1] Clock speed is not a measure of
| performance alone.
|
| Besides, most of the work in reaching a certain clock speed or
| target can be owed to the foundry (in this case TSMC which is
| world-leading, certainly beating Intel on most metrics at the
| moment.)
|
| Comparing to the over-tuned enthusiast SKU of 2018 is not a
| fair comparison for either. Also 600W is not impossible to
| cool, there are GPUs at that level of power for a while now.
|
| [1] https://en.wikipedia.org/wiki/POWER8
| rayiner wrote:
| IBM hit 5 ghz in 2008: https://en.wikipedia.org/wiki/POWER6.
| IBM's Cell hit 4 ghz in 2006 on a 65 nm process.
| Symmetry wrote:
| The advantages of chopping up chopping your pipeline stages
| in half so that each is 10 FO4s long rather than the 16
| FO4s most people use. You've generally got 2 FO4s of
| latching and 2 of clock skew so IBM was seeing 6 FO4s of
| useful work per stage compared to 12 with Intel. Or at
| least the overhead was 4 per stage in the mid 2000s, I've
| got no idea what they are in the early 2020s.
| rbanffy wrote:
| And, if you have enough threads per core, it's relatively
| simple to switch to another thread when an instruction
| stalls. Unfortunately, most our software is designed for
| machines with few fast cores.
| sk0g wrote:
| The M1 Max (8+2 cores) tops out at a CPU TDP of around 30W
| IIRC, on the 5nm node. These numbers aren't that unrealistic,
| are they? Intel isn't exactly known for power efficiency
| currently, aside from E-cores.
| xxs wrote:
| M1 Max runs 0.6-3.2GHz - this is the efficiency range.
| Running higher requires more voltage which increases the
| power squared, and then the freq. is linear. The infamous
| cubic power scaling for increased frequency 5.5GHz is just
| unrealistic.
| klelatti wrote:
| Also how does this tiny company get access to 5nm manufacturing
| capability?
| eis wrote:
| By signing a contract with TSMC? That's the fab according to
| the article. 5nm is not bleeding edge and as others move to
| N5P or N4, capacity gets freed at N5.
| klelatti wrote:
| > 5nm is not bleeding edge and as others move to N5P or N4,
| capacity gets freed at N5.
|
| Actually the article says it's on N5P the same process as
| the Apple M2.
|
| I think TSMC does give smaller companies access to cutting
| edge processes in small volumes but it won't be cheap.
|
| I'm still sceptical.
| masklinn wrote:
| Given the main comparison target seems to be the H100 and
|
| > The processor pipeline has its out of order execution handled
| by the compiler, not by hardware
|
| This is not a direct competitor to general purpose CPUs, which
| makes the frequency claims a lot more realistic but also
| completely useless as a basis for comparison.
| rbanffy wrote:
| > The processor pipeline has its out of order execution
| handled by the compiler, not by hardware
|
| I wonder how compilers improved at generating good ILP with
| VLIW designs. The Itanium suffered from poor performance
| because it was very difficult to generate optimally ordered
| code for it.
|
| OTOH, with enough GHz, even a simple, inefficient, in-order
| architecture can be fast enough. That was what made RISC
| attractive in the 80's and 90's.
| rayiner wrote:
| > This sounds fairly obviously fake. 128 cores at a TDP of 950W
| means only ~7.4W per core, which would be a massive improvement
| on the i9-9990XE - which can only do 5Ghz - and requires 18.4W
| per core
|
| You're comparing apples and oranges. The 9990-xe is on 14 nm
| process. This is on 5 nm. Beyond that, this appears to be an in
| order VLIW core. The 9990-xe is a deeply out of order core. In
| a modern processor, much of the power budget is taken up by the
| structures used for out of order execution, such as reorder
| buffers and schedulers. These structures often grow non-
| linearly with the amount of reordering capability of the CPU.
| Jettisoning them entirely saves huge amounts of power.
| jfindley wrote:
| Well, the process size numbers between different companies
| have been somewhat meaningless for a while now, as they all
| measure different things. Intel's 14nm process is still
| larger than the 5nm TSMC process used here, but the
| difference is considerably smaller than the numbers suggest.
| It's a fair point about VLIW cores being a lot cheaper in
| terms of power budget though. I'm still extremely sceptical
| but I concede that at least on paper it's not impossible.
| terafo wrote:
| The difference is huge, for example, if we measure density
| there is 5x difference.
| mhh__ wrote:
| TSMC is much much denser than Intel 14nm keep in mind + these
| cores are probably much dumber than an Intel one.
| sudosysgen wrote:
| I wonder if you could make VLIW processors work better for
| general purpose loads by exposing a higher level machine code
| with an on-board JIT compiler that could optimize for runtime
| behaviour. In theory JITs should be even more effective for VLIW
| in order processors because runtime behaviour should have an even
| larger effect of what kinds of optimizations are needed, and the
| difficult and costly nature of optimizing such code coule benefit
| from very accurate hotspot optimization. You could of course also
| expose the lower level architecture for programs that do their
| own JIT.
| baobob wrote:
| Smells vaguely like another Transmeta, will wait for shipping
| products
| bloaf wrote:
| Maybe its secretly the Mill CPU architecture!
| black3r wrote:
| I love how they call the 180W variant "Low Power"
| rbanffy wrote:
| For a server CPU it's kind of low power.
| hkgjjgjfjfjfjf wrote:
| vsskanth wrote:
| Do you need to compile separately for tachyum ?
| sydbarrett74 wrote:
| londons_explore wrote:
| Smells like vaporware to me...
|
| They are missing critical statements like "The emulation allows
| booting x64 Linux and gets XXXX score on [industry benchmark]".
|
| They have no documentation on their native ISA, nor any
| indication of any software or even compilers ported to it.
|
| I would guess the 4 year delay is them struggling to get the
| software side working with any reasonable performance. It isn't
| too hard to make a toy processor with a high clock rate in a
| simulator... But getting it to run linux and win benchmarks is
| much harder.
| [deleted]
| BirAdam wrote:
| This sounds like yet another company aiming to take advantage of
| the everything bubble, where in a company can make a claim
| without any shipping product, without any proven ROI, and still
| get a multi-billion dollar valuation. The team becomes
| exceedingly rich, and then they either get bought or go bankrupt
| (though still individually wealthy). A claim this large needs
| very substantial proof, and there's nothing to show that this is
| more than an overzealous teenager mouthing off about something
| he/she/ze doesn't understand.
| thecompilr wrote:
| To those like me wondering what ISA it is, the official
| documentation says:
|
| Runs binaries for x86, Arm, and RISC-V in addition to native ISA
|
| I am quite a bit skeptical. OTOH, if it were aarch64 compatible
| with 1024 bit SVE support, it could have a nice potential.
| ThinkBeat wrote:
| Only x86 not amd64?
| victor82 wrote:
| According to golem.de's report, Prodigy has its own VLIW ISA,
| and Qemu achieves compatibility with the other mentioned ISAs.
| ip26 wrote:
| How does it run native binaries from other ISA if ILP is
| supposed to be handled by the compiler...
| ncmncm wrote:
| Looks like ordinary emulation, Qemu.
| mhh__ wrote:
| By having it's own compiler in the background. Transmeta did
| this 20 years ago, sadly the IP is in a bin somewhere inside
| Intel (?) or some other giant.
|
| When we talk about speculation and out of order execution we
| imagine the CPU is a kind of giant dependency-graph engine
| but this isn't actually true. The genius of modern hardware
| design (although kicked off by Tomasulo in the 60s) is that
| you can "compress" this idea into a real circuit with a
| finite number of gates and SRAM etc.
|
| The quality of the branch prediction lets you get away with a
| lot on a fairly dumb "throw stuff on a buffer, speculate
| across memory accesses, pop (commit) off the buffer when the
| pie's finished cooking" model inside the processor.
|
| The draw of this and originally Transmeta is that you have an
| extremely wide dumb processor in front of a smart _software_
| frontend that can do much more complicated work and
| scheduling based on the all-important runtime information
| that static VLIW sorely lacked (and thus lead to Intel doing
| all kinds of stuff with Itanium, hence it ending up EPIC
| rather than a true VLIW spiritually).
|
| Now, software is slow, the way Transmeta got around this is
| by having a physical cache (the "Tcache") for storing
| translated instructions in.
|
| https://www.cs.cornell.edu/courses/cs6120/2019fa/blog/transm.
| ..
|
| https://www.realworldtech.com/crusoe-intro/5/ Some reverse
| engineering from the time. Note the amount of nops in the
| firmware.
|
| https://safari.ethz.ch/digitaltechnik/spring2019/lib/exe/fet.
| ..
| erincandescent wrote:
| NVIDIA Denver was basically the Transmeta design with an
| ARM instead of x86 frontend.
|
| It was very underwhelming.
| mhh__ wrote:
| Was Denver VLIW?
| Symmetry wrote:
| Yes, mostly. It was essentially a Transmeta Efficeon with
| some facilities to run ARM code natively the first time
| through in case it wasn't going to be re-used.
| [deleted]
| my123 wrote:
| > is in a bin somewhere inside Intel
|
| NVIDIA. For example, the Carmel core, shipping on Tegra
| Xavier.
| mhh__ wrote:
| Did Nvidia get the rights to CMS? I thought Nvidia got
| some power management stuff but Intel got the rest of it
| my123 wrote:
| https://www.techpowerup.com/67814/nvidia-licenses-
| technologi...
|
| > The agreement grants to NVIDIA a non-exclusive and
| fully paid-up license to all of Transmeta's patents and
| patent applications,
| Symmetry wrote:
| They were going to have their cores be able to run both
| ARM and x86 binaries but IIRC patent issues with Intel
| prevented them from doing both so they just went with
| ARM. Whether you need the x86 patents to run have a
| Transmeta style processor running x86 might be something
| that can only be settled by going to court.
| 2000UltraDeluxe wrote:
| The first thing that came to my mind was that someone
| bought the old Transmeta IP. The dream of a multi-GHz m68k
| lives on! :)
| windenntw wrote:
| You can already get that by replacing the cpu with a
| pistorm:
|
| https://linuxjedi.co.uk/2021/12/27/800mips-amiga-with-
| emu68-...
| amelius wrote:
| Perhaps the microcode can be flashed?
| throw457 wrote:
| Wouldn't really change the physical registers...
| rbanffy wrote:
| You can have a large register file and mask the ones that
| are not architectural into speculative execution flows.
| drewg123 wrote:
| Does the dupe detector work on title text, or URLS? I posted the
| same article last night:
| https://news.ycombinator.com/item?id=31719519 The URL is the
| same, but I shortened the text differently (the article's title
| was too long for the submission form).
| pxeger1 wrote:
| I think it doesn't count duplicates when one of them has very
| few votes
| tiffanyh wrote:
| > 950W TDP
|
| Wow, that's high.
| cosmiccatnap wrote:
| I'm surprised that wccftech doesn't get auto flagged on here like
| it does many other sites. It is well known for getting it's
| content from the rumor mill.
| fathyb wrote:
| First time I'm hearing about Tachyum. Looks very promising,
| although it does sound too good to be true, especially the cross-
| ISA support.
|
| Interesting bit I found researching them:
| https://www.nextplatform.com/2020/04/02/tachyum-starts-from-...
|
| _The processor pipeline has its out of order execution handled
| by the compiler, not by hardware, so there is some debate about
| whether this is an in order or out of order processor. Danilak
| says that instruction parallelism in the Prodigy chip is
| extracted using poison bits, which was popular with the Itanium
| chip which this core resembles in some ways and which are also
| used in Nvidia GPUs. The Prodigy instruction set as 32 integer
| registers at 64-bits and 32 vector registers that can be 256 bits
| or 512 bits wide, plus seven vector mask registers. The explicit
| parallelism (again, echoes of Itanium) is extracted by the
| compiler and instructions are bundled up in sizes of 3, 8, 12, or
| 16 bytes._
| fweimer wrote:
| Regarding the "too good to be true" part, I wouldn't take them
| seriously based on what they have published (and more crucially
| what they have withheld, like an ISA manual or sources of a GNU
| toolchain port), _except_ they managed to hire a very senior
| GCC developer. I trust that he did his due diligence before
| joining them, so I must assume what they are building is real.
|
| Did they make any performance claims about the cross-ISA
| support? It might just be QEMU port with qemu-user and TCG.
| foobiekr wrote:
| Transmeta managed to hire Linus Torvalds. Hiring is mostly -
| not entirely - about money.
| masklinn wrote:
| > except they managed to hire a very senior GCC developer. I
| trust that he did his due diligence before joining them, so I
| must assume what they are building is real.
|
| "Lots of money" and interesting challenge can be the due
| diligence, it's not like the product has to be realistic to
| get paid (it helps in the long run, but in the short run VC
| money pays the bills).
|
| Hell, they might even believe in the product. Linus spent 6
| years at Transmeta.
| pinewurst wrote:
| I think there's a difference though between Transmeta not
| making a competitive product from their story and Tachyum
| seeming an out-and-out scam.
| rayiner wrote:
| So it's a big VLIW chip. Maybe interesting for the domain, but
| the crazy specs make sense in that context. With deep OOO
| designs hitting almost 5 ghz on TSMC 5 nm, it's not surprising
| to see an in order VLIW design hit 5.7. Impressive effort by
| new company if it pans out though. It would be good to see a
| renaissance in high end chips and architectures like the mid
| 1990s.
| Symmetry wrote:
| Yeah. I wonder if its a classic VLIW or if the pipeline is
| exposed and/or skewed.
|
| _exposed_ : The results of operations that take more than
| one clock cycle don't necessarily appear at their destination
| the cycle after the instruction is executed. Think branch
| delay slots but potentially for multiplies and loads too.
|
| _skewed_ : Loads, processing, and stores can happen on
| subsequent clock ticks so simple loops don't necessarily need
| prologues and epilogues.
|
| A compiler can handle either of these for a particular CPU
| pretty easily but they tend to eliminate binary
| compatibility. Code morphing as in the Transmeta lineage like
| to use both of these. Other VLIWs with barrel multithreading,
| like the Hexagons DSPs in Snapdragon SOICs, don't need them.
|
| EDIT: The Mill guys have a video on how this works on their
| system. They've got their own names for things for some
| reason but they do a good job of explaining how this all
| works: https://millcomputing.com/docs/execution/
| rayiner wrote:
| I would be curious to learn what makes the "skewed"
| approach work. Googling fails me since this turns up a lot
| of articles on clock skew.
| pclmulqdq wrote:
| In my time as an FPGA developer, I wrote a lot of tiny
| processing cores that were exposed and skewed VLIW designs
| for specific applications. If the code isn't changing much,
| they work extremely well in a very small silicon area and
| power footprint. However, they are awful to program.
|
| In supercomputing, this sort of thing sometimes appears and
| works well (like the Pezy-SC2 chips that recently came
| out). However, they usually fail on general purpose
| computing tasks.
| Symmetry wrote:
| Yeah. Normally sophisticated software scheduling works
| great on DSP-like tasks where the memory access patterns
| are very predictable but suffer a lot where you tend to
| have unexpected cache misses that a deep OoO system could
| just paper over.
| londons_explore wrote:
| I think the benefits of both could be had with "software
| assisted branch prediction/caching".
|
| Ie. you transpile your x86 code to native code for your
| VLIW machine. Then you run that code for a few hundred
| clock cycles till _bam_ "cache not ready on time
| exception" which fires when you try to execute an
| instruction that is expecting to read memory from the
| cache, but the cache isn't yet populated with that value.
| Then you re-run your transpiler which will produce new
| code which either does a better job of reading the data
| into the cache ahead of time, or issues different
| instructions which take more time and read data direct
| from RAM.
|
| Remember a software transpiler sometimes has _more_
| information than a typical deep OoO CPU, because it can
| use a lot more memory for state (eg. remembering that a
| particular branch or memory access won 't be cached), and
| it can even persist state across system reboots. It can
| also do far more expensive optimizations and save the
| results, something a deep OoO CPU can't do because all
| the optimizations need to be doable in hardware.
| bee_rider wrote:
| This seems like it would give fantastic benchmark
| results, if the benchmark result shared was the final
| version and the benchmark was identical from run-to-run.
| freemint wrote:
| All i can think is online polyhedral optimization using
| the unused matrix instructions. I recoil in horror.
| Symmetry wrote:
| I wonder how they manage that? It's straightforward to do if a
| page fault represents an error that halts the execution of a
| thread but not if you need to be able to keep going after the
| OS reads in the data from the hard drive. That is, if you
| speculatively load values that aren't going to be used in a
| loop then the fact that you had poisoned values sitting around
| in some registers doesn't matter. But if that data "should"
| have been there but wasn't and you store or branch based on it
| then you've got to roll back to the load, page in the data,
| then continue from the checkpoint. And if you're able to do all
| of that why not just go full out of order?
| rayiner wrote:
| The pipeline state can be checkpointed with a fixed amount of
| logic gates that's proportional to the amount of pipeline
| state. Out of order execution requires tracking dependencies
| in structures that scale superlinearly with the size of the
| out of order window.
| Symmetry wrote:
| It isn't bound by the pipeline length. Even without
| pipelining at all, with poisoning you can do a faulting
| load into a register and then just mark the value in the
| register as poisoned. As you perform operations with the
| value any results are also poisoned. Then maybe dozens or
| hundreds of cycles later when you store or branch on one of
| the poisoned values the fault occurs. So pipeline length
| really doesn't have anything to do with it.
|
| On Itanium you essentially had to double check your values
| for poison before operating on them in a lot of cases and
| that caused big performance penalties on conventional code.
| Other systems restrict the shenanigans you can get up to
| with your MMU and solve the problem that way but that means
| you can't run a traditional OS with mmaped files and memory
| paging and such. I'm not sure what the Tachyum people are
| doing or if they've got some clever idea to get around all
| of this.
| avianes wrote:
| I'm not sure if this answers your question but VLIW
| processors feature speculative loads.
|
| "speculative load" can be seen as data prefetch to a
| register, but with a extra instruction to put before
| reading/using the register. This instruction check that the
| memory content has been received, otherwise the instruction
| stall the pipeline. It allows to reorder a load before a
| conditional branch.
|
| To determine whether the load has been received, there is an
| additional structure in the microarchitecture that tracks
| speculative loads in-flight. When a context switch occurs,
| this data-structure is overwritten, so there are additional
| mechanisms to replay the load in such cases.
| [deleted]
| ThinkBeat wrote:
| I presume it would not be possible but mixing and matching ISA
| opcodes across all the implemented ones would be interesting.
| Pick the opcode that is most advantageous for the task happening
| rigth there.
| devit wrote:
| Seems bullshit, it's obviously impossible to beat both state of
| the art CPUs, GPUs and even TPUs (lol) with a single
| architecture.
|
| They can maybe do that if the architecture is configurable and
| they are using different configurations for their CPU, GPU and
| TPU competitors, but then it's still highly implausible that they
| can deliver more than 2x improvement over competitors, unless
| perhaps if it also costs proportionally more (but even then, you
| get decreasing yields for larger chips and inefficiencies if you
| make an SMP system).
| bee_rider wrote:
| VLIW can be pretty weird, though.
|
| Might have something where hand-tuned assembly code can beat
| top tier CPUs and GPUs for very specific workloads (Although I
| guess it would have to be something straight-line enough that
| it can be statically scheduled, while not falling into the
| bucket of things that GPUs blow through).
| BeefWellington wrote:
| > Seems bullshit, it's obviously impossible to beat both state
| of the art CPUs, GPUs and even TPUs (lol) with a single
| architecture.
|
| Unseating x86/AMD64 is going to be hard because of the inertia
| they have. Whatever you make, even if it's faster, at least has
| to be able to run x86/64 binaries at a reasonable speed or it
| won't get wide adoption, unless it's a very captive market
| (mobile/Apple).
|
| I'm skeptical of their claims but I would just say, the M1 has
| proven that if you have an appetite for throwing away
| compatibility and a great engineering team you can accomplish
| quite a bit. It seems you definitely can throw away the baggage
| that comes with needing compatibility and make fast, successful
| processors.
| lbriner wrote:
| What's depressing is that these hardware specs are millions of
| times faster/more cores/more storage/more ram than 20 years ago
| but we still manage to produce laggy applications and websites.
|
| How can something that should e.g. Visual Studio whose solution
| should easily fit into RAM take about 5 seconds to start, 5
| seconds to search the MRU and 10+ seconds to load intellisense.
|
| How can "search the combo box" on Octopus deploy take notceable
| seconds sometimes even though it is purely an in-browser
| operation?
|
| That's just two examples, there are plenty of others.
|
| Sorry hardware guys!
| ryanjshaw wrote:
| > 20 years ago
|
| This was published nearly 33 years ago:
|
| OUSTERHOUT, J. 1989. Why aren't operating systems getting
| faster as fast as hardware? WRL Tech Note, (TN-11)
|
| https://www.hpl.hp.com/techreports/Compaq-DEC/WRL-TN-11.pdf
| Kerbonut wrote:
| How much latency does all of modern software's telemetry add
| into that?
| rbanffy wrote:
| > How can something that should e.g. Visual Studio whose
| solution should easily fit into RAM take about 5 seconds to
| start, 5 seconds to search the MRU and 10+ seconds to load
| intellisense.
|
| You could start all three in three threads and have everything
| finish in 10+ seconds, provided you have cores and memory
| bandwidth available.
|
| Maybe Microsoft is providing too good desktops for the Visual
| Studio team. ;-)
|
| I frequently advocate developers should, as an exercise, work
| on machines with more cores and lower single-thread
| performance. Core counts are only going to increase and being
| able to put all cores to work at the same time is an important
| competitive advantage.
| sombragris wrote:
| I see this article as quite high on hype and very low on factual
| info. What about the CPU's native instruction set, for example?
| Not a single word.
| freemint wrote:
| Actually a very long word (forgive the pun). "Proprietary"
| daniel-cussen wrote:
| I love the 950W part. Love it.
|
| Fake news, yeah maybe. What makes me incredulous is how bad the
| Tachyum name is. Although people without multiple startups before
| them can't come up with good names, like https://fgemm.com
| (coming soon). Apart from that!
| machinekob wrote:
| Citing other comment -> "Tachyum is writing press releases like a
| machine gun (2-3 a month), but they don't participate in MLPerf
| and avoid comparisons altogether. They talk about big facilities,
| but they have 43 employees (including ex-employees) on LinkedIn.
|
| Doesn't anything confuse you?"
| simne wrote:
| For me, only really hard, to make one solution, which will be
| market viable, mean, will sell on real open market in
| quantities enough to make project profitable.
|
| For example, it is possible, if we consider some fantastic
| scenario, in which some big rich country will totally prohibit
| all other architectures, and enforce all people to buy only
| this. But I only know big poor countries, who could consider
| such experiments.
| projektfu wrote:
| How do you dissipate that much power?
| thecompilr wrote:
| large die area
| okl wrote:
| I agree, dissipating 950 Watts over such small area seems
| infeasible. Maybe with a phase change cooler.
| xxs wrote:
| phase change is an awful idea for such high power. It's just
| fake.
| rbanffy wrote:
| Multiple clock regions is one option. Others pointed out large
| silicon areas. We also don't know how the packaging is done -
| it may be a bunch of smaller, 32-core, chiplets separated by
| interposers or memory controllers and IO modules running at
| lower speeds.
| nynx wrote:
| The list of specs definitely sound fake, but maybe they actually
| did figure out how to statically schedule VLIW instructions well.
| I guess we'll see in a year or two.
| RantyDave wrote:
| I think the "thing that has changed" is that we now measure cpu
| performance on much longer and more predictable runs. Not so
| much booting windows, more doing a hundred trillion FPMAC. But
| I still don't believe it.
| simne wrote:
| If consider every claim separate, looks possible.
|
| Everything, even claims to be better than CPU,GPU and TPU at
| once.
|
| But to make all claims in one business, in one solution, looks
| scam. Because every vector needs it's own very effective leader,
| and in real life they will compete for shared resources. It is
| extremely difficult to organize in such way, so will got overall
| system working smooth and be economically viable.
|
| In best case, I think possible for this company, to deliver some
| sort of very good number-crunching accelerator, and only then, to
| consider something more.
|
| But now I see too much self-confidence and too much hidden
| details.
|
| For example, all commodity hardware suffers from slow commodity
| DRAM and buses.
|
| It is possible to make complex solution, with custom DRAM (HBM),
| custom high speed bus, etc, but its net cost will be prohibitive
| for commodity market.
|
| So need some killer app, which will tolerate so high cost for
| some more important reason. This could be something for big corp,
| or govt, or military, or anything, but I cannot see any fit,
| which is not already handled with already existed solutions.
|
| For example, I could imagine, we got knowledge about
| 11-dimensional travel, but for this need too much computational
| power for current best hardware, so need something much more
| powerful, and it will pay off. But I don't see any signs of such
| knowledge.
| mhh__ wrote:
| I'll believe it when I see it.
|
| This triggers my bullshit detector however even delivering
| anything in this sector is deeply impressive so hat's off to them
| even if they're cheating as long as they ship.
| xxs wrote:
| 5mn TMSC - how did they win the bidding war; very few can
| afford the process alone.
| cestith wrote:
| I'm no foundry insider, but in other forms of manufacturing
| it's not entirely uncommon to sell slack time on your lines
| where you have tiny amounts of capacity unused by other
| contracts on an as-available basis. Yes, I'm suggesting their
| manufacturing may be the contract foundry equivalent of
| flying on standby.
| black3r wrote:
| The founder/CEO of this has already (co-)founded and sold 2
| hardware companies: SandForce and Skyera, he probably has the
| right connections and can afford it.
___________________________________________________________________
(page generated 2022-06-13 23:01 UTC)