csl
Joined 18 years ago
Joined 18 years ago
See https://docs.astral.sh/uv/reference/environment/#uv_no_binar...
In many ways, things were much easier back then: Direct access to most of the hardware, flat memory layout, smaller and vastly simpler ISAs, smaller programs (meaning shorter disassemblies to wade through), no protected mode so you could overwrite anything in RAM and so on. And you wouldn't even have to do it live in-memory, just disassemble the program piecewise from disk. People did extraordinary things back then, and you vastly underestimate their capabilities. Sure, you had to write a lot of tooling yourself, but it was simpler times.
I am not trying to detract from the copy protection mechanism, which truly is ingenious. I was just genuinely curious whether I was misunderstanding anything from the article.
Edit: Guess it depends on the details and amount of "obfuscation" that he mentions.
— N.H. Abel (1802–1829)
Ignoring obvious scalability problems, wouldn’t it be possible to manufacture that with a pretty decent environmental footprint from various carbon neutral bio sources?
They have an example where this code is compiled:
def sumitup(n):
total = 0
for i in range(n):
total = total + i
return total
It was optimized quite well, but still had loops. I know this is a lot to ask, but I would have expected it to be possible to specialize it to a loopless variant: def sumitup(n):
if n < 0:
return 0
else:
return n*(n-1) // 2
Clang 4+ actually finds this optimization, but gcc and icc doesn't seem to: https://godbolt.org/g/v4zhrmThat is, the assembly generated by clang seems to be equivalent to
if n <= 0:
return 0
else:
return ((n-1)*(n-2) >> 1) + (n-1)
which might even run faster on the CPU, due to the speficic code emitted.I'd love to see a comparison of the various JIT libraries. I guess both give you optimizations and register allocation for free. Of course, the JITting speed is quite important as well.
uv is still quite new though. Perhaps you can open an issue and ask for that?