Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

Disobedience: The silver lining to the cloud of servitude. -- Ambrose Bierce


computers / comp.os.linux.misc / Re: GPU

SubjectAuthor
* GPUDieter Britz
+- Re: GPURich
`* Re: GPUEli the Bearded
 `* Re: GPURichard Kettlewell
  `* Re: GPUEli the Bearded
   `- Re: GPURich

1
GPU

<s855bp$8fm$1@dont-email.me>

 copy mid

https://www.novabbs.com/computers/article-flat.php?id=5092&group=comp.os.linux.misc#5092

 copy link   Newsgroups: comp.os.linux.misc
Path: i2pn2.org!i2pn.org!aioe.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: dieterha...@gmail.com (Dieter Britz)
Newsgroups: comp.os.linux.misc
Subject: GPU
Date: Thu, 20 May 2021 08:07:21 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 8
Message-ID: <s855bp$8fm$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 20 May 2021 08:07:21 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="3b93f2ec945eb557a56d2aac08dd406d";
logging-data="8694"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+kLnSPKsn8aqk5hZK7kh7pEyRcuX6G9Ks="
User-Agent: Pan/0.144 (Time is the enemy; 28ab3ba git.gnome.org/pan2)
Cancel-Lock: sha1:CUgE+/38oCofXeSpaarMMPHqAbo=
 by: Dieter Britz - Thu, 20 May 2021 08:07 UTC

I have some long running jobs and maybe they can be speeded
up if I run them on the GPU. Or maybe not. They don't lend
themselves to parallel processing, so my question is, is the GPU
faster than the CPU for sequential programs? This would be good
to know before I start learning how to send jobs to the GPU.

--
Dieter Britz

Re: GPU

<s85m93$66j$1@dont-email.me>

 copy mid

https://www.novabbs.com/computers/article-flat.php?id=5093&group=comp.os.linux.misc#5093

 copy link   Newsgroups: comp.os.linux.misc
Path: i2pn2.org!i2pn.org!aioe.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ric...@example.invalid (Rich)
Newsgroups: comp.os.linux.misc
Subject: Re: GPU
Date: Thu, 20 May 2021 12:56:04 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 13
Message-ID: <s85m93$66j$1@dont-email.me>
References: <s855bp$8fm$1@dont-email.me>
Injection-Date: Thu, 20 May 2021 12:56:04 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="6474c7d420e72bbb74962c02c06d0b2c";
logging-data="6355"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/Tq024r3BlAiefyEYnp/uu"
User-Agent: tin/2.0.1-20111224 ("Achenvoir") (UNIX) (Linux/3.10.17 (x86_64))
Cancel-Lock: sha1:IEPsIWZvf/p8lC7IlWvcSjCsQ3k=
 by: Rich - Thu, 20 May 2021 12:56 UTC

Dieter Britz <dieterhansbritz@gmail.com> wrote:
> I have some long running jobs and maybe they can be speeded
> up if I run them on the GPU. Or maybe not. They don't lend
> themselves to parallel processing, so my question is, is the GPU
> faster than the CPU for sequential programs?

Typically, no. The GPU is a massively parallel processor, and if the
task can't be subdivided in some way to allow parallel operation,
trying to run it on a GPU is not likely to be worthwhile (vs running it
on a recently modern CPU).

Now, if you /can/ divide it some way to allow parallel operation, then
running it on a GPU might be worthwhile.

Re: GPU

<eli$2105201428@qaz.wtf>

 copy mid

https://www.novabbs.com/computers/article-flat.php?id=5096&group=comp.os.linux.misc#5096

 copy link   Newsgroups: comp.os.linux.misc
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!panix!qz!not-for-mail
From: *...@eli.users.panix.com (Eli the Bearded)
Newsgroups: comp.os.linux.misc
Subject: Re: GPU
Date: Thu, 20 May 2021 18:28:29 +0000 (UTC)
Organization: Some absurd concept
Lines: 34
Message-ID: <eli$2105201428@qaz.wtf>
References: <s855bp$8fm$1@dont-email.me>
NNTP-Posting-Host: panix5.panix.com
X-Trace: reader1.panix.com 1621535309 28507 166.84.1.5 (20 May 2021 18:28:29 GMT)
X-Complaints-To: abuse@panix.com
NNTP-Posting-Date: Thu, 20 May 2021 18:28:29 +0000 (UTC)
X-Liz: It's actually happened, the entire Internet is a massive game of Redcode
X-Motto: "Erosion of rights never seems to reverse itself." -- kenny@panix
X-US-Congress: Moronic Fucks.
X-Attribution: EtB
XFrom: is a real address
Encrypted: double rot-13
User-Agent: Vectrex rn 2.1 (beta)
 by: Eli the Bearded - Thu, 20 May 2021 18:28 UTC

In comp.os.linux.misc, Dieter Britz <dieterhansbritz@gmail.com> wrote:
> I have some long running jobs and maybe they can be speeded
> up if I run them on the GPU. Or maybe not. They don't lend
> themselves to parallel processing, so my question is, is the GPU
> faster than the CPU for sequential programs? This would be good
> to know before I start learning how to send jobs to the GPU.

GPUs are optimized for the sorts of math useful in graphics. One thing
you may notice about a screen is there are a lot of small numbers (0 to
255 per color channel per per pixel) that all need updating at about
the same time. The math behind those updates generally comes from
floating point multiplications. GPUs are best at taking a large set
of 4x4 matrices and multiplying eatch by another 4x4 matrix, an
operation that can be used to cover just about all typical screen
graphics tasks (sometimes a chunk of the numbers will be 0 when smaller
operations are needed). Each part of the screen can be independently
calculated -- pixel values calculations are not used as input to
adjacent pixels -- so to make a GPU be fast it is designed to do a
lot of those matrix operations in parallel.

If your problem can be solved with matrix multiplication then offload to
a GPU is a likely to be a win (maybe video transcoding or modeling
weather). If your problem involves a lot of branching, copying,
responding to changing requests, or other non-multiplication work (say
compressing a large amount of text files) the GPU is not going to be
useful.

I'm not sure what you think are "sequential" programs, but that sounds
like a process that will use previous state to determine next state,
which is not a good fit for a GPU.

Elijah
------
separately the history of graphics processing in computers is interesting

Re: GPU

<871ra1xld7.fsf@LkoBDZeT.terraraq.uk>

 copy mid

https://www.novabbs.com/computers/article-flat.php?id=5097&group=comp.os.linux.misc#5097

 copy link   Newsgroups: comp.os.linux.misc
Path: i2pn2.org!i2pn.org!aioe.org!nntp.terraraq.uk!.POSTED.nntp.terraraq.uk!not-for-mail
From: inva...@invalid.invalid (Richard Kettlewell)
Newsgroups: comp.os.linux.misc
Subject: Re: GPU
Date: Thu, 20 May 2021 20:20:52 +0100
Organization: terraraq NNTP server
Message-ID: <871ra1xld7.fsf@LkoBDZeT.terraraq.uk>
References: <s855bp$8fm$1@dont-email.me> <eli$2105201428@qaz.wtf>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Info: mantic.terraraq.uk; posting-host="nntp.terraraq.uk:2a00:1098:0:86:1000:3f:0:2";
logging-data="16568"; mail-complaints-to="usenet@mantic.terraraq.uk"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
Cancel-Lock: sha1:frIatdzvo3aYNWcvfnAGcW2s1Ok=
X-Face: h[Hh-7npe<<b4/eW[]sat,I3O`t8A`(ej.H!F4\8|;ih)`7{@:A~/j1}gTt4e7-n*F?.Rl^
F<\{jehn7.KrO{!7=:(@J~]<.[{>v9!1<qZY,{EJxg6?Er4Y7Ng2\Ft>Z&W?r\c.!4DXH5PWpga"ha
+r0NzP?vnz:e/knOY)PI-
X-Boydie: NO
 by: Richard Kettlewell - Thu, 20 May 2021 19:20 UTC

Eli the Bearded <*@eli.users.panix.com> writes:
> GPUs are optimized for the sorts of math useful in graphics. One thing
> you may notice about a screen is there are a lot of small numbers (0 to
> 255 per color channel per per pixel) that all need updating at about
> the same time. The math behind those updates generally comes from
> floating point multiplications. GPUs are best at taking a large set
> of 4x4 matrices and multiplying eatch by another 4x4 matrix, an
> operation that can be used to cover just about all typical screen
> graphics tasks (sometimes a chunk of the numbers will be 0 when smaller
> operations are needed). Each part of the screen can be independently
> calculated -- pixel values calculations are not used as input to
> adjacent pixels -- so to make a GPU be fast it is designed to do a
> lot of those matrix operations in parallel.
>
> If your problem can be solved with matrix multiplication then offload to
> a GPU is a likely to be a win (maybe video transcoding or modeling
> weather). If your problem involves a lot of branching, copying,
> responding to changing requests, or other non-multiplication work (say
> compressing a large amount of text files) the GPU is not going to be
> useful.

They’re the standard tool for password cracking[1], which depends on
integer/bitwise operations. They’ve evidently moved beyond just being a
good way to do a lot of multiplications quickly, though AFAICT remain
optimized for executing essentially the same code on huge volumes of
data.

[1] which is why modern password encryption algorithms deliberately use
a great deal of memory.

--
https://www.greenend.org.uk/rjk/

Re: GPU

<eli$2105201541@qaz.wtf>

 copy mid

https://www.novabbs.com/computers/article-flat.php?id=5098&group=comp.os.linux.misc#5098

 copy link   Newsgroups: comp.os.linux.misc
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!panix!qz!not-for-mail
From: *...@eli.users.panix.com (Eli the Bearded)
Newsgroups: comp.os.linux.misc
Subject: Re: GPU
Date: Thu, 20 May 2021 19:41:55 +0000 (UTC)
Organization: Some absurd concept
Lines: 22
Message-ID: <eli$2105201541@qaz.wtf>
References: <s855bp$8fm$1@dont-email.me> <eli$2105201428@qaz.wtf> <871ra1xld7.fsf@LkoBDZeT.terraraq.uk>
NNTP-Posting-Host: panix5.panix.com
X-Trace: reader1.panix.com 1621539715 7449 166.84.1.5 (20 May 2021 19:41:55 GMT)
X-Complaints-To: abuse@panix.com
NNTP-Posting-Date: Thu, 20 May 2021 19:41:55 +0000 (UTC)
X-Liz: It's actually happened, the entire Internet is a massive game of Redcode
X-Motto: "Erosion of rights never seems to reverse itself." -- kenny@panix
X-US-Congress: Moronic Fucks.
X-Attribution: EtB
XFrom: is a real address
Encrypted: double rot-13
User-Agent: Vectrex rn 2.1 (beta)
 by: Eli the Bearded - Thu, 20 May 2021 19:41 UTC

In comp.os.linux.misc, Richard Kettlewell <invalid@invalid.invalid> wrote:
> They're the standard tool for password cracking[1], which depends on
> integer/bitwise operations. They've evidently moved beyond just being a
> good way to do a lot of multiplications quickly, though AFAICT remain
> optimized for executing essentially the same code on huge volumes of
> data.

That is a good point, though it still remains that it is a a process
where each operation does not depend on the output of the previous
operation. Likely it's the same sort of work breakdown as in old-school
shift (scroll) and blit graphics work, whereas I was focused on modern
3D and overlay type jobs.

> [1] which is why modern password encryption algorithms deliberately use
> a great deal of memory.

I suspect that there are multiple competing factors there, including
saving intermidate states to avoid recalculation.

Elijah
------
rainbow tables being the most extreme "avoid recalculation" case

Re: GPU

<s86ibv$kjr$3@dont-email.me>

 copy mid

https://www.novabbs.com/computers/article-flat.php?id=5099&group=comp.os.linux.misc#5099

 copy link   Newsgroups: comp.os.linux.misc
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ric...@example.invalid (Rich)
Newsgroups: comp.os.linux.misc
Subject: Re: GPU
Date: Thu, 20 May 2021 20:55:27 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 51
Message-ID: <s86ibv$kjr$3@dont-email.me>
References: <s855bp$8fm$1@dont-email.me> <eli$2105201428@qaz.wtf> <871ra1xld7.fsf@LkoBDZeT.terraraq.uk> <eli$2105201541@qaz.wtf>
Injection-Date: Thu, 20 May 2021 20:55:27 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="6474c7d420e72bbb74962c02c06d0b2c";
logging-data="21115"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19WJ2hHaGniX/00EbsMatFc"
User-Agent: tin/2.0.1-20111224 ("Achenvoir") (UNIX) (Linux/3.10.17 (x86_64))
Cancel-Lock: sha1:z0iMj8lc3Y4K4JZ09tznCNmDXgA=
 by: Rich - Thu, 20 May 2021 20:55 UTC

Eli the Bearded <*@eli.users.panix.com> wrote:
> In comp.os.linux.misc, Richard Kettlewell <invalid@invalid.invalid> wrote:
>> They're the standard tool for password cracking[1], which depends on
>> integer/bitwise operations. They've evidently moved beyond just being a
>> good way to do a lot of multiplications quickly, though AFAICT remain
>> optimized for executing essentially the same code on huge volumes of
>> data.
>
> That is a good point, though it still remains that it is a a process
> where each operation does not depend on the output of the previous
> operation. Likely it's the same sort of work breakdown as in old-school
> shift (scroll) and blit graphics work, whereas I was focused on modern
> 3D and overlay type jobs.
>
>> [1] which is why modern password encryption algorithms deliberately use
>> a great deal of memory.
>
> I suspect that there are multiple competing factors there, including
> saving intermidate states to avoid recalculation.

For at least one of the algorithms, the "large memory" requirement was
deliberately added specifically to thwart custom hardware ASIC's:

https://en.wikipedia.org/wiki/Scrypt

"The algorithm was specifically designed to make it costly to
perform large-scale custom hardware attacks by requiring large
amounts of memory."

...

"Previous password-based KDFs (such as the popular PBKDF2 from RSA
Laboratories) have relatively low resource demands, meaning they do
not require elaborate hardware or very much memory to perform.
They are therefore easily and cheaply implemented in hardware (for
instance on an ASIC or even an FPGA). This allows an attacker with
sufficient resources to launch a large-scale parallel attack by
building hundreds or even thousands of implementations of the
algorithm in hardware and having each search a different subset of
the key space. This divides the amount of time needed to complete
a brute-force attack by the number of implementations available,
very possibly bringing it down to a reasonable time frame.

The scrypt function is designed to hinder such attempts by raising
the resource demands of the algorithm. Specifically, the algorithm
is designed to use a large amount of memory compared to other
password-based KDFs,[4] making the size and the cost of a hardware
implementation much more expensive, and therefore limiting the
amount of parallelism an attacker can use, for a given amount of
financial resources."

1
server_pubkey.txt

rocksolid light 0.9.7
clearnet tor