Yes, there are some exceptions where it clearly states that a thinking model has been chosen like for kimi, but there is no such indicator for the GPT family from OpenAI and other major models.
I think it is quite reasonable to tell incompetents that they can't just cover their ass by claiming "you can't demand perfection".
These are the same kind of incompetents who want the pay but not the responsibility of the position. Who think that building a giant haystack of all of the data is the solution so they can illogically claim to have prevented something that because you had that needle in there somewhere! Except you never found it in time because you were too busy building the tower of Babel out of hay! It is just utterly idiotic double-think. (Cough, cough NSA!)
It's one thing for your blog post to be full of faux writing style, but also that letter to the organization... oof. I wouldn't enjoy receiving that from someone who attached a script that dumps all users from my database and the email, as well as my access logs, confirm they ran it
For determining the maximum performance achievable, the performance per watt is what matters, as the power consumption will always be limited by cooling and by the available power supply.
Even if we interpret the NVIDIA claim as referring to the performance available in a desktop, the GPU cards had power consumptions at most double in comparison with CPUs. Even with this extra factor there has been more than an order of magnitude between reality and the NVIDIA claims.
Moreover I am not sure whether around 2010 and before that, when these NVIDIA claims were frequent, the power permissible for PCIe cards had already reached 300 W, or it was still lower.
In any case the "100" factor claimed by NVIDIA was supported by flawed benchmarks, which compared an optimized parallel CUDA implementation of some algorithm with a naive sequential implementation on the CPU, instead of comparing it with an optimized multithreaded SIMD implementation on that CPU.
Well, power envelope IS the limit in many applications; anyone can build a LOBOS (Lots Of Boxes On Shelves) supercomputer, but data bandwidth and power will limit its usefullness and size.
Everyone has a power budget. For me, it's my desk outlet capacity (1.5kW); for a hyperscaler, it's the capacity of the power plant that feeds their datacenter (1.5GW); we both cannot exceed Pmax * MIPS/W of computation.
How is caching implemented in this scenario? I find it unlikely that two developers are going to ask the same exact question, so at a minimum some work has to be done to figure out “someone’s asked this before, fetch the response out of the cache.” But then the problem is that most questions are peppered with specific context that has to be represented in the response, so there’s really no way to cache that.
From my understanding (which is poor at best), the cache is about the separate parts of the input context. Once the LLM read a file the content of that file is cached (i.e. some representation that the LLM creates for that specific file, but I really have no idea how that works). So the next time you bring either directly or indirectly that file into the context the LLM doesn't have to do a full pass, but pull its understanding/representation from the cache and uses that to answer your question/perform the task.
I wrote awhile ago on here that he should stick to his domain.
I was downvoted big time. Ah, I love it when people provide an example so it can finally be exposed without me having to say anything.
Unfortunately this is a huge problem on here - many people step outside of their domains, even if on the surface it seems simple, but post gibberish and completely mangled stuff. How does this benefit people who get exposed to crap?
If you don't know you are wrong but have an itch to polish your ego a bit then what's stopping you (them), right.
People form very strong opinions on topic they barely understand. I'd say since they know little the opinions come mostly from emotions, which is hardly a good path for objective and deeper knowledge.
I added the following at the top of the blog post that I wrote yesterday: "All words in this blog post were written by a human being."
I don't particularly care if people question that, but the source repo is on GitHub: they can see all the edits that were made along the way. Most LLMs wouldn't deliberately add a million spelling or grammar mistakes to fake a human being... yet.
As for knowing what I'm talking about. Many of my blog posts are about stuff that I just learned, so I have many disclaimers that the reader should take everything with a grain of salt. :-) That said: I put a ridiculous amount of time in these things to make sure it's correct. Knowing that your stuff will be out there for others to criticize if a great motivator to do your homework.
It's a combination of cumbersome syntax and the vendor's poor API design and execution environment.
For a syntax example, compare python to Tcl. In python, there's a compact array lookup operator, and dictionaries allow string keys:
mydata["channel"][2]
Tcl, however, requires a function call to access an array index, resulting in nested function calls with magic numbers for the simplest expressions:
lindex [lindex $mydata 35] 2 # Tcl
Then there isn't any static type checking so you have to run code to see if it would work; the shape of a return may surprise you. Connecting to hardware may be your only opportunity to exercise certain code paths.
So for any non trivial task, Tcl becomes effectively write-only.
Some tools allow you to export Tcl scripts that automate tasks like project creation to help you avoid tracking intermediate objects in source control, but because the Tcl cwd path can change throughout a script, they export every source path as a hard coded absolute path, including whatever developer's home directory it might be residing in. This is not suitable for source control (because it would preclude building on any other machine) so then you have to post process these scripts before tracking them. But since it's Tcl there aren't good scriptable tools for programmatic Tcl AST manipulation, so you have to modify these files with some sort of a state machine, looking for various sentinels to trigger the various string replace behaviors you need. It's not all Tcl's fault, but if a vendor is only using Tcl for automation and you need automation, you have a battle ahead of you.
Outside the language, you'll often find that your runtime tool locks the UI thread to run your scripts, so long running operations are impossible to pause or cancel. And I've never seen a vendor expose adequate objects to allow full control, so often, the critical actions you hoped to automate are only possible through the GUI.
In the 90s, an integrated Tcl interpreter was a good sign that your vendor cared about developers. Today it's more a sign of neglect.
> Tcl, however, requires a function call to access an array index, resulting in nested function calls with magic numbers for the simplest expressions:
I do understand how that one can be frustrating to a newbie, but I can't fault that implementation choice when thinking about Tcl as a "Lisp but it's strings".
> Then there isn't any static type checking so you have to run code to see if it would work; the shape of a return may surprise you. Connecting to hardware may be your only opportunity to exercise certain code paths.
This, though, yeah. I feel this in my whole body. I haven't checked out Tcl 9.0 to see how it's changed, but Tcl 8.6's abbreviated compilation phase definitely doesn't leave any room for type much type inference ahead-of-time.
> sentinels
Tangential, but man I wish Tcl had `gensym` out of the box. That alone was enough to start my own programming language over a decade ago.
Everything else, I largely agree with. Short of a hard fork or the Tcl team splitting their time between maintaining for the sake of EDA vendors, and trying different approaches, I don't see much changing.
I really appreciate the time you took to share your experiences here.
My experience with Tcl is 30 years of using EDA tools, all of them equipped with this language from hell. Luckily, I've been to restrict the scripting part to the minimum. I'm sure that if you know the language well, you can see the foundational model that's behind it, but for occasional users, there's nothing predictable about it.
I couldn't tell you exactly all the thing that are wrong with it. Let's just say that a language where this is ok:
Similar amount of experience with tcl here (since dc_shell-t was released). I love working in tcl. It can be expressive, redable, sufficiently performant, and makes it easy and fast to develop and test new features and functions in even very complex EDA design flows with 100k lines of code.
I find it curious that so many of the criticisms of tcl are that it doesn't have some feature or behavior of some other language. That has never stopped me from accomplishing what is needed with clear, elegant code.
Rule #10 in the Dodekalogue [0] explains why your preferred comment style is not supported: a command is not expected immediately after the last argument of the previous command. Terminate the command per rule #1 and it is perfectly fine:
puts "Hello" ;# A comment
Isn't that the same number of characters one would type to start a javascript comment? //
Almost any programming language can be beautiful in its simplicity if you work with it on its own terms. tcl doesn't deserve the hate.
Of course it's still a thing. It takes 30 seconds, but it's there and requires energy.
Compare the smell of exhaust next time you do a cold and warm start of a combustion car. That smell is the engine running rich, because the fuel can't initially vaporise properly.
I used to think that getting admitted to YC was a major accomplishment. Maybe it was at some point, but at the college graduation parties of my daughter it seemed like pretty much everyone who tried had gotten in. Most collapsed after a few months due to infighting, funds mismanagement etc. It was fascinating to watch.
I think you mean "prestigious" rather than "major accomplishment". You're right, there was a small period of time when it was. However, that window didn't quite align with "best time to do YC" (several years prior to such prestige) nor with "best time to be doing YC" (the prestige embellishes your resume, which is useless if you're otherwise occupied).
It's interesting to me that YC has managed to dilute this prestige to a large extent. I don't think it's an inevitable result of scale: look at Google. I think "Xoogler" prestige has diminished, but it's not nearly as bad as what has happened to the YC label.
My theory is: YC never figured out their formula. The whole formula is essentially Paul Graham, who had a knack for trusting his gut (and sometimes his wife) when everything else in his "system" was saying NO.
Once they lost that, they had to rely on what was left, and it simply wasn't competitive anymore. It's like Apple in their John Sculley era. While Sculley is credited with growing Apple's revenue from $800 million to $8 billion, his approach created a "mess of dull SKUs" that eventually confused customers and diluted the brand.
They also have a (bad) habit of removing access to bookface for all the founders who aren't "active", decimating their network and in some ways discarding valuable knowledge around what didn't work.
reply