[COFF] AI and spin locks

[COFF] AI and spin locks

[Warren Toomey via COFF]

I was just trying to find out if there was a way of uploading the TUHS
mailing list as a corpus of text into a LLM so that I could ask questions
based on the knowledge contained therein. I'm not having much luck yet.

Anyway, while messing around with things I asked a simple question and got
this answer:

What is a spin lock?

  A spin lock, also known as a spinning lock or spinning lock mechanism, is
  a type of mechanical locking device used to secure and protect sensitive
  electronic components, such as microprocessors, memory chips, and other
  high-value devices.

  Here's how it worked: when a CPU instruction was executed and the
  necessary data was stored in registers, the CPU would "lock" the registers
  by spinning them around to prevent other instructions from accessing them.

Those poor registers must get dizzy with all the spinning that they
have to endure :-)

Cheers, Warren

P.S. If anybody has ideas on how to usefully import the TUHS mailing list
into a LLM, let me/us know.

[COFF] Re: AI and spin locks

[David Barto]

That is some of the funniest stuff I’ve read in a long time

     David

Sent from iPhone Hotblack Desiato

> On Nov 27, 2024, at 4:41 PM, Warren Toomey via COFF <coff@tuhs.org> wrote:
> 
> I was just trying to find out if there was a way of uploading the TUHS
> mailing list as a corpus of text into a LLM so that I could ask questions
> based on the knowledge contained therein. I'm not having much luck yet.
> 
> Anyway, while messing around with things I asked a simple question and got
> this answer:
> 
> What is a spin lock?
> 
>  A spin lock, also known as a spinning lock or spinning lock mechanism, is
>  a type of mechanical locking device used to secure and protect sensitive
>  electronic components, such as microprocessors, memory chips, and other
>  high-value devices.
> 
>  Here's how it worked: when a CPU instruction was executed and the
>  necessary data was stored in registers, the CPU would "lock" the registers
>  by spinning them around to prevent other instructions from accessing them.
> 
> Those poor registers must get dizzy with all the spinning that they
> have to endure :-)
> 
> Cheers, Warren
> 
> P.S. If anybody has ideas on how to usefully import the TUHS mailing list
> into a LLM, let me/us know.

[COFF] Re: AI and spin locks

[Stuff Received]

On 2024-11-27 19:40, Warren Toomey via COFF wrote:
> I was just trying to find out if there was a way of uploading the TUHS
> mailing list as a corpus of text into a LLM so that I could ask questions
> based on the knowledge contained therein. I'm not having much luck yet.
> 
> Anyway, while messing around with things I asked a simple question and got
> this answer:
> 
> What is a spin lock?
> 
>    A spin lock, also known as a spinning lock or spinning lock mechanism, is
>    a type of mechanical locking device used to secure and protect sensitive
>    electronic components, such as microprocessors, memory chips, and other
>    high-value devices.
> 
>    Here's how it worked: when a CPU instruction was executed and the
>    necessary data was stored in registers, the CPU would "lock" the registers
>    by spinning them around to prevent other instructions from accessing them.
> 
> Those poor registers must get dizzy with all the spinning that they
> have to endure :-)

ld gravol

S.

> 
> Cheers, Warren
> 
> P.S. If anybody has ideas on how to usefully import the TUHS mailing list
> into a LLM, let me/us know.

[COFF] Re: AI and spin locks

[Edouard Klein]

So, I ran the following experiment:

I downloaded the last month of email from the archive, and split them
into one email per file using a quick and dirty state machine script in
python looking an empty line followed by two lines starting with "From"
in order to know where to split.

I then uploaded the files into https://openwebui.com/ built-in RAG
system.
The vectorization model is nvidia/NV-Embed-v2, and the LLM is
https://huggingface.co/bartowski/gemma-2-27b-it-GGUF/blob/main/gemma-2-27b-it-Q8_0.gguf

I then put the following very vague query, but which I knew was relevent
to last month's discussion:

What has changed in the C language in the last few decades ?

I copied the response at the end of the email. It seems quite good to
me, but it may get worse when the whole archive is uploaded.

I think this proof of concept shows that there could be value in doing
the whole list, with a cleaner email extraction a few tweaks to the
system prompt.

I can't do it now because I have a few deadlines coming soon (not the
least of which is the International Workshop on Plan 9
https://iwp9.org/ SEND YOUR PAPERS, PEOPLE !), but I would like to
tackle that in the near future.

Hosting this require significant but not overly expansive hardware (from
1 to few k€), if a university lab or a generous patron wants to see it
done and make it available to the public, please contact me :)

Otherwise llamafile (https://github.com/Mozilla-Ocho/llamafile  justine
single-handedly restored my faith in Mozilla) could be used to
distribute a file that would contain the model+the emails+the vector
database in a single huge file that can run anywhere.

Exciting times !


Here is the LLM answer:

Based on the provided context, it appears that the C language has
undergone significant changes over the last few decades. Here are some
key changes mentioned:

    Standardization and Formalization : The C language has become more
    formalized and standardized, with the introduction of new standards
    (e.g., C89, C99, C23). This has led to a more rigid and legalistic
    approach to the language, which some users find less useful.

    Changes to realloc function : The behavior of the realloc function
    has changed over time. In the first ANSI C standard, realloc(0, ptr)
    was well-defined when ptr was not nil. However, this behavior was
    changed in C99, and now, in C23, realloc(0, ptr) is undefined
    behavior (UB) regardless of the value of ptr.

    Strict Aliasing : The introduction of strict aliasing rules has led
    to compilers assuming that pointers to incompatible types always
    point to different non-overlapping locations. This has caused issues
    for some programmers.

    Additional Features and Functions : The C language has gained new
    features and functions over the years, such as stdint.h (introduced
    in C89), which provides integer types with specific widths.

    Evolution of Language Principles : The language has evolved with no
    appreciation or understanding of the aesthetic and practical
    principles of the original language effort, leading to a more
    verbose and less concise language.


These changes reflect the C language's growth and adaptation to new
requirements and use cases over the decades. However, some users, like
the ones in the provided context, feel that these changes have made the
language less useful and more complicated.

Warren Toomey via COFF <coff@tuhs.org> writes:

> I was just trying to find out if there was a way of uploading the TUHS
> mailing list as a corpus of text into a LLM so that I could ask questions
> based on the knowledge contained therein. I'm not having much luck yet.
>
> Anyway, while messing around with things I asked a simple question and got
> this answer:
>
> What is a spin lock?
>
>   A spin lock, also known as a spinning lock or spinning lock mechanism, is
>   a type of mechanical locking device used to secure and protect sensitive
>   electronic components, such as microprocessors, memory chips, and other
>   high-value devices.
>
>   Here's how it worked: when a CPU instruction was executed and the
>   necessary data was stored in registers, the CPU would "lock" the registers
>   by spinning them around to prevent other instructions from accessing them.
>
> Those poor registers must get dizzy with all the spinning that they
> have to endure :-)
>
> Cheers, Warren
>
> P.S. If anybody has ideas on how to usefully import the TUHS mailing list
> into a LLM, let me/us know.

[COFF] Re: AI and spin locks

[Warner Losh]

[-- Attachment #1: Type: text/plain, Size: 5010 bytes --]

On Thu, Nov 28, 2024, 11:11 AM Edouard Klein <edouardklein@gmail.com> wrote:

> So, I ran the following experiment:
>
> I downloaded the last month of email from the archive, and split them
> into one email per file using a quick and dirty state machine script in
> python looking an empty line followed by two lines starting with "From"
> in order to know where to split.
>
> I then uploaded the files into https://openwebui.com/ built-in RAG
> system.
> The vectorization model is nvidia/NV-Embed-v2, and the LLM is
>
> https://huggingface.co/bartowski/gemma-2-27b-it-GGUF/blob/main/gemma-2-27b-it-Q8_0.gguf
>
> I then put the following very vague query, but which I knew was relevent
> to last month's discussion:
>
> What has changed in the C language in the last few decades ?
>
> I copied the response at the end of the email. It seems quite good to
> me, but it may get worse when the whole archive is uploaded.
>
> I think this proof of concept shows that there could be value in doing
> the whole list, with a cleaner email extraction a few tweaks to the
> system prompt.
>
> I can't do it now because I have a few deadlines coming soon (not the
> least of which is the International Workshop on Plan 9
> https://iwp9.org/ SEND YOUR PAPERS, PEOPLE !), but I would like to
> tackle that in the near future.
>
> Hosting this require significant but not overly expansive hardware (from
> 1 to few k€), if a university lab or a generous patron wants to see it
> done and make it available to the public, please contact me :)
>
> Otherwise llamafile (https://github.com/Mozilla-Ocho/llamafile  justine
> single-handedly restored my faith in Mozilla) could be used to
> distribute a file that would contain the model+the emails+the vector
> database in a single huge file that can run anywhere.
>
> Exciting times !
>
>
> Here is the LLM answer:
>
> Based on the provided context, it appears that the C language has
> undergone significant changes over the last few decades. Here are some
> key changes mentioned:
>
>     Standardization and Formalization : The C language has become more
>     formalized and standardized, with the introduction of new standards
>     (e.g., C89, C99, C23). This has led to a more rigid and legalistic
>     approach to the language, which some users find less useful.
>
>     Changes to realloc function : The behavior of the realloc function
>     has changed over time. In the first ANSI C standard, realloc(0, ptr)
>     was well-defined when ptr was not nil. However, this behavior was
>     changed in C99, and now, in C23, realloc(0, ptr) is undefined
>     behavior (UB) regardless of the value of ptr.
>
>     Strict Aliasing : The introduction of strict aliasing rules has led
>     to compilers assuming that pointers to incompatible types always
>     point to different non-overlapping locations. This has caused issues
>     for some programmers.
>
>     Additional Features and Functions : The C language has gained new
>     features and functions over the years, such as stdint.h (introduced
>     in C89), which provides integer types with specific widths.
>
>     Evolution of Language Principles : The language has evolved with no
>     appreciation or understanding of the aesthetic and practical
>     principles of the original language effort, leading to a more
>     verbose and less concise language.
>
>
> These changes reflect the C language's growth and adaptation to new
> requirements and use cases over the decades. However, some users, like
> the ones in the provided context, feel that these changes have made the
> language less useful and more complicated.
>

Now you kids get off my damn lawn!

But it is a fairly accurate summary.

Warner

Warner

Warren Toomey via COFF <coff@tuhs.org> writes:
>
> > I was just trying to find out if there was a way of uploading the TUHS
> > mailing list as a corpus of text into a LLM so that I could ask questions
> > based on the knowledge contained therein. I'm not having much luck yet.
> >
> > Anyway, while messing around with things I asked a simple question and
> got
> > this answer:
> >
> > What is a spin lock?
> >
> >   A spin lock, also known as a spinning lock or spinning lock mechanism,
> is
> >   a type of mechanical locking device used to secure and protect
> sensitive
> >   electronic components, such as microprocessors, memory chips, and other
> >   high-value devices.
> >
> >   Here's how it worked: when a CPU instruction was executed and the
> >   necessary data was stored in registers, the CPU would "lock" the
> registers
> >   by spinning them around to prevent other instructions from accessing
> them.
> >
> > Those poor registers must get dizzy with all the spinning that they
> > have to endure :-)
> >
> > Cheers, Warren
> >
> > P.S. If anybody has ideas on how to usefully import the TUHS mailing list
> > into a LLM, let me/us know.
>

[-- Attachment #2: Type: text/html, Size: 6513 bytes --]

[COFF] Re: AI and spin locks

[Clem Cole]

[-- Attachment #1: Type: text/plain, Size: 5299 bytes --]

Amen

Sent from a handheld expect more typos than usual


On Thu, Nov 28, 2024 at 1:17 PM Warner Losh <imp@bsdimp.com> wrote:

>
>
> On Thu, Nov 28, 2024, 11:11 AM Edouard Klein <edouardklein@gmail.com>
> wrote:
>
>> So, I ran the following experiment:
>>
>> I downloaded the last month of email from the archive, and split them
>> into one email per file using a quick and dirty state machine script in
>> python looking an empty line followed by two lines starting with "From"
>> in order to know where to split.
>>
>> I then uploaded the files into https://openwebui.com/ built-in RAG
>> system.
>> The vectorization model is nvidia/NV-Embed-v2, and the LLM is
>>
>> https://huggingface.co/bartowski/gemma-2-27b-it-GGUF/blob/main/gemma-2-27b-it-Q8_0.gguf
>>
>> I then put the following very vague query, but which I knew was relevent
>> to last month's discussion:
>>
>> What has changed in the C language in the last few decades ?
>>
>> I copied the response at the end of the email. It seems quite good to
>> me, but it may get worse when the whole archive is uploaded.
>>
>> I think this proof of concept shows that there could be value in doing
>> the whole list, with a cleaner email extraction a few tweaks to the
>> system prompt.
>>
>> I can't do it now because I have a few deadlines coming soon (not the
>> least of which is the International Workshop on Plan 9
>> https://iwp9.org/ SEND YOUR PAPERS, PEOPLE !), but I would like to
>> tackle that in the near future.
>>
>> Hosting this require significant but not overly expansive hardware (from
>> 1 to few k€), if a university lab or a generous patron wants to see it
>> done and make it available to the public, please contact me :)
>>
>> Otherwise llamafile (https://github.com/Mozilla-Ocho/llamafile  justine
>> single-handedly restored my faith in Mozilla) could be used to
>> distribute a file that would contain the model+the emails+the vector
>> database in a single huge file that can run anywhere.
>>
>> Exciting times !
>>
>>
>> Here is the LLM answer:
>>
>> Based on the provided context, it appears that the C language has
>> undergone significant changes over the last few decades. Here are some
>> key changes mentioned:
>>
>>     Standardization and Formalization : The C language has become more
>>     formalized and standardized, with the introduction of new standards
>>     (e.g., C89, C99, C23). This has led to a more rigid and legalistic
>>     approach to the language, which some users find less useful.
>>
>>     Changes to realloc function : The behavior of the realloc function
>>     has changed over time. In the first ANSI C standard, realloc(0, ptr)
>>     was well-defined when ptr was not nil. However, this behavior was
>>     changed in C99, and now, in C23, realloc(0, ptr) is undefined
>>     behavior (UB) regardless of the value of ptr.
>>
>>     Strict Aliasing : The introduction of strict aliasing rules has led
>>     to compilers assuming that pointers to incompatible types always
>>     point to different non-overlapping locations. This has caused issues
>>     for some programmers.
>>
>>     Additional Features and Functions : The C language has gained new
>>     features and functions over the years, such as stdint.h (introduced
>>     in C89), which provides integer types with specific widths.
>>
>>     Evolution of Language Principles : The language has evolved with no
>>     appreciation or understanding of the aesthetic and practical
>>     principles of the original language effort, leading to a more
>>     verbose and less concise language.
>>
>>
>> These changes reflect the C language's growth and adaptation to new
>> requirements and use cases over the decades. However, some users, like
>> the ones in the provided context, feel that these changes have made the
>> language less useful and more complicated.
>>
>
> Now you kids get off my damn lawn!
>
> But it is a fairly accurate summary.
>
> Warner
>
> Warner
>
> Warren Toomey via COFF <coff@tuhs.org> writes:
>>
>> > I was just trying to find out if there was a way of uploading the TUHS
>> > mailing list as a corpus of text into a LLM so that I could ask
>> questions
>> > based on the knowledge contained therein. I'm not having much luck yet.
>> >
>> > Anyway, while messing around with things I asked a simple question and
>> got
>> > this answer:
>> >
>> > What is a spin lock?
>> >
>> >   A spin lock, also known as a spinning lock or spinning lock
>> mechanism, is
>> >   a type of mechanical locking device used to secure and protect
>> sensitive
>> >   electronic components, such as microprocessors, memory chips, and
>> other
>> >   high-value devices.
>> >
>> >   Here's how it worked: when a CPU instruction was executed and the
>> >   necessary data was stored in registers, the CPU would "lock" the
>> registers
>> >   by spinning them around to prevent other instructions from accessing
>> them.
>> >
>> > Those poor registers must get dizzy with all the spinning that they
>> > have to endure :-)
>> >
>> > Cheers, Warren
>> >
>> > P.S. If anybody has ideas on how to usefully import the TUHS mailing
>> list
>> > into a LLM, let me/us know.
>>
>

[-- Attachment #2: Type: text/html, Size: 7124 bytes --]

[COFF] Re: AI and spin locks

[David Arnold]

> On 29 Nov 2024, at 05:11, Edouard Klein <edouardklein@gmail.com> wrote:

<…>

> Additional Features and Functions : The C language has gained new features and functions over the years, such as stdint.h (introduced in C89), which provides integer types with specific widths.

Wasn’t stdint.h a C99 thing?



d

[COFF] Re: AI and spin locks

[Warner Losh]

[-- Attachment #1: Type: text/plain, Size: 511 bytes --]

On Thu, Nov 28, 2024, 12:26 PM David Arnold <davida@pobox.com> wrote:

>
> > On 29 Nov 2024, at 05:11, Edouard Klein <edouardklein@gmail.com> wrote:
>
> <…>
>
> > Additional Features and Functions : The C language has gained new
> features and functions over the years, such as stdint.h (introduced in
> C89), which provides integer types with specific widths.
>
> Wasn’t stdint.h a C99 thing?
>

Yes. It's why FreeBSD has lots of u_int16_t instances in its tree still.

Warner


>
>

[-- Attachment #2: Type: text/html, Size: 1178 bytes --]

[COFF] Re: Sending TUHS to an LLM

[Warren Toomey via COFF]

On Thu, Nov 28, 2024 at 10:40:59AM +1000, Warren Toomey via COFF wrote:
> I was just trying to find out if there was a way of uploading the TUHS
> mailing list as a corpus of text into a LLM so that I could ask questions
> based on the knowledge contained therein. I'm not having much luck yet.

Steve Jenkin pointed me at Google's NotebookLM. I took the first 1M (of 137M)
of the TUHS mailing list mbox, filtered out most of the headers and fed it in.

It seems to do a good job of summarising the contents and responding to
questions. Here's a link:

https://notebooklm.google.com/notebook/eca37b7c-dfbd-4346-bdaa-2cc038087fb9?_gl=1*dqtpyz*_ga*NTgzOTM5MzU2LjE3MzMxMDY0NzU.*_ga_W0LDH41ZCB*MTczMzEwNjQ3NC4xLjEuMTczMzEwNjQ5OS4zNS4wLjA.&original_referer=https:%2F%2Fnotebooklm.google%23&pli=1

What's weirder is you can generate a 30-minute dialogue where two AI entities
talk about the content. There's a lot of verbal diarrhoea, but here is the
link if you feel like listening to it :-)

https://notebooklm.google.com/notebook/eca37b7c-dfbd-4346-bdaa-2cc038087fb9/audio

Cheers, Warren

[COFF] Re: Sending TUHS to an LLM

[Warner Losh]

[-- Attachment #1: Type: text/plain, Size: 1318 bytes --]

On Sun, Dec 1, 2024, 8:05 PM Warren Toomey via COFF <coff@tuhs.org> wrote:

> On Thu, Nov 28, 2024 at 10:40:59AM +1000, Warren Toomey via COFF wrote:
> > I was just trying to find out if there was a way of uploading the TUHS
> > mailing list as a corpus of text into a LLM so that I could ask questions
> > based on the knowledge contained therein. I'm not having much luck yet.
>
> Steve Jenkin pointed me at Google's NotebookLM. I took the first 1M (of
> 137M)
> of the TUHS mailing list mbox, filtered out most of the headers and fed it
> in.
>
> It seems to do a good job of summarising the contents and responding to
> questions. Here's a link:
>
>
> https://notebooklm.google.com/notebook/eca37b7c-dfbd-4346-bdaa-2cc038087fb9?_gl=1*dqtpyz*_ga*NTgzOTM5MzU2LjE3MzMxMDY0NzU.*_ga_W0LDH41ZCB*MTczMzEwNjQ3NC4xLjEuMTczMzEwNjQ5OS4zNS4wLjA.&original_referer=https:%2F%2Fnotebooklm.google%23&pli=1
>
> What's weirder is you can generate a 30-minute dialogue where two AI
> entities
> talk about the content. There's a lot of verbal diarrhoea, but here is the
> link if you feel like listening to it :-)
>
>
> https://notebooklm.google.com/notebook/eca37b7c-dfbd-4346-bdaa-2cc038087fb9/audio


Better or worse than the analyze-pinhead output in gnuemacs?

Warner


>
> Cheers, Warren
>

[-- Attachment #2: Type: text/html, Size: 2373 bytes --]

[COFF] Re: Sending TUHS to an LLM

[Dave Horsfall]

On Mon, 2 Dec 2024, Warren Toomey via COFF wrote:

> What's weirder is you can generate a 30-minute dialogue where two AI 
> entities talk about the content. There's a lot of verbal diarrhoea, but 
> here is the link if you feel like listening to it :-)

Where's ELIZA when we need her? :-)

-- Dave

[COFF] Re: Sending TUHS to an LLM

[Gergely Buday]

[-- Attachment #1: Type: text/plain, Size: 1360 bytes --]

The first link asks me to add sources first. I guess I don't have rights to
use your sources.

- Gergely

Warren Toomey via COFF <coff@tuhs.org> ezt írta (időpont: 2024. dec. 2.,
Hét 3:23):

> On Thu, Nov 28, 2024 at 10:40:59AM +1000, Warren Toomey via COFF wrote:
> > I was just trying to find out if there was a way of uploading the TUHS
> > mailing list as a corpus of text into a LLM so that I could ask questions
> > based on the knowledge contained therein. I'm not having much luck yet.
>
> Steve Jenkin pointed me at Google's NotebookLM. I took the first 1M (of
> 137M)
> of the TUHS mailing list mbox, filtered out most of the headers and fed it
> in.
>
> It seems to do a good job of summarising the contents and responding to
> questions. Here's a link:
>
>
> https://notebooklm.google.com/notebook/eca37b7c-dfbd-4346-bdaa-2cc038087fb9?_gl=1*dqtpyz*_ga*NTgzOTM5MzU2LjE3MzMxMDY0NzU.*_ga_W0LDH41ZCB*MTczMzEwNjQ3NC4xLjEuMTczMzEwNjQ5OS4zNS4wLjA.&original_referer=https:%2F%2Fnotebooklm.google%23&pli=1
>
> What's weirder is you can generate a 30-minute dialogue where two AI
> entities
> talk about the content. There's a lot of verbal diarrhoea, but here is the
> link if you feel like listening to it :-)
>
>
> https://notebooklm.google.com/notebook/eca37b7c-dfbd-4346-bdaa-2cc038087fb9/audio
>
> Cheers, Warren
>

[-- Attachment #2: Type: text/html, Size: 2192 bytes --]