chore: bump icicle to v2.8.0 #595

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

vid/Cargo.toml

@@ -38,7 +38,7 @@ ark-ed-on-bls12-377 = "0.4.0"
 ark-ed-on-bls12-381 = "0.4.0"
 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

pcs/src/univariate_kzg/mod.rs

        fn ark_affine_to_icicle(p: ark_bn254::G1Affine) -> icicle_bn254::curve::G1Affine {
            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

pcs/src/univariate_kzg/mod.rs

        /// - 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

pcs/src/lib.rs

    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

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

vid/Cargo.toml

@@ -38,7 +38,7 @@ ark-ed-on-bls12-377 = "0.4.0"
 ark-ed-on-bls12-381 = "0.4.0"
 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

vid/src/advz/test.rs

+/// 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

pcs/src/univariate_kzg/mod.rs

        fn ark_affine_to_icicle(p: ark_bn254::G1Affine) -> icicle_bn254::curve::G1Affine {
            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

vid/src/advz.rs

+        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.

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 ggutoski, akonring and alxiong 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

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

chore: bump icicle to v2.8.0 #595

chore: bump icicle to v2.8.0 #595

mrain commented May 29, 2024 •

edited

Loading

alxiong commented Jul 3, 2024

mrain Aug 15, 2024

ggutoski Aug 15, 2024

alxiong Aug 19, 2024

ggutoski left a comment

ggutoski Aug 15, 2024

alxiong Aug 19, 2024

mrain Aug 19, 2024 •

edited

Loading

ggutoski Aug 15, 2024

mrain Aug 19, 2024

alxiong Aug 19, 2024

alxiong Aug 19, 2024

alxiong Aug 19, 2024

mrain Aug 19, 2024

ggutoski Aug 19, 2024

alxiong Aug 19, 2024

alxiong Aug 19, 2024

mrain Aug 19, 2024

alxiong Aug 19, 2024

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

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

chore: bump icicle to v2.8.0 #595

Are you sure you want to change the base?

chore: bump icicle to v2.8.0 #595

Conversation

mrain commented May 29, 2024 • edited Loading

This PR:

This PR does not:

Key places to review:

alxiong commented Jul 3, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ggutoski left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mrain Aug 19, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mrain commented May 29, 2024 •

edited

Loading

mrain Aug 19, 2024 •

edited

Loading