If this article was written a year ago, I would have agreed.
But knowing what I know today, I highly doubt that the outcomes of LLM/non-LLM users will be anywhere close to similar.
LLMs are exceptionally good at building prototypes.
If the professor needs a month, Bob will be done with the basic prototype of that paper by lunch on the same day, and try out dozens of hypotheses by the end of the day.
He will not be chasing some error for two weeks, the LLM will very likely figure it out in matter of minutes, or not make it in the first place.
Instructing it to validate intermediate results and to profile along the way can do magic.
The article is correct that Bob will not have understood anything, but if he wants to, he can spend the rest of the year trying to understand what the LLM has built for him, after verifying that the approach actually works in the first couple of weeks already.
Even better, he can ask the LLM to train him to do the same if he wishes.
Learn why things work the way they do, why something doesn't converge, etc.
Assuming that Bob is willing to do all that, he will progress way faster than Alice.
LLMs won't take anything away if you are still willing to take the time to understand what it's actually building and why things are done that way.
5 years from now, Alice will be using LLMs just like Bob, or without a job if she refuses to, because the place will be full of Bobs, with or without understanding.
Yes, the government knows how to lie with statistics. Since the introduction of the so-called "one-euro jobs", the unemployment has gone down only because people who took such jobs were not counted as unemployed anymore, even though their situation has not been improved.
Just send an email to this woman---she might send your mac back!
My wife just told me that Iranians, like the ones in this case, don't like to use stolen things.
Thanks for your insights, there is a lot of value for me in your post.
I have an intense dislike for VHDL.
I have yet to meet an engineer who likes it!
I hate it with passion, but it lets me write circuits in the way I want.
Luckily, emacs VHDL mode makes me type less.
If you've done non-trivial FPGA work you have probably experienced the agony of waiting an hour and a half for a design to compiler and another N hours for it to simulate before discovering problems.
My simulations never took hours.
I use GHDL (an open source tool that converts VHDL into C++) to simulate my code, which is much slower than running Modelsim in a virtual machine.
So I guess that you are working on much larger problems than I do.
I have tried using a high level language before writing my circuits in VHDL before.
But the results were not very good, apart from learning a lot more about the actual algorithm/circuit.
Either I coded at a too high of a level, which would be impossible in an FPGA (e.g., accessing a true dual port block RAM at 3 different addresses in a clock cycle), or I ended up simulating a lot of hardware just to make sure that it will work.
But the point is, no matter which approach I tried, it was painful, so I ended up choosing the workflow that is less painful.
I'd have to know more specifics to be able to comment beyond a certain level.
I am developing a marker detection system that runs at 100fps, with 640x480 8-bit grayscale images.
First I am doing CCL to find anything in the image that could be a marker.
At the same time, some features are accumulated for each detected component (potential marker).
Then the features are used to find which component is a real marker and what's its ID.
And finally, the markers have some spacial information that allows me to find out the position and orientation of the camera.
Even though the FPGA that I use is the largest of all Cyclone II FPGAs with 70k LEs, I have to juggle registers and block RAM because it's too small to store all data in the registers, and using up too many registers substantially increases the time to place&route the design.
I maintain that FPGA's are, fundamentally, still about electrical engineering and not about software development. These, at certain levels, become vastly different disciplines. Once FPGA compilers become 100 to 1,000 times faster and FPGA's come with 100 to 1,000 times more resources for the money the two worlds will probably blur into one very quickly for most applications.
I agree, and I would add that the compilers need to be smarter about parallelizing the code.
So while being able to perform better than the alternatives, the FPGAs are still a pain to develop for.
Even if the compilers are faster, and FPGAs are bigger, writing code for FPGAs feels still more like writing assembly code rather than code that is easily accessible "for the masses".
But I would be happy if the compilers become just 10x faster!
That's perfectly possible, but only the newer FPGAs are big enough to store the whole image in the registers.
If I had a bigger FPGA, I would not bother doing all this memory juggling that I am doing now and place all my data into the registers.
And then wait for 10 hours for the software to produce the bitstream!
Probably some combo of your pixel's X/Y coord and/or just a (very large) random number.
I would go with X/Y because it requires less memory than a random number.
Besides, random numbers on FPGAs need extra (though not much!) logic to produce them in LFSRs.
No, I am not one of them :) Thanks for the reference! I am drawing my inspiration from Bailey, and more recently Ma et al.
They label an image line by line and merge the labels during the blanking period.
If you start merging labels while the image is processed then data might get lost if the merged label occurs after the merge.
The paper that you reference divides the image into regions, so that the merging can start earlier, because labels used in one region are independent of the other regions.
If it starts earlier, it also ends earlier, so that new data can be processed.
In my case, there is no need for such high performance, just a real time requirement of 100fps for 640x480 images, where CCL is used for feature extraction.
The work by Bailey and his group is good enough, and the reference can be done in the future, if there is need for more throughput!
My workflow is a lot different from the one that you describe.
I don't use any soft cores, and write everything in VHDL!
I have used soft cores before, but they were kind of not to my liking.
I miss the short feedback loop (my PC is a Mac and the synthesis tools run in a VM).
After trying out a couple of environments, I ended up using open source tools---GHDL for VHDL->C++ compilation and simulation, and GTKwave for waveform inspection.
Usually, I start with a testbench a testbench that instantiates my empty design under test.
The testbench reads some test image that I draw in photoshop.
It prints some debugging values, and the wave inspection helps to figure out what's going on.
If it works in the simulator, it usually works on the FPGA!
But the biggest advantage is that it takes just some seconds to do all that.
I will give the softcore approach another chance once my deadline is over!
Someone just needs to design a high level language that can be synthesised; something akin to a python of the FPGA world if you will.
The advantage of FPGAs is that they allow nontrivial parallelism. On a CPU with 4 cores, you can run 4 instructions at a time (ignoring the pipelining). On the FPGA, you can run any number of operations at the same time, as long as the FPGA is big enough. The problem is not the low-level nature of hardware description languages, the problem is that we still don't have a smart compiler that can release us from the difficulty of writing nontrivial massively-parallel code.
At the moment, I am writing some computer vision code in VHDL. A part of the circuit will perform connected component labeling (CCL) on incoming images, because I want to extract some features from some object in the images. And CCL is actually a union find algorithm. The algorithm can be written in a normal programming language like Racket or even Java in a couple of hours. However, the same algorithm will take me weeks to work out and test in VHDL!
I have done some nontrivial work with FPGAs, and every single time it was hard, because every low-level detail has to be considered.
Maybe it is so hard because on FPGAs you are forced to optimize right from the start, whereas when using programming languages, you can develop a prototype quickly and then improve upon it?
How is your experience with developing stuff on FPGAs?
Good way to start is to learn one of the hardware description languages.
I liked the book by Pong P. Chu "FPGA Prototyping by VHDL Examples: Xilinx Spartan-3 Version".
The same book is also available for Verilog, which is another HDL.
Later on you can take a look into higher level HDLs, since creating hardware in VHDL and Verilog is tedious.
Wouldn't open data make a bus company more popular to another one that does not release its data to the public? But here in Colone there is only one bus company, which might be the reasons why there is no public API---why put extra effort if there is no competition?
Recently in Germany many banks introduced a new "security" feature that allows you to receive your TANs per SMS in order to do online transactions. The TANs are sent in plain text.
All you need is a UMTS receiver and a way to analyze the data, e.g., a software-defined radio implemented on an FPGA.
Now it is legal to do what everyone was doing already--to hack our own stuff. It is fascinating to see how laws catch up to the norm. Just wonder why it was illegal in the first place?
Next time when I want to publish a paper, I will take the work of someone else, claim that it's unreadable and difficult to understand, "clarify" parts that were unreadable, and put my name on it. I just cannot believe that things like that are common practice for some researchers.
That was a great read, thanks.
I didn't like that I had to download Adobe AIR for downloading and installing your app. What speaks against making a .dmg file and allowing the user to copy your app wherever she/he likes?
LLMs are exceptionally good at building prototypes. If the professor needs a month, Bob will be done with the basic prototype of that paper by lunch on the same day, and try out dozens of hypotheses by the end of the day. He will not be chasing some error for two weeks, the LLM will very likely figure it out in matter of minutes, or not make it in the first place. Instructing it to validate intermediate results and to profile along the way can do magic.
The article is correct that Bob will not have understood anything, but if he wants to, he can spend the rest of the year trying to understand what the LLM has built for him, after verifying that the approach actually works in the first couple of weeks already. Even better, he can ask the LLM to train him to do the same if he wishes. Learn why things work the way they do, why something doesn't converge, etc.
Assuming that Bob is willing to do all that, he will progress way faster than Alice. LLMs won't take anything away if you are still willing to take the time to understand what it's actually building and why things are done that way.
5 years from now, Alice will be using LLMs just like Bob, or without a job if she refuses to, because the place will be full of Bobs, with or without understanding.