Hw about testing same input vs output with same seed on different dates. If its a different model it will return different output.
Isn’t this not true since these models run with a non-zero temperature?
Readit Newszomnoys commented on OpenAI dropped the price of o3 by 80% twitter.com/sama/status/1... · Posted by u/mfiguiere
Postgres can develop problematic behavior if you have high churn tables - tables with lots of deletes on them.
If you have many inserts and deletes on a table, the table will build up tombstones and postgres will eventually be forced to vacuum the table. This doesn't block normal operation, but auto vacuums on large tables can be resource intensive - especially on the storage/io side. And this - at worst - can turn into a resource contention so you either end up with an infinite auto vacuum (because the vacuum can't keep up fast enough), or a severe performance impact on all queries on the system (and since this is your postgres-as-redis, there is a good chance all of the hot paths rely on the cache and get slowed down significantly).
Both of these result in different kinds of fun - either your applications just stop working because postgres is busy cleaning up, or you end up with some horrible table bloat in the future, which will take hours and hours of application downtime to fix, because your drives are fast, but not that fast.
There are ways to work around this, naturally. You could have an expiration key with an index on it, and do "select * from cache order by expiration_key desc limit 1", and throw pg_partman at it to partition the table based on the expiration key, and drop old values by dropping partitions and such... but at some point you start wondering if using a system meant for this kinda workload is easier.
I believe the author addresses this by making the table `UNLOGGED`. https://www.crunchydata.com/blog/postgresl-unlogged-tables. These have less overhead.
zomnoys commented on Overhead of Python asyncio tasks textual.textualize.io/blo... · Posted by u/willm
After running that code on both a Windows SB3 and major souped up Lenovo running Ubuntu...I just feel inadequate.
Above anything, this shows the performance gains from 3.10 -> 3.11:
>> python3.10 create_task_overhead.py
100,000 tasks 185,694 tasks per/s
200,000 tasks 165,581 tasks per/s
300,000 tasks 170,857 tasks per/s
400,000 tasks 159,081 tasks per/s
500,000 tasks 162,640 tasks per/s
600,000 tasks 158,779 tasks per/s
700,000 tasks 161,779 tasks per/s
800,000 tasks 179,965 tasks per/s
900,000 tasks 160,913 tasks per/s
1,000,000 tasks 162,767 tasks per/s
>> python3.11 create_task_overhead.py
100,000 tasks 289,318 tasks per/s
200,000 tasks 265,293 tasks per/s
300,000 tasks 266,011 tasks per/s
400,000 tasks 259,821 tasks per/s
500,000 tasks 251,819 tasks per/s
600,000 tasks 267,441 tasks per/s
700,000 tasks 251,789 tasks per/s
800,000 tasks 254,303 tasks per/s
900,000 tasks 249,894 tasks per/s
1,000,000 tasks 266,581 tasks per/sI am currently in the online MS in CS from UT Austin, and I am really enjoying it. I’m just doing one class at a time for fun. I’m only in my second class right now, but I’m excited for this to add new courses!
zomnoys commented on How does database indexing work? (2008) stackoverflow.com/questio... · Posted by u/luu
...the same way as non-database indexing? e.g. a lookup table for values in a different order than they're stored
This feels a bit reductionary. Database indexes definitely have more to consider than just simple lookup tables. I’d say that mental model breaks down in practice.
zomnoys commented on Sleep has a role in developing Alzheimer's qz.com/1737881/scientists... · Posted by u/laurex
This is briefly touched upon in “Why we sleep: unlocking the power of sleep and dreams” by Matthew Walker. I highly recommend it!