I might buy this if those languages were actually faster. Instead, implementations of scheme with no commercial backers run circles around scripting languages with huge budgets.
Common Lisp can match and exceed languages like Java without the backing of a megacorp.
Carp Lisp is basically identical to C in performance and old PS games were shipped in a proprietary dialect (GOAL) and had very good performance.
Lisp has proven itself capable great performance at every abstraction level.
function can do what a macro does, but it must run every single time while the macro can run just one time during the final code generation.
Let's say you have some Java-style a + b. It needs to work on native strings (concatenation) along with various kinds of ints and floats. The issue is that each one of these works differently internally, so the system is going to look at the incoming symbols and metasymbols (inferred type data) and is going to dynamically change between different functions like ADD_STR, ADD_INT8, ADD_INT32, ADD_FLOAT32, etc. If it did this at runtime by introspecting the type with some `switch(incomingType)` statement which involves all kinds of extra data and branches that clog the cache and create branches (two of the worst things you can do for performance). Instead, the macro (though they probably don't call it that) looks at everything and hardwires the correct output.
This hardwiring and its associated performance is the difference between a function and a macro. A macro `foo!(a b)` can inline into the current function while the function alternative must save all the registers to the stack and create a new stack frame which is very expensive.
The beauty of lisp macros is how functions and macros look the same. You may think that `(+ a b)` is the same as your favorite languages' `a + b`, but most lisps also allow `(+ a b c)` too. `+` is a macro rather than a function and it knows that `(+ a b c)` needs to convert to something more like `(+ a (+ b c))` and a typed lisp may go further to something like `(+f64 a (+f64 b c))`.
Your lisp criticism is orthogonal to the idea of lisp itself. Lisps like Coalton (lambda calculus) or Shen (sequent calculus) are strongly typed.
AI is an interesting point too where being closer to a raw AST is likely an advantage because it can focus more on the semantics instead of the syntax.
You can wrap parentheses around anything and call it Lisp, but I specified Common Lisp and pg's article clearly wasn't contemplating anything like Shen. Surface syntax is near irrelevant though.
I feel you're now contradicting your own statements now. You said: "[maybe] Lisp is just another Blub", but when pointed out that Lisp (and Lispers) is evolving, you're saying "pg clearly meant [the other Lisp]"...
Of course we're not talking about "parenthesis". Clojure even added square brackets for arguments and destructuring, it's not about the syntax, I agree on that.
This is like when a vacuum doesn’t pick something up after a few tries. The user picks the thing up, looks at it, then puts it back down and tries again until they finally give up and move it to the trash.
If you can’t design a solution and instead waste days and who knows how much money in tokens instead of just turning on your brain for a few minutes, you are in the wrong profession.
Taalas HC1 AI uses Llama 3.1 8B, but takes up a massive 53B transistors and 815mm2 on TSMC N6 (nearly at the reticle limit of 858mm2). N2 is a little less than 3x as dense (110MTr/mm2 vs 313MTr/mm2).
This chip would still be 272mm2 on N2 which is an eye-watering $30k/wafer and bigger than a 9950x or Nvidia 5070.
This just isn't feasible. Some of the latest-gen LLMs seem to have 5-10T parameters or about 1000x more. I don't know that taping out just one chip makes economic sense let alone the 300-1000 chips required for a cutting-edge model. Things like continuing education so your model knows about the latest NPM packages or world news is super important, but seems like it would require new chips.
There are a TON of uses for an 8B parameter models on the edge, but this is WAY too big to put on the edge of anything. Something like a 10mm2 100m parameter voice model might be feasible on the edge, but only for expensive devices, but most of those are TSMC 28nm (up to 29MTr/mm2) or GF FDX22 (up to 40MTR/mm2) which would increase the AI chip to the point where it would absolutely dominate the BOM.
> Things like continuing education so your model knows about the latest NPM packages or world news is super important, but seems like it would require new chips.
They probably have a few ideas around that. Me, personally, I'd have one main expensive chip (replaced every 10 years, or whatever), with a secondary cheap chip in front of it that gets replaced every year or so.
The secondary chip could act the way RAG does, or perhaps both chips together can act as LoRA.
Either way, 99.999% of the knowledge is static, you just need to fine-tune the weights with that remaining 0.001% knowledge, which can be done using RAG or LoRA on a much smaller (thus cheaper) disposable chip.
The better solution would be making part of the chip cluster use something like FPGA which can be reprogrammed.
Text to speech or diagnostics equipment where the core model is relatively small and never changes seems like the ideal application. You might be able to fit something in the 25-30B range in 2nm to 14A, but it would need a way to update.
Large models are simply out of the question in my opinion. If you need 400+ different chip designs, it’ll be billions of dollars to tape out before you even make the first chip.
> The better solution would be making part of the chip cluster use something like FPGA which can be reprogrammed.
I'm not sure I follow (It's late, I am tired and I haven't had my dinner yet. That's my stupid trifecta!)
The original chip has the weights, so it's literally just a bunch of on-die (read-only) memory cells. The FPGA, while you could use it for the memory cells, would be way too expensive to use as pure memory. Typically one would hook up (read-only) storage to it, so you still need that read-only chip anyway.
The FPGA is just the compute bits, but this chip has on-die weights, not just compute.
I was proposing that the they have the base weights on a primary (permanent) chip, and have a secondary (replaceable) smaller chip with weights for a specific use-case, or for fine-tuning with new knowledge/updates to the model.
The matrices can be multiplied LoRA style, applying the matrix in the secondary chip to the primary chip, resulting in up-to-date weights through which the prompt is pushed.
I'm wondering about something different. FPGA seems ideal for an AI chip because you can simply flash the latest model. The downsides are low density and low clockspeed. It seems that you can only fit 100-300M parameters in even very large FPGA, but that seems like it would be enough for most finetuning.
I'm thinking of a situation where you do the initial model calculations in hardware on the Taalas chip then hand that off to the FPGA to do the LoRA subset of calculations in hardware that can be continuously re-tuned to keep the model up-to-date. This would probably reduce throughput (or at least increase latency), but would save tons of money by allowing you to use the chips longer.
Yeah, they're clearly just starting out and just shipped their very first proof of concept. But to me, their plans seem generally reasonable https://taalas.com/the-path-to-ubiquitous-ai/, and like I wrote, if this kind of thing succeeds and could become some kind of cheaply producible commodity component, I think there's huge value in that. Alas, maybe not as a frontier model replacement, but say 10 years from now you can drop a cheap raspberry pi like device in your Lan and have a fast local engine for things like text sentiment analysis, text summarisation, voice recognition, basic vision and things like that, that would be pretty exciting to me (but maybe as you outlined, impossible in practice)
There is a reasonable kernel of an idea here, but only if you dial expectations WAY back. The 10 years speculation is just wrong though. Even in 10 years, their 8B param model isn't going to be in consumer devices.
6nm is just 7nm++ and the process will be a decade old in a few months. In the decade since, we've only had a slightly less than 3x increase in transistor density and that's including EUV, BSPD, and GAAFET (which means progress is likely going to slow down even more).
Even if we hit another 3x increase, their 815mm2 design will still be a bit over 90mm2. For comparison, the entire M5 Pro/Max CPU die is just 61.7nm.
If our current progress somehow holds (not likely), even 20 years from now the 8B model would be 30mm2. You need 30 years of dead consistent progress to get it down to an includable 10mm2.
As you can see, this doesn't make sense to invest in. As to the stuff like voice recognition or basic vision, these can often fit within 100m parameter models which would be around 10mm2 on their current 6nm design. That's doable today in custom edge computing devices.
The other possible use is cheap fallback models for AI companies. Moving to N2 and shrinking chips to 600mm2 to improve yields a bit would give about 50B parameters with 3 chips plus another FPGA-ish programmable chip for continuing training and interconnects for everything. You'd need hundreds of thousands of chips produced for that exact AI model just to get costs below $100,000 per board.
That seems like a lot of money for the AI model you are essentially giving away, but maybe it still beats the power and price of GPU server racks.
The government isn't going to be making chip fabs go any faster which is the biggest limitation here.
The second big issue is that it takes months to fab chips meaning your hardware AI is months to maybe a year or more behind the times when it lands.
I do think it makes sense for something like a medical scanner where the model simply doesn't need constant updates, but that doesn't need government involvement to ship.
M1 released 6 years ago, but AMD/Intel still can't get close to ARM cores in IPC. Anandtech was observing that Apple had better IPC in their phone chips YEARS before M1. Lots of people discredited it as "apples and oranges" because the ISAs were different, but investigative teams from Intel and AMD absolutely HAD to know the truth.
This has both a technical and human component.
On the human side, top x86 execs refused to see any threat coming. They must have thought Apple couldn't overcome the x86 software moat, thought the chips were for servers, consoles, or some other non-PC device, or perhaps they simply couldn't believe what their investigative teams told them.
At the same time, we're 6 years post-launch. The proof of ARM's capability is clear. x86 server marketshare is about to hit just 50% and Microsoft is pushing ARM hard as a replacement for x86. Either all the x86 engineers are completely incompetent and incapable of learning from years of ARM designs or there are aspects of x86 that makes copying those designs infeasible.
> M1 released 6 years ago, but AMD/Intel still can't get close to ARM cores in IPC.
> teams from Intel and AMD absolutely HAD to know the truth.
These people are professionals that acknowledge IPC is a stupid metric. If you switch your statement to SIMD throughput, now ARM NEON has the lower IPC and x86 looks like space age technology. They're optimized for different workloads.
x86 vendors recognized that they could recoup the majority of efficiency that Apple Silicon has without buying an architectural license for ARM. Intel invested early on big.LITTLE, and AMD drilled down on denser nodes for their preexisting designs. As both businesses converge on each other's ideas, their SOCs have adapted most of ARMs' greatest mobile innovations. Even before that, x86 hardware was always usable - AMD was shipping faster integrated GPUs than the M1 Pro before the M1 ever hit shelves.
All of this makes sense, nothing objectively prevents the x86 architecture from being power-efficient. Arm LTD. would have gouged any of those vendors for their IP, and even with an architectural license it's not like AMD or Intel would get usable core designs from Arm. There was no reason to pivot to ARM for either company, they both saw Qualcomm and could read the writing on the wall.
> x86 server marketshare is about to hit just 50% and Microsoft is pushing ARM hard as a replacement for x86
That's Nvidia's work, no credit is due to Microsoft or Apple for reshaping the server market. Apple's early ARM hardware was outright ignored for server/HPC applications, leading to the discontinuation of the Mac Pro. Apple was entirely incapable of pivoting their mobile chipsets to the server scale, surprising nobody that had paid attention to Apple's godawful raster/GPGPU acceleration stack. The Ultra hardware looked like a dog's dinner compared to x86 arches like CDNA.
The Graviton and Grace chips that displaced x86 servers did it because they are slower, cheaper and less feature-dense. Graviton for the bare minimum of Raspberry Pi-tier web serving, and Grace for the high-end of "we need CUDA and enough bandwidth for Infiniband" that made trillions in the HPC market.
> These people are professionals that acknowledge IPC is a stupid metric.
Even if you think IPC is a stupid metric (it's not), ARM is still wiping the floor in total performance, performance per area, and performance per watt.
> If you switch your statement to SIMD throughput, now ARM NEON has the lower IPC and x86 looks like space age technology. They're optimized for different workloads.
Fujitsu also makes a 512-bit SIMD that has very good performance, but that large SIMD eats area and power while giving very little back to consumers. Honestly, SME co-processors or 6-wide SVE are much closer to "space age" than simply making a wider packed SIMD.
> x86 vendors recognized that they could recoup the majority of efficiency that Apple Silicon has without buying an architectural license for ARM.
AMD actually bought an architectural license and Intel used to have one too. They could (and should) undercut ARM entirely by making x86+RISC-V cores. You can talk about Intel's E-cores or AMD C-cores, but they still don't compare in the key metrics.
> AMD was shipping faster integrated GPUs than the M1 Pro before the M1 ever hit shelves.
Which GPUs are you talking about? 4800U (Vega 8) was around 50% slower than M1's GPU. 5700G released in April 2021 and also had the same Vega 8 GPU design. They didn't see a bump until RDNA2 in Rembrandt in 2022 (by which point Apple was already on M2).
> nothing objectively prevents the x86 architecture from being power-efficient.
Citation needed. This is like saying nothing prevents branch delay slots from being good or VLIW/EPIC/Itanium is just as good as anything else. uop cache, extra pipeline stages for decoding, and memory ordering prediction are enough by themselves to use more power when under load. If you have actual proof that x86 workarounds have absolutely ZERO energy/area/latency, then show it.
> That's Nvidia's work, no credit is due to Microsoft or Apple for reshaping the server market.
Linus Torvalds pointed out that ARM server wouldn't take off until devs could run ARM natively on their laptops. Apple provided those laptops.
MS claims Cobalt 200 lowers carbon footprint by 40% vs x86 (which should mostly reflect power consumption per unit of work). ARM accounted for over a third of Azure deployments in 2025 and should increase as C200 becomes available.
> The Graviton and Grace chips that displaced x86 servers did it because they are slower, cheaper and less feature-dense. Graviton for the bare minimum of Raspberry Pi-tier web serving
That hasn't been true for a long time now. Graviton5 in particular is a big deal. It removes the NUMA issues resulting in much lower latencies (and higher performance) for a lot of things. It gives 2.6x more cache per core and a general ~25% performance uplift (SAP said it was up to 60% for their workloads) which is more than the difference between graviton4 and Zen5 for most workloads. Graviton accounts for more than 50% of all new servers in AWS and basically all of their 1000 largest customers are using them.
> Apple was entirely incapable of pivoting their mobile chipsets to the server scale, surprising nobody that had paid attention to Apple's godawful raster/GPGPU acceleration stack. The Ultra hardware looked like a dog's dinner compared to x86 arches like CDNA.
Apple wasn't incapable -- they didn't want to because they aren't in the server market. That is the entire reason X-Elite/Nuvia exists. GPU stack is completely orthogonal to making server CPUs (you can make good CPUs without making good GPUs).
Common Lisp can match and exceed languages like Java without the backing of a megacorp.
Carp Lisp is basically identical to C in performance and old PS games were shipped in a proprietary dialect (GOAL) and had very good performance.
Lisp has proven itself capable great performance at every abstraction level.
reply