Skip Navigation

InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)AU
Posts
36
Comments
8
Joined
2 yr. ago

Technology @lemmy.world

One Law to Rule Them All: The Iron Law of Software Performance

Technology @lemmy.world

Why This Python Performance Trick Doesn’t Matter Anymore

Technology @lemmy.world

Python Performance: Why 'if not list' is 2x Faster Than Using len()

Technology @lemmy.world

Hardware-Aware Coding: CPU Architecture Concepts Every Developer Should Know

Technology @lemmy.world

Context Switching and Performance: What Every Developer Should Know

Technology @lemmy.world

How Unix Spell Ran in 64kB RAM

Technology @lemmy.world

Linux Context Switching Internals: Part 1 - Process State and Memory

Technology @lemmy.world

The CAP Theorem of Clustering: Why Every Algorithm Must Sacrifice Something

Technology @lemmy.world

Disillusioning the Magic of the fork System Call

Technology @lemmy.world

An Unreachable Hidden XKCD Easter Egg inside CPython

Technology @lemmy.world

CPython's Garbage Collector and its Impact on Application Performance

Technology @lemmy.world

The Pythonic Emptiness

Technology @lemmy.world

A Selective Survey of Efficient Speculative Decoding Techniques for LLM Inference

Technology @lemmy.world

CPython Runtime Internals: Key Data Structures & Runtime Bootstrapping

Technology @lemmy.world

The Design & Implementation of the CPython Virtual Machine

Technology @lemmy.world

Are Function Calls Still Slow in Python? An Analysis of Recent Optimizations in CPython

Technology @lemmy.world

Two Threads, One Core: How Simultaneous Multithreading Works Under the Hood

Technology @lemmy.world

CPython Garbage Collection: The Internal Mechanics and Algorithms

Technology @lemmy.world

How Python Compares Floats and Ints: When Equals Isn’t Really Equal

Technology @lemmy.world

A Deep Dive into the Underlying Architecture of Groq's LPU

  • Interesting. I'm just thinking aloud to understand this.

    In this case, the models are looking at a few sequence of bytes in their context and are able to predict the next byte(s) with good accuracy, which allows efficient encoding. Most of our memories are associative, i.e. we associate them with some concept/name/idea. So, do you mean, our brain uses the concept to predict a token which gets decoded in the form of a memory?

  • Yes. They also mention that using such large models for compression is not practical because their size thwarts any amount of data you might want to compress. But this result gives a good picture into how generalized such large models are, and how well they are able to predict the next tokens for image/audio data at a high accuracy.

  • Do you mean the number of tokens in the LLM's tokenizer, or the dictionary size of the compression algorithm?

    The vocab size of the pretrained models is not mentioned anywhere in the paper. Although, they did conduct an experiment where they measured compression performance while using tokenizers of different vocabulary sizes.

    If you meant the dictionary size of the compression algorithm, then there was no dictionary because they only used arithmetic coding to do the compression which doesn't use dictionaries.