chore: bump icicle to v2.8.0 by mrain · Pull Request #595 · EspressoSystems/jellyfish

mrain · 2024-05-29T21:10:43Z

no issue related.

This PR:

bump icicle deps to v2.8.0
- HostOrDeviceSlice is now a trait. Occurrences are changed to concrete types now.
- For Bn254 curve impl
  - commit_on_gpu now assume that the input scalars are in normal form instead of montgomery form.
  - now load_poly_to_gpu has one memory copy instead of free as before
  - these are because, icicle field impl now uses u32 limbs instead of u64 limbs as in arkworks.
add GPU stress test for memory leakage/fragmentation

This PR does not:

Key places to review:

Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

Targeted PR against correct branch (main)
Linked to GitHub issue with discussion and accepted design OR have an explanation in the PR that describes this work.
Wrote unit tests
Updated relevant documentation in the code
Added relevant changelog entries to the CHANGELOG.md of touched crates.
Re-reviewed Files changed in the GitHub PR explorer

…cicle

alxiong · 2024-07-03T02:46:34Z

thanks @mrain for taking the initiative to upgrade our icicle dep! 👍

…cicle

mrain · 2024-08-15T15:41:08Z

 ark-ed-on-bn254 = "0.4.0"
 criterion = "0.5.1"
-jf-pcs = { git = "https://github.com/EspressoSystems/jellyfish", tag = "0.4.5", features = ["test-srs"] }
+jf-pcs = { path = "../pcs", features = ["test-srs"] }


Use path b/c some updates are not reflected in the github yet.

Do you intend to switch back before merge?

i don't think he can. One of the perils of separate versioning is multi-step upgrade here.
changing back need another PR: a new tag will be added once this PR is merged, then next one would switch back.

ggutoski

A couple of nits. I'd like another pair of eyes before approval.

ggutoski · 2024-08-15T15:54:59Z

            icicle_bn254::curve::G1Affine {
-                x: icicle_bn254::curve::BaseField::from(p.x.0 .0),
-                y: icicle_bn254::curve::BaseField::from(p.y.0 .0),
+                x: unsafe { ark_std::mem::transmute(p.x.into_bigint()) },


Nit: refactor this recurring line of unsafe code into a separate function.

and did we add test for this unsafe transmute anywhere?

also can you add comment that even though arkworks uses u64 limb (as opposed to u32 in icicle), they are both little-endian encoded, thus agree on a byte-level, which is why this unsafe transmute is correct.

^^ am I right?

Yes, the test is here: https://github.com/EspressoSystems/jellyfish/pull/595/files#diff-1b7c209306eb56d628e64ac6bc03978824af57767468dc3c618243860d04a6e3L1415

But it's only testing the ScalarField conversion. Maybe it's okay to assume that BaseField conversion should pass if this passes.

ggutoski · 2024-08-15T16:05:53Z

        /// - default implementation assume normal(non-montgomery) affine for
        ///   bases and scalars, consider overwrite this function if you want
        ///   otherwise


From the PR description:

commit_on_gpu now assume that the input scalars are in normal form instead of montgomery form.

Why switch from montgomery to normal?

I'm surprised you don't need to update this comment. This comment suggests it was always the case that scalars are in normal form. So was it wrong before and is now correct??

No this is always correct. The generic implementation assumes that the scalars are normal. Only for Bn254 we take montgomery scalars. Now they have to be normal in all cases.

alxiong · 2024-08-19T03:01:50Z

    pub fn warmup_new_stream() -> anyhow::Result<CudaStream> {
        let stream = CudaStream::create().map_err(|e| anyhow!("{:?}", e))?;
-        let _warmup_bytes = HostOrDeviceSlice::<'_, u8>::cuda_malloc_async(1024, &stream)
-            .map_err(|e| anyhow!("{:?}", e))?;
+        let _warmup_bytes =
+            DeviceVec::<u8>::cuda_malloc_async(1024, &stream).map_err(|e| anyhow!("{:?}", e))?;


i think we can forgo this function in favor of out-of-box: https://github.com/ingonyama-zk/icicle/blob/621676bd41659bc101f29dc7ac54f29c7cdaa92b/wrappers/rust/icicle-cuda-runtime/src/device.rs#L44

this is probably the last unaddressed comment? @mrain

They are already at v4.0.0 and there're many breaking changes. Probably we could directly jump there by spending some more time if necessary.

alxiong · 2024-08-19T03:03:47Z

 ark-ed-on-bn254 = "0.4.0"
 criterion = "0.5.1"
-jf-pcs = { git = "https://github.com/EspressoSystems/jellyfish", tag = "0.4.5", features = ["test-srs"] }
+jf-pcs = { path = "../pcs", features = ["test-srs"] }


i don't think he can. One of the perils of separate versioning is multi-step upgrade here.
changing back need another PR: a new tag will be added once this PR is merged, then next one would switch back.

alxiong · 2024-08-19T03:05:39Z

+/// Stress test with varied payload sizes for GPU memory
+/// leakage/fragmentation.


how does this test leakage or fragmentation?

iiuc, this only put lots of running instances, and in case we didn't clean up (after use) the memory, it would overflow the memory?

but how does it test fragmentation?

Suggested by Salman. It really depends on the GPU memory management. Hypothesis is that if you make many GPU memory allocations and they are not cleaned up fast enough, then there're potentially fragmentations that prevent you from allocating even if the GPU memory is not full.

plz put this explanation in a comment 🙏

alxiong · 2024-08-19T03:28:45Z

            icicle_bn254::curve::G1Affine {
-                x: icicle_bn254::curve::BaseField::from(p.x.0 .0),
-                y: icicle_bn254::curve::BaseField::from(p.y.0 .0),
+                x: unsafe { ark_std::mem::transmute(p.x.into_bigint()) },


and did we add test for this unsafe transmute anywhere?

also can you add comment that even though arkworks uses u64 limb (as opposed to u32 in icicle), they are both little-endian encoded, thus agree on a byte-level, which is why this unsafe transmute is correct.

^^ am I right?

alxiong · 2024-08-19T09:49:08Z

+        DeviceVec<IcicleAffine<<UnivariateKzgPCS<E> as GPUCommittable<E>>::IC>>,
        CudaStream,


do we strictly need type AdvzGPU? the 'srs lifetime can be removed at least?

Sure we could remove the lifetime specifier. I'm not sure what do you mean, AdvzGPU takes additional type generics for on GPU srs and CudaStream.

AdvzGPU takes additional type generics for on GPU srs and CudaStream.

i forgot about this. nvm. maybe just remove the lifetime.

…ellyfish into cl/icicle

mrain added 5 commits May 29, 2024 11:25

stress_test_gpu

c835ff1

comment

59adae1

upgrade to icicle 2.3.1

87dc6c6

Merge branch 'main' of github.com:EspressoSystems/jellyfish into cl/i…

73af41a

…cicle

bump to 2.4.0

84be0dd

mrain changed the title ~~chore: bump icicle to v2.3.1~~ chore: bump icicle to v2.4.0 Jun 10, 2024

mrain added 2 commits July 2, 2024 11:41

Merge branch 'main' of github.com:EspressoSystems/jellyfish into cl/i…

f5d321f

…cicle

bump icicle to 2.6.0

b04130a

mrain changed the title ~~chore: bump icicle to v2.4.0~~ chore: bump icicle to v2.6.0 Jul 2, 2024

This was referenced Jul 2, 2024

chore(deps): bump icicle-cuda-runtime from v1.5.1 to v2.6.0 #617

Closed

chore(deps): bump icicle-core from v1.5.1 to v2.6.0 #616

Closed

chore(deps): bump icicle-bn254 from v1.5.1 to v2.6.0 #615

Closed

mrain added 3 commits July 8, 2024 11:09

Merge branch 'main' into cl/icicle

e7ec82a

Merge branch 'main' of github.com:EspressoSystems/jellyfish into cl/i…

b97a147

…cicle

upgrade icicle

603d765

mrain changed the title ~~chore: bump icicle to v2.6.0~~ chore: bump icicle to v2.8.0 Aug 15, 2024

mrain marked this pull request as ready for review August 15, 2024 15:23

mrain requested review from akonring, alxiong and ggutoski as code owners August 15, 2024 15:23

mrain commented Aug 15, 2024

View reviewed changes

ggutoski reviewed Aug 15, 2024

View reviewed changes

alxiong reviewed Aug 19, 2024

View reviewed changes

Merge branches 'cl/icicle' and 'main' of github.com:EspressoSystems/j…

7c21407

…ellyfish into cl/icicle

		/// Stress test with varied payload sizes for GPU memory
		/// leakage/fragmentation.

		DeviceVec<IcicleAffine<<UnivariateKzgPCS<E> as GPUCommittable<E>>::IC>>,
		CudaStream,

Conversation

mrain commented May 29, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

This PR:

This PR does not:

Key places to review:

Uh oh!

alxiong commented Jul 3, 2024

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ggutoski left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mrain Aug 19, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

mrain commented May 29, 2024 •

edited

Loading

mrain Aug 19, 2024 •

edited

Loading