sleep(0.1) can reduce efficiency in stream way, replace with semaphore #1252
Conversation
|
semaphore是并发控制，sleep是为了让线程释放gil锁，这两个应该不是一个目的 |
|
semaphore也能释放gil锁吧？等待semaphore的线程应该不是spinlock自旋锁，理论上应该会释放gil锁
…---Original---
From: "Xiang ***@***.***>
Date: Sun, May 4, 2025 16:28 PM
To: ***@***.***>;
Cc: ***@***.******@***.***>;
Subject: Re: [FunAudioLLM/CosyVoice] sleep(0.1) can reduce efficiency instream way, replace with semaphore (PR #1252)
aluminumbox left a comment (FunAudioLLM/CosyVoice#1252)
semaphore是并发控制，sleep是为了让线程释放gil锁，这两个应该不是一个目的
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
这个代码我不知道你有没有试过，sleep目的是while true里让他不要一直判断，否则会占满线程，因为llm解码是异步的，所以间隔0.1s去判断一次有没有足够多的token。我看你这个while true里是一个sempare.acquire，跟我理解的这个sleep作用似乎是不太一样的 |
|
试了，可以的。sempare.acquire就是休眠，释放gil锁，让llm继续运行，同时等待llm来信号再继续，不用循环去检测。循环检测首先是会占用额外cpu，其次会有一定延时
…---Original---
From: "Xiang ***@***.***>
Date: Sun, May 4, 2025 17:04 PM
To: ***@***.***>;
Cc: ***@***.******@***.***>;
Subject: Re: [FunAudioLLM/CosyVoice] sleep(0.1) can reduce efficiency instream way, replace with semaphore (PR #1252)
aluminumbox left a comment (FunAudioLLM/CosyVoice#1252)
semaphore也能释放gil锁吧？等待semaphore的线程应该不是spinlock自旋锁，理论上应该会释放gil锁
…
---Original--- From: "Xiang @.> Date: Sun, May 4, 2025 16:28 PM To: @.>; Cc: @.@.>; Subject: Re: [FunAudioLLM/CosyVoice] sleep(0.1) can reduce efficiency instream way, replace with semaphore (PR #1252) aluminumbox left a comment (FunAudioLLM/CosyVoice#1252) semaphore是并发控制，sleep是为了让线程释放gil锁，这两个应该不是一个目的 — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>
这个代码我不知道你有没有试过，sleep目的是while true里让他不要一直判断，否则会占满线程，因为llm解码是异步的，所以间隔0.1s去判断一次有没有足够多的token。我看你这个while true里是一个sempare.acquire，跟我理解的这个sleep作用似乎是不太一样的
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
|
比如有2个线程，semaphore是1，那么按我以前使用semaphore的经验，如果semapohre控制并发为1。那么比如线程1 acquire后，那么它就会一直执行，直到release。我们这里希望的是，线程1/2通过sleep轮流释放gil。我理解semaphore是控制并发用的 |
semaphore既解决同步，也解决并发（其实没有并发，gil是伪并发）。所以llm和tts两个线程主要是靠同步。当tts进入semaphore.acquire时，如果llm没准备好，tts就会休眠让出cpu给llm运行。如果llm准备好了，会唤醒tts进行一次解码，解码后while循环又会进入acquire休眠，让出cpu给llm。如此同步，是效率最高的。sleep虽然也可以让出cpu，但很多时候是无效的，增加了无效线程切换的开销。 |
|
我看你这个是用了semapohore(0)，所以这里只有acquire，没有release。我不太熟悉这种用法，有空我会研究一下，我担心的是线程a在acquire后进行解码的时候，线程b无法进入解码，而且当a在解码进行到一半，比如token2wav执行到中间的时候，现成b也应该可以获得gil |
嗯，可以一块研究下。semaphore(0)是因为tts需要等待llm。感觉即使是sleep也没法做到tts在while中间时(比如token2wav)让出gil，只有执行到sleep这个点才会让出gil |
sleep是可以让出来的，因为没有加锁，sleep只是为了让while True里的判断不要一直执行 |
semaphore也会让出gil，和sleep一样的。这是个典型生产者消费者同步问题，llm是生产者，tts是消费者，所以用PV信号量。release是在llm生产出token时，唤醒tts |
When performing stream inference, using sleep(0.1) can reduce efficiency, introducing an average delay of 0.05 seconds per chunk. Switching to a semaphore can resolve this average delay issue.