HNHacker News
TopNewBestAskShowJobs

zerodensity

106 karma · joined January 27, 2023

submissionscomments
zerodensity··on The algorithmic anti-culture of scale
So not having used twitter how does that algorithm differ from this one? I mean he did not follow anything... Does Twitter have some magic sauce that unguided gives you exactly what you want or something?
zerodensity··on Lifers, Dayjobbers, and the Independently Wealthy: A Letter to a Former Student
I don't really care for this argument. We are currently not living in a meritocracy.

In a true meritocracy everyone must have the same starting point and rise up within the ranks based on their merits from there. In our society we do not all start at the same place. There are people born into wealth and people born into poverty. So some people have to struggle harder to get to the same place as others where born into. Essentially an anti-meritocracy system.

If anything UBIs will help make the system more meritocratic since the ones the bottom no longer need to climb the first hill.

zerodensity··on GPT-Prompt-Engineer
This was magical really made my day. Thanks for this.
zerodensity··on AI Safety and the Age of Dislightenment
Are people's self worth really intricately tied to what they do for a living?

I mean I enjoy my work, for the most part anyway. But if I could spend all my time with my family and hobbies I see that as an improvement rather then something to be depressed about.

zerodensity··on AI Safety and the Age of Dislightenment
And who will be that sanctioning agency? The US? The EU? Russia? China? A global collaboration? Who will enforce?
zerodensity··on A physicist who bets that gravity can’t be quantized
How exactly does quantized space-time contradict the Standard Model and General Relativity?
zerodensity··on Engineers should focus on writing
That sounds like good old Waterfall to me. Or in its current form SAFE. 90% communication 10% code. And something like that is basically what it takes when you have hundreds or thousands of people working on the same product.

Making sure that everyone understands how to use your part (and that the overall architecture is at least coherent), in a big project, is actually more important than if that part is of high quality. And since communication is more important it's the seniors responsibility.

Sometimes I really want to go back to the junior years it was in general more fun back then. But getting to decide the architecture does have its charms.

zerodensity··on Sarah Silverman is suing OpenAI and Meta for copyright infringement
If you are making a commercial product I think not. Or do you mean educational as in educating the AI itself?
zerodensity··on The Code Review Pyramid (2022)
I might hold an unpopular view here but I do not like reviewing small focused changes.

When a feature is implemented I preferably want the entire thing before me when reviewing. Otherwise I find it hard to keep track of everything that has happened.

Not to mention that the small focused changes might be reviewed by different people leaving only the implementer in full knowledge of everything that was done.

Peer/Assembly programming help but if you do peer/assembly programming reviews are mostly a waste of time (especially for assembly programming).

zerodensity··on Workers are competing for their own jobs
Wow just wow
zerodensity··on Software engineers hate code
I have heard of this magical beast "readable code" but have not yet encountered it in the wild.
zerodensity··on Software engineers hate code
All code is not created equal. In a project there is normally some divide between shared code and service specific code. This divide can be as simple as a base class and its children or a library and the microservices that use it. I declare that shared code is sacred and should only be touched for a good reason. (Note: sacred does not imply good)

So when reviewing my carelevel is highly dependent on if shared code is touched. If the commit only contains changes in the leafs eg subclass / single microservice my gut instinct is to trust the code and go into LGTM mode (if it goes wrong it's at least localized). But if shared code is touched I don't trust it, I deep dive and complain about everything I can think of.

zerodensity··on Google claims to have proved its supremacy with new quantum computer
That clears that up thanks.
zerodensity··on Dynamic Languages Strike Back (2008)
In static languages sure types are very important for performance.

But in a dynamic language like python your options are limited.

Consider:

def add(a: int, b: int) -> int: return a + b

assert add(1,2) == 3

a, b = random.choice((3, 4), ("foo", "bar"))

assert add(a,b) in (7, "foobar")

In the first call we use ints and are golden. In the second we get ints or strings and we cannot know which until runtime.

So if we are going to use type information for speed improvements how should we proceed?

Some ideas.

1. Generate special purpose small (32 or 64 bit) integer version in a custom type aware bytecode format or ASM and a common version of the function. Use run-time typechecks to decide which one to use.

We generate two versions of the bytecode instead of one we also run some optimizations on the integer version to actually get a speedup when we call it.

To do the integer optimization we probably need a new special type aware bytecode format. (or just compile to assembly directly) To get advantage over the interpretor where everything including integers are objects.

When we call 'add' we just check the type send the values to our new bytecode format and bam faster add (possibly faster anyways).

Having two versions of the function will take extra memory and increase startup latency (during compilation to bytecode)

In some cases we could directly call the integer version of add like in the first call we know we are working with ints, in the second call we cannot know until the type check if we are dealing with ints or strings.

Will all of this be worth it? We use extra memory, slower startup time and an extra typcheck when we are not 100% clear on the types.

For hot code it could be worth but we do not know what code is hot and what is cold until we run the program. We could tell the compiler what is hot and what's not like 'numba' does, but then we are going beyond typing.

So why does python not so this? Well for a start it's very unclear that we will gain performance from this extra compilation / bytecode swapping but it will slow down startup. It will also be a massive change to the internals of the standard interpretor and need tons on man hours supporting this beast.

At a first glance it does not look that hard to do this extra compilation but the add function is very simple. What about more complex code that calls unknown methods that have not been defined yet possibly even loaded at very late at runtime. Will the ASM layer help or hinder when you need to go back and forth between the interpretor and optimized code? The interpretor really does not have enough information to make intelligent decision on this.

2. We could go the route of static languages. Compile only a special case integer version.

Assuming that we always use the function correctly this could be fast.

But this would be extremely unsafe in a dynamic language, if we don't have an integer but do integer additions on the objects internals anything could happenn.

Now if you have full static typing you can do this, really you should do exactly this. It is safe to assume that we are calling the function with the correct types, since it's enforced at the language level. Which leads us to do all kinds of optimizations that the dynamic nature of python prevents.

3. Just use a JIT like 'pypy'.

A JIT would do basically option 1 but only after hot code paths have been identified. Startup time is less of an issue since we delay compilation untill we are sure we need it (or fairly sure at least).

Type hinting could help guide the JIT if you using fairly specific types such as 'int32' instead of int to highlight that we are just interested in small numbers. But the information might also be missleading so it might opt out of using it altogether.

-------------------------------

Cpython does not do (1) since its not clear that you get any substantial speedup and startup latency is a big deal. Does not do (2) since its super unsafe. And it's not a JIT (3).

zerodensity··on Tips for programmers to stay ahead of generative AI
I don't know about this, from my point of view to learn how to program you need to actually... program.

Trying stuff over and over again in different variations using maybe different languages, dealing with all the errors the frustration and overcoming them.

I think that using chat gpt or similar llms to learn how to code is similar to using Midjorney to learn how to draw.

Don't get me wrong you might be able to produce results fast but taking shortcuts is not going to speed up understanding.

zerodensity··on Google claims to have proved its supremacy with new quantum computer
How so you mean calculating them on the fly? You need to at least load the data to perform operations on it.
zerodensity··on Dynamic Languages Strike Back (2008)
JSON is better than xml which it replaced. It's now such a defacto standard that if you make an API without json it will just be a hassle for your api users. Doesn't really matter if your encoding format is better or not.

You can still have schemas in the code through. We use alot of pydantic at work for this. You have your data schema class that is statically typed which you interact with and decide/encode it to json in the background.

All services expose an api to get JSON schemas from the apis so you can automatically generate the remote types used by other services when they change.

Using schemas for remote services has made life simpler for us so I would say schemas are a huge win. Not supporting JSON is not something I see happening anytime soon though, multiple parallel encodings based on schemas might be a possibility though.

zerodensity··on Dynamic Languages Strike Back (2008)
Well the idea is orthogonal to performance really. Static types makes it simpler to automatically spot issues in the "static" portion of the code. It's also very useful for metaprogramming since types are included at runtime. Additionally it gives better documentation for free. Gradual typing wont be able to make interpretors faster though. A jit compiler could in theory take advantage of it but since CPython is not a JIT it will not.
zerodensity··on Deep-sea mining may soon ease the world's battery-metal shortage
You make a valid point but if the last century has shown us anything it's that our global civilisation hates the ocean (all large bodies of water really, above or below ground) and we want them gone or poisoned and dead. So if this cost even 5% more I don't see it happening.
zerodensity··on Google claims to have proved its supremacy with new quantum computer
Questing regarding error correction and logical qbits. From my very limited understanding logical qbits could mitigate some of the error but uses multiple physical qbits for every logical qbits. Has anyone created a quantum computer that has logical qbits? Say a small one with 16 physical 4 logical qbits quantum computer, or similar.
zerodensity··on Douglas Hofstadter changes his mind on Deep Learning and AI risk
But self driving cars have a much lower accident rate than humans. How did you lose the bet?
zerodensity··on C’s Biggest Mistake (2009)
According to the bible (https://www.agner.org/optimize/) it's faster to use a loop with length than walking though a pointer so not having a length will make it slower to walk the string whole also making things like simd optimizations harder for the compiler to do.
zerodensity··on C’s Biggest Mistake (2009)
Can't think of a single case where null terminated strings are more efficient. Could you give some examples?
zerodensity··on Amount of work that once bought an hour of light now buys 51 years of it (2017)
When is electric heating not 100% efficient? I thought they were by definition.
zerodensity··on Deepmind Alphadev: Faster sorting algorithms discovered using deep RL
For a time that is what happened. Every year you would get a new CPU and that would be faster at pretty much everything than the version the year before. But then we hit the clockspeed wall and the only way of making faster CPUs was to add complexity to the internals of the CPUs. So branch prediction, micro code pipelining, larger caches, simd instructions more CPU cores ect was the result.

So nowadays a new CPU might not be better at everything then the previous version but it will most likely have more cache and some internal improvements to pipelining/concurrency.

Given this, for newer versions it can be useful to add instructions to take advantage of extra pipelining or using a different instruction that happen to be faster now.

zerodensity··on Browsers are essential and how operating systems are holding them back (2022) [pdf] (2022)
I'm pretty sure Apple updates it's browser just as much as Google chrome, firefox or edge is updated.

Browsers in general do often change with new temporary user facing features.

People choose iOS because it's a status symbol or they like the design of the interface. Not because they are afraid of updates.

zerodensity··on Path to a free, self-taught education in Computer Science
I mean 2 element arrays will be fast to sort.
zerodensity··on The Hundred-Year Programming Language
I mean as a field we love to reinvent the wheel over and over again, even in the same language if it's not in the stdlib (or even if it is) it's not uncommon to find multiple versions of the same thing. Take for example SQL database drivers in python, I have at various companies worked with at least 4 of them. They all do virtually the same thing with some minor differences.

So I don't think we will ever land in a situation where everyone uses the same thing.

zerodensity··on I use C when I believe in memory safety
Could you explain how functional without side effects helps cache locality?
zerodensity··on Critique of the mind/body problem
I mean they have the math down it's the interpretation (and for us mortals the math) that's causing all the confusion.

Particles behave non-locally which is really really not cool :(. From that you only have a bad list of options to choose from...

Do you go for non-local hidden variables

Multiverse spawning photons

Super determinism

More dimensions perhaps? Maybe the problem goes away if you have 11

← PreviousPage 2 of 3Next →