yes, same chip

+ Windows

+ Screen

- ConnectX-7 Smart NIC

+ battery too. I've wondered if a mini pc with battery would make for a good form factor. I often move between places where I have a desk with a screen but still use a laptop because I want to just suspend and resume. If a mini pc had a small battery just to hold its RAM while suspended I could move between places and just plug in a single USB-C cable and have my full workstation up and running. The thermals could be better than in a laptop and having a built-in UPS better than with a desktop. But last time I checked no one packaged things like that.

There's the Khadas Mind series of mini pcs. They have a proprietary docking interface though. Agree that it would be great if this form-factor was more common.

What about the desktop version? It seemed like it is not a dgx since it has the CPUs cores done by mediatek

The DGX Spark/GB10 has CPU cores from Mediatek (in a pretty odd cluster configuration, too).

MediaTek said MediaTek made the CPU: https://www.mediatek.com/press-room/mediatek-collaborates-wi...

Well, MediaTek actually said they made most of the SoC in fact. But the actual CPU cores themselves are all but certainly off-the-shelf Cortex parts, since MediaTek doesn't have a custom core design at all afaik.

NVIDIA hasn't done custom CPU cores for anything they've yet branded "Grace". The original Grace data center CPU (paired with the Hopper data center GPU) used ARM Neoverse V2 cores. The "GB10" chip shipped in DGX Spark and announced here for RTX Spark uses Cortex X925 and Cortex A725 CPU cores.

Physically, NVIDIA did the GPU chiplet and Mediatek did the other chiplet that has the CPU, DRAM controller, and IO.

desktop is GB300, not GB10 like Spark

GB300 is nominally "available" in desktop form factor workstations priced around $100k. That's a few orders of magnitude away from the ordinary desktop PC market that consumers participate in.

Yeah this is why it’s important to get something with similar programmability for less money. I don’t need the power of a gb300 just to do experiments with tma or “tcgen05” instructions

they also announced a GB10/N1X windows desktop mini PC.

Why is the Postgres status: "56 / 100 Failing" ???

https://scanaislop.com/postgres/postgres ( @ 5ab239c )

- Errors: 0 ; Warnings: 6 --> "56 / 100 Failing" ???

Please check again, I just made a new release

> and the article doesn't provide any configuration details (like shared buffers, is huge pages enabled).

maybe ? : phoronix-test-suite/ob-cache/test-profiles/pts/pgbench-1.16.2/install.sh

  # start server
  SHARED_BUFFER_SIZE=\`echo \"\$SYS_MEMORY * 0.25 / 1\" | bc\`
  SHARED_BUFFER_SIZE=\$(( \$SHARED_BUFFER_SIZE < 8192 ? \$SHARED_BUFFER_SIZE : 8192 ))
  echo \"Buffer size is \${SHARED_BUFFER_SIZE}MB\" > \$LOG_FILE
  pg_/bin/pg_ctl start -o \"-c max_connections=6000 -c  shared_buffers=\${SHARED_BUFFER_SIZE}MB\"
  # wait for server to start

https://github.com/phoronix-test-suite/phoronix-test-suite/b...

Every geography has a timestamp.

> "fc is a lossless compressor for streams of IEEE-754 64-bit doubles."

The new OpenZL SDDL2 (Simple Data Description Language) supports several different floating-point types. It would be worthwhile to contribute some of the FC project's experience to OpenZL. Now the OpenZL supported types:

  | Type           | Size    |Endian|
  |----------------|---------|-----|
  | `Int8`         | 1 byte  | N/A |
  | `UInt8`        | 1 byte  | N/A |
  | `Int16LE/BE`   | 2 bytes | Yes |
  | `UInt16LE/BE`  | 2 bytes | Yes |
  | `Int32LE/BE`   | 4 bytes | Yes |
  | `UInt32LE/BE`  | 4 bytes | Yes |
  | `Int64LE/BE`   | 8 bytes | Yes |
  | `UInt64LE/BE`  | 8 bytes | Yes |
  | `Float16LE/BE` | 2 bytes | Yes |
  | `Float32LE/BE` | 4 bytes | Yes |
  | `Float64LE/BE` | 8 bytes | Yes |
  | `BFloat16LE/BE`| 2 bytes | Yes |
  | `Bytes(n)`     | n bytes | N/A |

Some links:

- https://github.com/facebook/openzl/releases/tag/v0.2.0

- https://openzl.org/getting-started/introduction/

- https://openzl.org/sddl/sddl2-announcement/

- https://openzl.org/sddl/core-concepts/

Thanks, this looks super relevant. I think the transferable part is the per-block selectrover predictors, strides, deltas, exponent/mantissa-ish structure, byte transpose, fallback raw/LZ, etc.sddl2 looks like a natural place to try some of that.

video: https://www.youtube.com/watch?v=8Ppw8254nLI

imho: the future is a specialized compressor optimized for your specific format. ( https://openzl.org/ , ... )

It's good, but is it "the future" when it's extra work?

Consider that you could hand-code an algorithm to recognize cats in images but we would rather let the machine just figure it out for itself. We're kind of averse to manual work and complexity where we can brute force or heuristic our way out of the problem. For the 80% of situations where piping it into zstd gets you to stay within budget (bandwidth, storage, cpu time, whatever your constraint is), it's not really worth doing about 5000% more effort to squeeze out thrice the speed and a third less size

It really is considerably better, but I wonder how many people will do it, which means less implicit marketing by seeing it everywhere like we do the other tools, which means even fewer people will know to do it, etc.

This seems very cool. Was going to suggest submitting it, but I see there was a fairly popular thread 5 months ago for anyone interested: https://news.ycombinator.com/item?id=45492803

That is an interesting link.

Does gmail use a special codec for storing emails ?

The biggest savings for a service like GMail are going to be based around deduplication - e.g. if you can recognize that a newsletter went out to a thousand subscribers and store those all as deltas from a "canonical" copy - congratulations, that's >1000:1 compression, better than you could achieve with any general-purpose compression. Similarly, if you can recognize that an email is an Amazon shipping confirmation or a Facebook message notification or some other commonly repeated "form letter", you can achieve huge savings by factoring out all the common elements in them, like images or stylesheets.

I kind of doubt they would do this to be honest. Every near-copy of a message is going to have small differences in at least the envelope (not sure if encoding differences are also possible depending on the server), and possibly going to be under different guarantees or jurisdictions. And it would just take one mistake to screw things up and leak data from one person to another. All for saving a few gigabytes over an account's lifetime. Doesn't really seem worth it, does it?

That's why a base and a delta. Whereas PP was talking about general compression algorithm, my question was different.

In line with the original comment, I was asking about specialized "codecs" for gmail.

Humans do not read the same email many times. That makes it a good target for compression. I believe machines do read the same email many times, but that could be architected around.

Yes.

These and other email specific redundancies ought to be covered by any specialized compression scheme. Also note, a lot of standard compression is deduplication. Fundamentally they are not that different.

Given that one needs to support deletes, this will end up looking like a garbage collected deduplication file system.

Thanks!

Looks similar to OpenZL ( https://openzl.org/ ) "OpenZL takes a description of your data and builds from it a specialized compressor optimized for your specific format."

Honestly, Openzl looks even cooler! It would be cool to have it integrated with parquet and avro encoders. If I understand correctly the compressed files should be decompressable with standard tools.

Even existing hardware can fail, and swapping out memory or disks is expensive these days. :-(