Hacker Newsnew | past | comments | ask | show | jobs | submit | sylware's commentslogin

I wonder which SOC they are using.

The article doesn’t mention the details, it just says:

> Ukraine Defense Drones makes most of its own components, and European suppliers fill most of the gaps.

Anyway I guess they can be STmicro electronics, NXP, Infineon…


I wonder from which foundries they used for those very SOCs.

Those manufacturers have their foundries in Europe, France, Italy, Germany, etc...

Maybe because they are "robust" chips, probably far away from the best silicon process, and when I mean best, I mean 'with the smallest features.'

Yes but you don’t need 2/3nm chip in a drone! STmicro is a global leader in many sectors for example, like automotive chips, probably Ukraine is using those chips.

I wonder what is the silicon process for the SOC in those drones. Really.

The current hardware used is self-hosting mini-server grade, and certainly not on the latest silicon process. "Slow" is expected.

It is not the ISA, but the implementations and those horrible SDKs which needs to be adjusted for RISC-V (actually any new ISA).

RISC-V needs extremely performant implementations, that on the best silicon process, until then RISC-V _will be_ "slow".

Not to mention, RISC-V is 'standard ISA': assembly writted software is more than appropriate in many cases.


Is this a drone or a transport for delta force hit and run?

If, for even 1s, they get in a position which is threatening, in any way, Big Tech AI (mostly US based if not all), they will be raided by international finance to be dismantled and poached hardcore with some massive US "investment funds" (which looks more and more as "weaponized" international finance!!). Only china is very immune to international finance. Those funds have tens of thousands of billions of $, basically, in a world of money, there is near zero resistance.

I don't see a world where they become threatening and the employees don't become rich from investors flooding in.

Where have you been in the last 2 decades?

Don’t think that’s a fair interpretation of what I said.

Liquid money rich? No.

Can get pulled for big tech packages? Also no, for most of the employees.

AFAIK, big tech didn’t aggressively poach OpenAI-like talent, they did spend 10M+ pay packages but it was for a select few research scientists. Some folks left and came but it boiled down to culture mostly.


What???

microsoft openai is Big Tech.

Are you ok?


Ah yes, OpenAI the puppet of Microsoft that is currently declaring war against GitHub, sounds logical.

Internal battles or scheme to dodge anti-trust regulations. Don't let them fool you, it is Big Tech.

I am almost sure it was done so carefully that you can extract it from the abominations which are the whatng cartel web engines with a direct to OS abstraction layer that with only some little amount of work.

What is the model used for maths since it is not LLM? This model would have to be strap on a formal solver as a tool. Are those models training to use "scratch memory"? So many question about the models used for real maths.

The article is about an LLM being used for real maths.

Exactly why I do ask for non LLM, since it is not specialized for maths.

That's exactly what you did not ask. You or your translation tool are not fully accurate on the English language.

I think now LLM are surprisinly good at high level math.

Then specialized models would be even better, more so if the ML/inference uses a formal solver and maybe some scratch memory.

But with hardware IP locks like x86_64.

Better favor as much as possible RISC-V implementations.

But, I don't know if there are already good modern-desktop-grade RISC-V implementations (in the US, Sifive is moving fast as far as I know)... and the hard part: accessing the latest and greatest silicon process of TMSC, aka ~5GHz.

Those markets are completely saturated, namely at best, it will be very slow unless something big does happen: for instance AMD adapts its best micro-architecture to RISC-V (ISA decoding mostly), etc.

And if valve start to distribute a client with a strong RISC-V game compilation framework...


This is kind of a solution in search for a problem. RISC-V will grow only if people find some value in it. If it solves their actual problems in ways that other architectures can't.

Yeah, the primary reason RISC-V exists is political (the desire to have an "open source" CPU architecture). As noble as that may be, it's not enough to get people or companies to use (or even manufacture!) it. It'll either be economical (costs) and/or performance (including efficiency) that drives people.

It took ARM decades to get to where it is, and that involved a long stint in low-margin niche applications like embedded or appliances where x86 was poorly suited due to head and power consumption.


I don't think that's the primary reason there's momentum there. The reason is to avoid ARM licensing fees and IP usage restrictions.

I think you'll see ever more accelerating RISC-V adoption in China if the United States continues on its "cold war" style mentality about relations with them.

That said we're a long long way from Actually Existing RISC-V being at performance parity with ARM64, let alone x86.


Yep, licensing fee and IP usage restrictions is a massive decision point on some silicon markets.

The other massive point: RISC-V integrates a lot of CPU "we know now" in a very elegant "sweet spot".

And it is not china only, the best implementations are US, and RISC-V is a US/berkley initiative re-centered in switzerland for "neutrality" reasons.

If good large RISC-V implementations do reach TMSC silicon process (5GHz), some markets won't even look at arm or x86 anymore.

And there is the ultimate "standard ISA" point: assembly written code then become very appropriate, hence strong de-coupling from all those, very few, backdoor injecting compilers.

On many of my personal projects, I don't bother anymore: I write RISC-V assembly which I run with a small x86_64 interpreter, that with a very simple pre-processor and assembler, aka SDK toolchain complexity close to 0 compared to the other abominations.

And I think the main drawback is: big mistakes will be made, and you must account for them.


Standard ISA being rv64gc? Isn't MIPS 2 easier to emulate? It has less funky encoding.

There are tons of RISC-V SOCs and mini-boards. Ez and inexpensive native port...

That might be true for the desktop, but RISC-V is wonderful from a pedagogical and research standpoint for academic uses and in the embedded world its license and "only pay for what you need" is also quite nice.

> Sifive is moving fast as far as I know)

worked with their cores in $pastJob. I'd say their main products are flowery promises and long errata sheets.


Which models? Which nasty issues did you encounter?

Anybody is aware of a public token (severely limited) I can use to test claude coding ability? You know using CURL.

I am itching at testing claude for assembly coding and c++ to plain and simple C ports.


Anybody: can I test claude code without a whatng cartel web engine? web API using curl with an "public" token? Anything else?

I am itching at testing its ability to code assembly.


Wait, I can get such a key and perform gemini API requests with curl? (probably limited in some ways)

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: