exyi

I don't know how large are those boxes, but normal CPU L1 cache has 32 or 48KB which should be plenty for this. Python opcodes for this program are going to be tiny, and the interpreter itself uses the instruction-L1 cache (which is another 32-48KB). I hope the sequential scan of the big array won't flush the L1 cache (there should be 12-way associativity with LRU, so I don't see how it could).

Anyway, there is no need to have 256 integers, just 2 is enough. When I try that, the results are similar: 17.5 ms (unsorted) / 12.5 ms (sorted)

It corresponds to a way more than one branch at instruction level. The branch prediction AFAIK does not care based on what are you branching, it just assumes branches will go in similar sequences as they did last time. If the Python 'if' is never taken, the instruction-level predictor will learn that after the comparison operation, there is an 'if' operation and then another array access operation. If the Python 'if' is unpredictable unpredictable, CPU predictor can't be sure which opcode are we processing after 'if', so there will be penalty.

I intentionally stayed in the small integer range to avoid benchmarking the cache. 256 distinct values should fit into L1 just fine in both cases.

I'm now thinking that the difference might be even larger if we instead avoid small integers and let the CPU get stuck chasing pointers. The idea is that it gets stuck on a memory access, which forces it to speculate much further, which in turn makes it backtrack a longer path if a branch was mispredicted. I'm obviously no expert on this, feel free to correct me

The results for 1B range instead of 255 are 17.6 ms for unsorted / 68.2 ms for sorted! We are back to what the original article observed and it's a way stronger effect than what branch prediction can offer. So don't sort your arrays, keep them in the order the boxed values were allocated ;)

It is! Although my test case is probably an unrealistically bad scenario:

It's the classic, why is processing sorted array faster than unsorted one

    def f(arr):
        r = True
        for x in arr:
           if x > 128: r = not r
        return r

    arr = [ random.randint(0, 255) for i in range(0, 1000_000) ]
    arr_sorted = list(sorted(arr))

    %timeit f(arr)
    %timeit f(arr_sorted)

Results are (on my machine): 17.5 ms for unsorted, and 13.5 ms for sorted. For comparison, in a compiled language, the difference is 4x

I'd assume that the serializer is writing directly into the output buffer, so you'd have to shift everything left by one character if you overallocate. With the added checks for this, it might be faster to compute it precisely the first time.

Even if you are running it constantly, the per token power consumption is likely going to be in a similar range, not to mention you'd need 10+ macs for the throughput.

It's apparently a monoclonal antibody (https://en.wikipedia.org/wiki/Bimekizumab). That's just a protein, so it might actually be easier to make in your garage than your average small molecule ;) ... not that either would be practically possible, but it might be available in countries where they don't care too much about patents and such

Except that XPath and JSONPath are overpowered. I'd welcome a simple standard path syntax for JSON, for instance, I'd want to use for reporting schema errors in JSON document ($.users[10].name must be a string). I can use JSONPath, sure, but even this subset is annoying to parse - compared to a filepath which you can parse with `path.split('/')`.

If we have enough resources dedicated to this problem, why are we still burning coal/gas for power on sunny days? I'm definitely not against researching carbon capture, but it currently isn't the "the solution the planet desperately needs"

> Preventing extraction is pointless because it has the same effect as the first one

Yes, but it might raise oil prices, effectively making the carbon tax apply globally. Unless OPEC just compensates by increasing production. IMHO carbon tax indeed better tool for EU/US, given that most of oil production out of "our" control

Yes it's 2 years (if you are buying it as the consumer)

[1]: https://www.eccnet.eu/consumer-rights/what-are-my-consumer-r...

I think this is just transposed masonry, the wall looks ok if gravity is on the left. "Transposed" is redundant though, since I assume it will work in both grid-template-columns and grid-template-rows

Nice :) Today it's possible to do a lot of it with vanilla Python (sortof):

   something(lambda x: [
      x2 := x + 10, # define variables

      [ print(f"Number: {i})
        for i in range(x) ], # loop

      [ 0 for i in range(x)
           if print(f"Number: {i}") or True
           if print(f"Second line: {i}") ], # loop if you prefer "normal code order"

      0 if x > 0 else {}[f'{n} should be positive'], # conditions and asserts (throws KeyError, but includes the error message)

      x2 * 2 # return
   ][-1])

note: I'm not responsible for coworkers injuring you after committing this

This is only an issue with plain numbers, however. If you'd have the number in an object or array, you'd detect the truncation just as well. Since using jsonl for a plain list of numbers is... overkill, I'd say it's not an issue.

On the other hand, requiring line terminators in the standard would inevitably lead to incompatibility issues. Most software would accept unterminated files, because text libraries do; and so some files will not be terminated. Some applications do not line-terminate files even on Linux (hello VSCode), and it would be even more problematic on Windows

Exactly, the AI chatbots is the perfect technology for autoscamming people.

Yes, it's a downside of using them in b-tree indexes. However, the purpose of having an ID is usually to use it for lookup (from foreign keys, query string arguments, ...). If you create an index on two columns, you won't be able to lookup using only the second value, at least not in Postgres.

If it had 200 nucleotides you'd know for sure it's a contamination. RNA isn't very stable (in our conditions, I have no idea how it does at 3 Kelvin, blasted with radiation for a million years...)

At least in GNOME, I can turn off the laptop screen without closing the lid

...you can't compare minimalism/configurability in this way

Sure there is no silver bullet. However, I don't know about anything which would since this flathub problem as well as Nix:

* Works on all (most) distros * Builds the packages from sources, binaries are only a cache to speed things up. * Bonus: already has a lot of software packaged

And proprietary works in the system too, the build step can just download the binary from internet. It's not a preferred way to do it, but you don't have to build a broken system just because of few packages without source access

Surely nobody is waking up 5 minutes ahead of class if they have to travel to school/work.

You wouldn't want pirates capturing a nuclear reactor :| And protecting the ship at all times would be too expensive

It seems ok to me, EVs have about 13kWh/100km efficiency while an older gasoline car would consume 10l/100km. And yes, it's quite plausible that the engine was running during loading and unloading

It has to, if you want to be able to unlock the device with a fingerprint

Sure. [hypothetically] After Microsoft makes new "Azure UI Test", it will surely kill Playwright in favor of the new thing. It wouldn't make sense to maintain two browser automation frameworks. The second one being bound to their cloud offering is just a ... coincidence?

So it took about 10 years to get into production. OP isn't claiming it's impossible, just that it's far from being practical. You could definitely say that about EUV 15y ago

They don't claim that pure FP is the future. Immutable is better default IMHO, make it explicitly mutable if you need it and know what you are doing.

Actually, implementing AVL tree in purely functional way is easy, I'd say it's easier than doing it in the mutable in-place way. It will allocate more, but will have the optimal O(something) complexity.

Many other algorithms are much harder, though, especially those requiring fast array indexing (graph search, hash tables, ...)

I think he counts academic computer scientists more as mathematicians than developers.

Parsing JSON in powershell is not that bad either, `ConvertFrom-Json` pretty much does what you need. AFAIK there is nothing as convenient as nu's `parse`

nushell seems to have better way of parsing the string-only outputs of other commands.

https://www.nushell.sh/book/commands/parse.html

I don't know how to do a similar thing in powershell.

> To me interesting question is that is it even possible to build rich strucure-aware shell-like cli environment that would allow seamless integration of external polyglot programs...

Problem is that most of the classic Unix programs output in some messy format. It would be nice if we could agree that each command has --json flag (for example) which will make the output trivial to parse programmatically in any other advanced shell.