Chat/GPT-4 released

I don't know White lotus, Ozark, Breaking Bad, Chernobyl, first season of Cobra Kai, Games of Thrones/True Detective/Fargo/Sucession/Mindhunter/Big Littles lies had there moments, there still solid content getting made.
 
sfsuphysics said:
Also saw with the writers strike one of the things they are demanding is job protection from AI
Click to expand...
Hollywood loves rehashes of movies, decide you want to make a new Die Hard reboot feed ChatGPT the scripts to all the others as well as a few similar movies. Ask it to make something new along those lines with a new protagonist and similar run time and boom you have a script to a known formula and now you just pay 1 guy shit to edit it for clarity.
There is no way some studios didn’t try that as an experiment and find it to be viable.

Then again looking at the new Transformers trailer I’m not even sure they bothered with the editor…
 
LukeTbk said:
I don't know White lotus, Ozark, Breaking Bad, Chernobyl, first season of Cobra Kai, Games of Thrones/True Detective/Fargo/Sucession/Mindhunter/Big Littles lies had there moments, there still solid content getting made.
Click to expand...
From my point of view tv is just getting better and better. shrug. I don't bother with big block busters, remakes, sequals, etc, most of them seem pretty boring to me.
 
Lakados said:
Hollywood loves rehashes of movies, decide you want to make a new Die Hard reboot feed ChatGPT the scripts to all the others as well as a few similar movies. Ask it to make something new along those lines with a new protagonist and similar run time and boom you have a script to a known formula and now you just pay 1 guy shit to edit it for clarity.
Click to expand...
The last time an AI did this we got SkyScraper.
 
LukeTbk said:
The last time an AI did this we got SkyScraper.
Click to expand...
I like you got the reference!!!

But that was then this is now, given many of the AI generated songs, short stories, and D&D campaigns are considered objectively good with some fine tune training I have no doubt that studios would try this if they weren’t already.
 
erek said:
Did you like Picard?
Click to expand...
I haven't watched it. Also didn't get to finish Deep Space Nine because netflix decided to remove it midway through :mad: .

General media I've liked in the past decade:
Arcane, Counterpart, goliath, the americans, normal people, dune, everything everywhere all at once, a quiet place, parasite, banshees of inisherin, only murders in the building, downton abbey, spiderman: into the spiderverse (was surprised by this one, since I've generally dont like superhero movies).
Shows that I've just watched a few episodes here and there because my roommates are watching them and they seem good (need to go back and watch):
severance, patriot, the bridge, barry

Anyways, sorry for thread derail.
 
  • Like
Reactions: erek
like this
1683252399883.png


“A senior software engineer at Google wrote a critique asserting that the internet search leader is losing its edge in artificial intelligence to the open-source community, where many independent researchers use AI technology to make rapid and unexpected advances.

The engineer, Luke Sernau, published the document on an internal system at Google in early April. Over the past few weeks, the document was shared thousands of times among Googlers, according to a person familiar with the matter, who asked not to be named because they were not authorized to discuss internal company matters. On Thursday, the document was published by the consulting firm SemiAnalysis, and made the rounds in Silicon Valley.”
 
Interesting hot take on the latest from MidJourney

 
erek said:
AI Needs Specialized Processors. Crypto Miners Say They Have Them https://www.bloomberg.com/news/articles/2023-05-10/ether-crypto-miners-woo-artificial-intelligence-ai-with-gpu-chips-services?leadSource=uverify wall
Click to expand...
Sure they do, FPGAs. Especially the modern ones with a large die and HBM, which constitutes a very end computatinal device surpassing gpus in many workloads and even custom ASICs for smaller scale systems. Additinally thay can be reconfigured in such a way to dynamically change the learning network.

I believe current ai approaches are pretty fixed in scope and large enough in size companies are willing to commit to ASICs in addition to general purpose devices like GPUs and CPUs. Currently ai is almost completely centralized in approach for computation and highly distributed regarding data. Making a minable ai with GPUs or FPGAs would provide the opportunity to distribute the computation which could pose different benefits.
 
  • Like
Reactions: erek
like this
cdabc123 said:
Sure they do, FPGAs. Especially the modern ones with a large die and HBM, which constitutes a very end computatinal device surpassing gpus in many workloads and even custom ASICs for smaller scale systems. Additinally thay can be reconfigured in such a way to dynamically change the learning network.

I believe current ai approaches are pretty fixed in scope and large enough in size companies are willing to commit to ASICs in addition to general purpose devices like GPUs and CPUs. Currently ai is almost completely centralized in approach for computation and highly distributed regarding data. Making a minable ai with GPUs or FPGAs would provide the opportunity to distribute the computation which could pose different benefits.
Click to expand...
So don't get rid of these Radeon VIIs? ;-)
 
  • Like
Reactions: erek
like this
cdabc123 said:
Sure they do, FPGAs. Especially the modern ones with a large die and HBM, which constitutes a very end computatinal device surpassing gpus in many workloads and even custom ASICs for smaller scale systems. Additinally thay can be reconfigured in such a way to dynamically change the learning network.

I believe current ai approaches are pretty fixed in scope and large enough in size companies are willing to commit to ASICs in addition to general purpose devices like GPUs and CPUs. Currently ai is almost completely centralized in approach for computation and highly distributed regarding data. Making a minable ai with GPUs or FPGAs would provide the opportunity to distribute the computation which could pose different benefits.
Click to expand...
Im not an expert in AI or GPUs, but I would question that FPGAs are better general solutions for AI then GPUs. GPUs are optimized for matrix calculations, and nvidia have tuned their GPUs for AI workloads specifically with inclusing of int8 and fp8 datatypes.

Im also not sure what you mean by FPGAs surpassing custom ASIC in many workloads for smaller scale systems. Once you have a design that's working on an FPGA, converting it to an ASIC will always give you better performance, efficiency, and/or cost (at scale).

FPGAs are better than ASIC when:
1) You only need a few chips (ASIC cost is enormous for a few chips)
2) You are okay with the performance of an FPGA (the same design for ASIC will be higher performance, smaller, and/or more efficient)
3) You need to be able to reprogram the logic after deployment.
4) You are prototyping (end goal is still ASIC)
5) You need a solution FAST (skip the entire taping out process)
 
  • Like
Reactions: erek
like this
serpretetsky said:
Im not an expert in AI or GPUs, but I would question that FPGAs are better general solutions for AI then GPUs. GPUs are optimized for matrix calculations, and nvidia have tuned their GPUs for AI workloads specifically with inclusing of int8 and fp8 datatypes.

Im also not sure what you mean by FPGAs surpassing custom ASIC in many workloads for smaller scale systems. Once you have a design that's working on an FPGA, converting it to an ASIC will always give you better performance, efficiency, and/or cost (at scale).

FPGAs are better than ASIC when:
1) You only need a few chips (ASIC cost is enormous for a few chips)
2) You are okay with the performance of an FPGA (the same design for ASIC will be higher performance, smaller, and/or more efficient)
3) You need to be able to reprogram the logic after deployment.
4) You are prototyping (end goal is still ASIC)
5) You need a solution FAST (skip the entire taping out process)
Click to expand...

Yes, current AI workloads are largly optimized for GPUs at the scale currently utilized, as well as modern GPUs being excellent compute devices. Its also a much easier solution to build GPU clusters and handle development mostly on the software side. Especially for a field that is rapidly shifting, and an enormous software problem like AI.

I believe the problem of training ai algorithms and implementing them as an interfaceable machine is not strictly a finite in scope matrix calculation problem. FPGAs, specifically in clusters, would offer a network with a much greater degree of flexibility for the different ways to efficiently train on a variety of data. Imagine a interconnected device (supercomputer) with local nodes consisting of a large FPGAs paired with sizable HBM. Have these nodes tightly interconected (FPGAs are a fantastic solution for very high performance networking, even at large scale, ie. microsoft bing seaches, ect.). Then program the device in a way that allows for the algorithm of the nodes, as well as the whole structure of this network to be dynamically configured in a efficient manner.

For the cost of an enterprise gpu a very capable FPGA can be equiped with memory on par to the gpu and advantages in many specialized or dynamic workloads. There are many software problems currently tuned to the advantages of gpus that will not be optimal on a FPGA. There are many problems that are not easily solvable with a ASIC (for example the problems scope is too dynamic). Additionally, at any scale you are still paying for the cost of the high performance memory. Build an ASIC with HBM on the die and in most workloads the off the shelf FPGA with HBM will be more lucrative.

Regarding, repurposed mining equipment. At a medium scale, In Ethereum mining, FPGAs nearly surpassed ASICS In value due to the memory intensive workload and Xilinx being able to take an off the shelf HBM equipped FPGA and sell it at reasonable cost. GPUs again showed superiority in value.
 
Last edited:
  • Like
Reactions: erek
like this
cdabc123 said:
Yes, current AI workloads are largly optimized for GPUs at the scale currently utilized, as well as modern GPUs being excellent compute devices. Its also a much easier solution to build GPU clusters and handle development mostly on the software side. Especially for a field that is rapidly shifting, and an enormous software problem like AI.

I believe the problem of training ai algorithms and implementing them as an interfaceable machine is not strictly a finite in scope matrix calculation problem. FPGAs, specifically in clusters, would offer a network with a much greater degree of flexibility for the different ways to efficiently train on a variety of data. Imagine a interconnected device (supercomputer) with local nodes consisting of a large FPGAs paired with sizable HBM. Have these nodes tightly interconected (FPGAs are a fantastic solution for very high performance networking, even at large scale, ie. microsoft bing seaches, ect.). Then program the device in a way that allows for the algorithm of the nodes, as well as the whole structure of this network to be dynamically configured in a efficient manner.

For the cost of an enterprise gpu a very capable FPGA can be equiped with memory on par to the gpu and advantages in many specialized or dynamic workloads. There are many software problems currently tuned to the advantages of gpus that will not be optimal on a FPGA. There are many problems that are not easily solvable with a ASIC (for example the problems scope is too dynamic). Additionally, at any scale you are still paying for the cost of the high performance memory. Build an ASIC with HBM on the die and in most workloads the off the shelf FPGA with HBM will be more lucrative.

Regarding, repurposed mining equipment. At a medium scale, In Ethereum mining, FPGAs nearly surpassed ASICS In value due to the memory intensive workload and Xilinx being able to take an off the shelf HBM equipped FPGA and sell it at reasonable cost. GPUs again showed superiority in value.
Click to expand...
Perhaps you are right. My hesitation comes from the fact that for the same die size FPGA compared to GPU (or any CPU or ASIC), you are giving up a lot of transistors and die space to make a generic reprogammable device. I think last time I tried to research this it was something like 40:1. Meaning to recreate roughly the same logic on an FPGA as some ASIC you would need a chip about 40 times bigger in area (this was ignoring power and frequency penalty as well, just area). Would need to confirm that number, I'm not currently confident in it.

The penalty exists because of the added complexity of all of the additional slice muxes, routing muxes, and generic LUTs instead of dedicated gates and dedicated routing. These same things are also what slows down timing. With a dedicated circuit a bit can go from one flip flop, through a little big of dedicated combinatorial logic, and to terminate at another flip flop. In and FPGA, the same bit now has to go through a sea of muxes, through multiple layers of LUTs, and again through a sea of muxes before arriving at the terminating flip flop.

Ofcourse even with such a penalty it's still possible that an FPGA is better. If you are using less than 1/40 the full potential of a GPU, then perhaps an FPGA is better. Ofcourse this is also all ignoring the current ecosystem of AI. Not sure how hard it is to develop for FPGA vs GPU (I imagine nvidia makes this pretty easy).

There is also the less fashionable discussion of development tools in general. FPGA tools just always feel.... like a couple of engineers built them in their garage (despite being made by enormous companies). They are buggy, they crash, and sometimes bugs are just documented somewhere instead of actually fixed. Even if all of the tools were perfect, I feel like software development is just more flexible in general.

Let me give one example. If im compiling c code, it is trivial, and indeed expected, that your makefiles and/or an environment is setup so that you only compile the changes that you make to a single file. This is simple in C because code just lives in addresses in memory, and with relative addressing it is an easy job for a linker to just change jump addresses. This is certainly possible in FPGA development, but it's more complicated, and there are always trade offs. By default this should be done for synthesis/mapping automatically (converting verilog/vhdl to xilinx/altera primitives, LUTS, FF's, BRAM, etc). But for post-synthesis placement and route this not so trivial (this step is usually longer than synthesis). You can try to fence off parts of the chip to not change, but now you have added an additional restriction that may make it harder for the tools to fit your design, or meet timing, or route the signals. You also now have to maintain these fence lines and adjust them if one module takes up too much space. It is not automatic. It requires planning.

Coding environments also seem generally more polished for software development. I feel like everytime I jump into coding some C the tools are great, they find syntax errors early, there are plenty of good plugins for notepad++, visual studio code, etc. For FPGA development you can use the built-in editors in Vivado, etc. But I never liked them. In my current project it sometimes doesn't even find basic syntax errors. Only after 1 hour of synthesis do I realize I missed a comma ( at least it's not after the 5+ hour placement routing step). If your project is just verilog I've heard Verilator is a pretty good linter, but my projects are mixed vhdl/verilog :( . vhdl support seems just terrible.

Ofcourse a lot of this could just be my inexperience, but I feel like I just have less problems doing C programming (and im definitly not a highly experienced C programmer).

Well... I guess that's my rant for the day.

edit: dont get me started on errors reported from tools. Trying to decypher errors returned from the tools requires some sort of enlightenment. Sometimes they dont even return errors, it just fails and that's that.
 
Last edited:
serpretetsky said:
Perhaps you are right. My hesitation comes from the fact that for the same die size FPGA compared to GPU (or any CPU or ASIC), you are giving up a lot of transistors and die space to make a generic reprogammable device. I think last time I tried to research this it was something like 40:1. Meaning to recreate roughly the same logic on an FPGA as some ASIC you would need a chip about 40 times bigger in area (this was ignoring power and frequency penalty as well, just area). Would need to confirm that number, I'm not currently confident in it.

The penalty exists because of the added complexity of all of the additional slice muxes, routing muxes, and generic LUTs instead of dedicated gates and dedicated routing. These same things are also what slows down timing. With a dedicated circuit a bit can go from one flip flop, through a little big of dedicated combinatorial logic, and to terminate at another flip flop. In and FPGA, the same bit now has to go through a sea of muxes, through multiple layers of LUTs, and again through a sea of muxes before arriving at the terminating flip flop.

Ofcourse even with such a penalty it's still possible that an FPGA is better. If you are using less than 1/40 the full potential of a GPU, then perhaps an FPGA is better. Ofcourse this is also all ignoring the current ecosystem of AI. Not sure how hard it is to develop for FPGA vs GPU (I imagine nvidia makes this pretty easy).

There is also the less fashionable discussion of development tools in general. FPGA tools just always feel.... like a couple of engineers built them in their garage (despite being made by enormous companies). They are buggy, they crash, and sometimes bugs are just documented somewhere instead of actually fixed. Even if all of the tools were perfect, I feel like software development is just more flexible in general.

Let me give one example. If im compiling c code, it is trivial, and indeed expected, that your makefiles and/or an environment is setup so that you only compile the changes that you make to a single file. This is simple in C because code just lives in addresses in memory, and with relative addressing it is an easy job for a linker to just change jump addresses. This is certainly possible in FPGA development, but it's more complicated, and there are always trade offs. By default this should be done for synthesis/mapping automatically (converting verilog/vhdl to xilinx/altera primitives, LUTS, FF's, BRAM, etc). But for post-synthesis placement and route this not so trivial (this step is usually longer than synthesis). You can try to fence off parts of the chip to not change, but now you have added an additional restriction that may make it harder for the tools to fit your design, or meet timing, or route the signals. You also now have to maintain these fence lines and adjust them if one module takes up too much space. It is not automatic. It requires planning.

Coding environments also seem generally more polished for software development. I feel like everytime I jump into coding some C the tools are great, they find syntax errors early, there are plenty of good plugins for notepad++, visual studio code, etc. For FPGA development you can use the built-in editors in Vivado, etc. But I never liked them. In my current project it sometimes doesn't even find basic syntax errors. Only after 1 hour of synthesis do I realize I missed a comma ( at least it's not after the 5+ hour placement routing step). If your project is just verilog I've heard Verilator is a pretty good linter, but my projects are mixed vhdl/verilog :( . vhdl support seems just terrible.

Ofcourse a lot of this could just be my inexperience, but I feel like I just have less problems doing C programming (and im definitly not a highly experienced C programmer).

Well... I guess that's my rant for the day.

edit: dont get me started on errors reported from tools. Trying to decypher errors returned from the tools requires some sort of enlightenment. Sometimes they dont even return errors, it just fails and that's that.
Click to expand...
Scope this out

https://www.theregister.com/2023/05/12/github_microsoft_openai_copilot/
 
You must log in or register to reply here.
Back
Top