From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 1D26C7FA5C for ; Sat, 14 May 2016 10:41:27 +0200 (CEST) IronPort-PHdr: 9a23:El15zhKUaBDy4/1pgdmcpTZWNBhigK39O0sv0rFitYgVK/rxwZ3uMQTl6Ol3ixeRBMOAu6MC0bGd6/yocFdDyKjCmUhKSIZLWR4BhJdetC0bK+nBN3fGKuX3ZTcxBsVIWQwt1Xi6NU9IBJS2PAWK8TWM5DIfUi/yKRBybrysXNWC3oLtjKvqp9X6WEZhunmUWftKNhK4rAHc5IE9oLBJDeIP8CbPuWZCYO9MxGlldhq5lhf44dqsrtY4q3wD89pozcNLUL37cqIkVvQYSW1+ayFm0vb2rgHORhej4X4VU2Ne0kYZQluN0BavFKz2vyTmrO1lnGG/PMb2RL0wE3z26qZgSBbljGEcMDM27HvQkuRxir5WpFSqoBkpkKDOZ4TACPp5e6rGNfkATGtLV8BNH3hdAoS5ZpBJBfAIPOxRqZXVqF4HrB/4Dg6pUrC8ggRUj2P7iPVpm98qFhvLiUl9Rt8= Authentication-Results: mail2-smtp-roc.national.inria.fr; spf=None smtp.pra=thomas.braibant@gmail.com; spf=Pass smtp.mailfrom=thomas.braibant@gmail.com; spf=None smtp.helo=postmaster@mail-qg0-f44.google.com Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of thomas.braibant@gmail.com) identity=pra; client-ip=209.85.192.44; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="thomas.braibant@gmail.com"; x-sender="thomas.braibant@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of thomas.braibant@gmail.com designates 209.85.192.44 as permitted sender) identity=mailfrom; client-ip=209.85.192.44; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="thomas.braibant@gmail.com"; x-sender="thomas.braibant@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-qg0-f44.google.com) identity=helo; client-ip=209.85.192.44; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="thomas.braibant@gmail.com"; x-sender="postmaster@mail-qg0-f44.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0COAAD84zZXjyzAVdFehAx+Bqhwi3eFBYF2IoVvAoEhBzoSAQEBAQEBAQERAQEBAQcLCwkhL4ItghUBAQEDAQ4EER0BCBMJCQsBAwEHBAYDAgsGBAEBAQ0aAwICIQEBEQEFAQoBCQgGExIQh3IBAw8IDpUFj0KBMT4xizuBaoJYBYdgChknAwpSg1UBAQEBAQEBAQEBAQEBAQEBAQEBAQEUAgYQhhWDSoEDgkOCKYJTglkFhjsMkS8xgVaEKIYngXmBaU6HK4U3h1yGJxIegQ4PFwGCNAwSCoFMOzIBiAUBAQE X-IPAS-Result: A0COAAD84zZXjyzAVdFehAx+Bqhwi3eFBYF2IoVvAoEhBzoSAQEBAQEBAQERAQEBAQcLCwkhL4ItghUBAQEDAQ4EER0BCBMJCQsBAwEHBAYDAgsGBAEBAQ0aAwICIQEBEQEFAQoBCQgGExIQh3IBAw8IDpUFj0KBMT4xizuBaoJYBYdgChknAwpSg1UBAQEBAQEBAQEBAQEBAQEBAQEBAQEUAgYQhhWDSoEDgkOCKYJTglkFhjsMkS8xgVaEKIYngXmBaU6HK4U3h1yGJxIegQ4PFwGCNAwSCoFMOzIBiAUBAQE X-IronPort-AV: E=Sophos;i="5.24,617,1454972400"; d="scan'208,217";a="218263529" Received: from mail-qg0-f44.google.com ([209.85.192.44]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 14 May 2016 10:41:25 +0200 Received: by mail-qg0-f44.google.com with SMTP id 90so68986232qgz.1 for ; Sat, 14 May 2016 01:41:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=WeNZG1eAXdx8sYBtPNJUv8V+kpvnRk4Yt/r2b21Lb4s=; b=UaBYLUmwaptOacpkiy5Aid4CQQnv9muOe4bp40iUs59ZgO3AjehZJrc586/zrMnlbr mG5l1fCBCPoUsIrLh6L42IHxoz/7I43IMndxka0oTUnwbYsypt8VK/bYEN2XlCtYb++5 PN6nC7UNWoojJBw5MQIljylabFMmc21J5AxsOPeOJYBMhiEQJU7Led4D3yHPDAUHTnhN DsqmpIjWms6sIh+jSpgyNcD3nIH8dLTsQUfO+nzJBK0Q0i12uA2chly09/09o92Zxud/ CUdF/wwsv0ofZRcMjtMRo7jx/YPWJI0NyssLRjhvezC7PFrK2+oyoDZbZjpQ1Dmrtet0 zQAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=WeNZG1eAXdx8sYBtPNJUv8V+kpvnRk4Yt/r2b21Lb4s=; b=kgqB+5WNzKMrD93ltX8A6VANZWHFW4T8+Axz2e6ND8RriSttvadcIrYsbhynQapj30 uhxnlhKJ9PurhmEQABbrR/WlPugqh+Hb6t+BUsJMwxaPutX60KC4EHZ9MccwXIgDo1Wd /0RdyCKZX3nXkG8PFtie1/SgyIRG2so1HQu3obLLDf9rbDGaoKLuE6OxczeuXZJzxGDX 77qku1hGAkknYgW7n3qYn0ExmFWbxzIwcWWLgw6msH07JEeXmxl1cN3hq49jswvH80HF xRyVPSDw7iV8br71tiDN3SYrazbbzHqhjdRg5oAqWTqiNmNPdNy7AU35JoXSvq4K8Mqo 46fQ== X-Gm-Message-State: AOPr4FVotWbyi9EPb0jDwOjw0+AuWbkRYuMBUZUAObvcq+TjHgIzHxWkIS+P8aBmM++FqdFsFi0jk89eNU+5Fw== MIME-Version: 1.0 X-Received: by 10.140.20.203 with SMTP id 69mr874124qgj.52.1463215284171; Sat, 14 May 2016 01:41:24 -0700 (PDT) Received: by 10.140.92.173 with HTTP; Sat, 14 May 2016 01:41:24 -0700 (PDT) Received: by 10.140.92.173 with HTTP; Sat, 14 May 2016 01:41:24 -0700 (PDT) In-Reply-To: <0F7D3B1B3C4B894D824F5B822E3E5A172CEF2DF6@IRSMSX102.ger.corp.intel.com> References: <0F7D3B1B3C4B894D824F5B822E3E5A172CEF1630@IRSMSX102.ger.corp.intel.com> <850765ff-25f1-ecb9-9707-74d3dc47675c@lexifi.com> <5735DBB9.5050101@ocamlpro.com> <44df5d5e-8ad9-1a86-7fda-bfc203bfb479@lexifi.com> <0F7D3B1B3C4B894D824F5B822E3E5A172CEF2D2F@IRSMSX102.ger.corp.intel.com> <0F7D3B1B3C4B894D824F5B822E3E5A172CEF2DF6@IRSMSX102.ger.corp.intel.com> Date: Sat, 14 May 2016 09:41:24 +0100 Message-ID: From: Thomas Braibant To: "Soegtrop, Michael" Cc: Alain Frisch , OCaML Mailing List , Pierre Chambart Content-Type: multipart/alternative; boundary=001a11c124f83e3cc30532c95bbf Subject: RE: [Caml-list] Specify the default hash function for a type --001a11c124f83e3cc30532c95bbf Content-Type: text/plain; charset=UTF-8 Dear Michael, 256 might be too small for your use case if you have big lists in your records. A way to workaround this limitation is to use the seeded_hash function to fold an hash accumulator through your record. That is, if your record has fields f1, ..., fn you might want to write let hash t = let x = seeded_hash (hash t.f1) (hash t.f2) in let x = seeded_hash x (hash t.f3) in ... seeded_hash x (hash t.fn) On 14 May 2016 00:46, "Soegtrop, Michael" wrote: > Dear Tom, > > thanks for the pointer to the manual. I googled, but couldn't find this > info - should have read the manual first. Yes, 10 is for sure not enough in > my case. I will try the hash function with a value adjusted to my case and > compare with mine. > > Best regards, > > Michael > > > -----Original Message----- > > From: Thomas Braibant [mailto:thomas.braibant@gmail.com] > > Sent: Friday, May 13, 2016 8:57 PM > > To: Soegtrop, Michael > > Cc: Alain Frisch; Pierre Chambart; caml-list@inria.fr > > Subject: Re: [Caml-list] Specify the default hash function for a type > > > > The OCaml hash function is not bad in itself (it's a slightly modified > version > > of Murmur 3, with a 32 bit state). There are a few difficult design > decisions > > that are made in the main hash loop which can impact users though. > > > > I wonder if the one that you are hitting is the fact that by default the > > polymorphic hash function only consider a (small) amount of meaningful > > value, in a breadth first manner. The following program is interesting > > > > ``` > > let rec make n acc = if n = 0 then acc else make (n - 1) (n :: acc);; > let r = ref 0 in > > while Hashtbl.hash (make !r []) <> Hashtbl.hash (make (!r + 1) []) do > incr r; > > done; !r;; > > - : int = 10 > > ``` > > > > The current default choice for the number of meaningful values is > described > > here: > > http://caml.inria.fr/pub/docs/manual-ocaml/libref/Hashtbl.html > > and it is indeed 10. You could try to increase the number of meaningful > > nodes that you want to consider in your code, to the max of 256. > > > > There is really a balance to strike here between speed of hashing and > > collisions. > > > > Tom > > > > > > > > > > > > On Fri, May 13, 2016 at 6:17 PM, Soegtrop, Michael > > wrote: > > > Dear Ocaml Users, > > > > > > a possibly interesting data point in the discussion on polymorphic > hashes: > > > > > > I replaced the polymorphic hash function for a record, which consists > of > > smallish integers, bools, lists of integers and short strings, with my > own > > hash function which looks like: > > > > > > ( ( ( (v1 * p1 + v2) * p2) + v3 ) *p3 + v4) * p4 > > > > > > where vi are values and pi are distinct prime numbers. For lists I use > 4 > > primes alternatingly and 4 different primes for empty cases (implemented > > as 4 mutual recursive functions). The primes are random primes between > > 2^28 and 2^29, avoiding those primes where larger powers of 2 are close > to 0 > > modulo the prime. All arithmetic is done with plain ocaml ints and > > corresponding overflows. For strings I used the polymorphic hash > function. > > > > > > The hash histogram for this hash function looks like this: > > > > > > num_bindings=1803454 > > > num_buckets=16777216 > > > max_bucket_length=24 > > > (the histogram is "number of items in bucket=count of buckets with > > > this number of items") > > > 0=15356268 (empty buckets) > > > 1=1185329 (non-colliding buckets) > > > 2=135231 > > > 3=80194 > > > 4=11344 > > > 5=2367 > > > 6=2836 > > > 7=2630 > > > 8=244 > > > 9=49 > > > 10=20 > > > 11=25 > > > 12=64 > > > 13=39 > > > 14=100 > > > 15=75 > > > 16=33 > > > 17=5 > > > 18=149 > > > 19=15 > > > 20=3 > > > 21=180 > > > 22=14 > > > 24=2 > > > > > > This is roughly in line with random numbers: > > > > > > fill rate = 1803454/16777216 = 10.7% > > > 2 collisions = 0.8% ~ fill rate ^2 > > > 3 collisions = 0.48% ~ 4 * fill rate ^3 > > > 4 collisions = 0.068% ~ 5 * fill rate ^4 > > > > > > The hash histogram for the same data and the polymorphic hash function > > looks like this: > > > > > > num_bindings=1803454 > > > num_buckets=16777216 > > > max_bucket_length=3343 > > > 0=16730926 > > > 1=5520 > > > 2=3201 > > > 3=2779 > > > 4=1633 > > > 5=1079 > > > 6=3701 > > > 7=672 > > > 8=828 > > > 9=1584 > > > 10=600 > > > 11=384 > > > 12=2774 > > > 13=404 > > > 14=525 > > > 15=500 > > > 16=435 > > > 17=358 > > > 18=1406 > > > 19=244 > > > 20=504 > > > 21=427 > > > 22=316 > > > 23=369 > > > 24=837 > > > 25=153 > > > 26=250 > > > 27=417 > > > 28=191 > > > 29=222 > > > 30=501 > > > 31=76 > > > 32=196 > > > 33=530 > > > 34=142 > > > 35=153 > > > 36=859 > > > 37=88 > > > 38=178 > > > 39=310 > > > 40=147 > > > 41=173 > > > 42=313 > > > 43=102 > > > 44=235 > > > 45=123 > > > 46=149 > > > 47=152 > > > 48=244 > > > 49=107 > > > 50=173 > > > : > > > : > > > 1001=1 > > > 1002=1 > > > 1005=1 > > > 1006=3 > > > 1009=1 > > > 1010=1 > > > 1013=1 > > > 1014=2 > > > 1019=1 > > > 1020=1 > > > 1029=1 > > > 1031=1 > > > 1034=1 > > > 1035=1 > > > 1036=1 > > > 1064=1 > > > 1082=1 > > > 1184=1 > > > 1191=1 > > > 1196=1 > > > 1197=1 > > > 1200=1 > > > 1206=1 > > > 1207=1 > > > 1219=1 > > > 1225=1 > > > 1228=1 > > > 1232=1 > > > 1566=1 > > > 1581=1 > > > 1636=1 > > > 1698=1 > > > 1720=2 > > > 1737=2 > > > 1740=1 > > > 1744=1 > > > 1752=1 > > > 1762=1 > > > 1789=1 > > > 2255=1 > > > 2271=1 > > > 2287=1 > > > 2319=1 > > > 2332=1 > > > 2345=1 > > > 3296=1 > > > 3325=1 > > > 3343=1 > > > > > > So there are many buckets with 1000s of collisions and only a few 1000 > > collision free buckets. > > > > > > It might make sense to come up with a better polymorphic hashing > > function. > > > > > > Best regards, > > > > > > Michael > > > Intel Deutschland GmbH > > > Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany > > > Tel: +49 89 99 8853-0, www.intel.de > > > Managing Directors: Christin Eisenschmid, Christian Lamprechter > > > Chairperson of the Supervisory Board: Nicole Lau Registered Office: > > > Munich Commercial Register: Amtsgericht Muenchen HRB 186928 > > > > > > > > > -- > > > Caml-list mailing list. Subscription management and archives: > > > https://sympa.inria.fr/sympa/arc/caml-list > > > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > > > Bug reports: http://caml.inria.fr/bin/caml-bugs > Intel Deutschland GmbH > Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany > Tel: +49 89 99 8853-0, www.intel.de > Managing Directors: Christin Eisenschmid, Christian Lamprechter > Chairperson of the Supervisory Board: Nicole Lau > Registered Office: Munich > Commercial Register: Amtsgericht Muenchen HRB 186928 > --001a11c124f83e3cc30532c95bbf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Dear Michael,

256 might be too small for your use case if you have big lis= ts in your records. A way to workaround this limitation is to use the seede= d_hash function to fold an hash accumulator through your record.

That is, if your record has fields f1, ..., fn
you might want to write

let hash t =3D
=C2=A0=C2=A0 let x =3D seeded_hash (hash t.f1) (hash t.f2) in
=C2=A0=C2=A0 let x =3D seeded_hash x (hash t.f3) in
=C2=A0=C2=A0 ...
=C2=A0=C2=A0 seeded_hash x (hash t.fn)


=C2=A0=C2=A0
=C2=A0=C2=A0

On 14 May 2016 00:46, "Soegtrop, Michael&qu= ot; <michael.soegtrop@inte= l.com> wrote:
Dear Tom,

thanks for the pointer to the manual. I googled, but couldn't find this= info - should have read the manual first. Yes, 10 is for sure not enough i= n my case. I will try the hash function with a value adjusted to my case an= d compare with mine.

Best regards,

Michael

> -----Original Message-----
> From: Thomas Braibant [mailto:thomas.braibant@gmail.com]
> Sent: Friday, May 13, 2016 8:57 PM
> To: Soegtrop, Michael
> Cc: Alain Frisch; Pierre Chambart; caml-list@inria.fr
> Subject: Re: [Caml-list] Specify the default hash function for a type<= br> >
> The OCaml hash function is not bad in itself (it's a slightly modi= fied version
> of Murmur 3, with a 32 bit state). There are a few difficult design de= cisions
> that are made in the main hash loop which can impact users though.
>
> I wonder if the one that you are hitting is the fact that by default t= he
> polymorphic hash function only consider a (small) amount of meaningful=
> value, in a breadth first manner. The following program is interesting=
>
> ```
> let rec make n acc =3D if n =3D 0 then acc else make (n - 1) (n :: acc= );; let r =3D ref 0 in
> while Hashtbl.hash (make !r []) <> Hashtbl.hash (make (!r + 1) [= ]) do incr r;
> done; !r;;
> - : int =3D 10
> ```
>
> The current default choice for the number of meaningful values is desc= ribed
> here:
> http://caml.inria.fr/pub/docs/man= ual-ocaml/libref/Hashtbl.html
> and it is indeed 10. You could try to increase the number of meaningfu= l
> nodes that you want to consider in your code, to the max of 256.
>
> There is really a balance to strike here between speed of hashing and<= br> > collisions.
>
> Tom
>
>
>
>
>
> On Fri, May 13, 2016 at 6:17 PM, Soegtrop, Michael
> <michael.soegtrop@int= el.com> wrote:
> > Dear Ocaml Users,
> >
> > a possibly interesting data point in the discussion on polymorphi= c hashes:
> >
> > I replaced the polymorphic hash function for a record, which cons= ists of
> smallish integers, bools, lists of integers and short strings, with my= own
> hash function which looks like:
> >
> > ( ( ( (v1 * p1 + v2) * p2) + v3 ) *p3 + v4) * p4
> >
> > where vi are values and pi are distinct prime numbers. For lists = I use 4
> primes alternatingly and 4 different primes for empty cases (implement= ed
> as 4 mutual recursive functions). The primes are random primes between=
> 2^28 and 2^29, avoiding those primes where larger powers of 2 are clos= e to 0
> modulo the prime. All arithmetic is done with plain ocaml ints and
> corresponding overflows. For strings I used the polymorphic hash funct= ion.
> >
> > The hash histogram for this hash function looks like this:
> >
> > num_bindings=3D1803454
> > num_buckets=3D16777216
> > max_bucket_length=3D24
> > (the histogram is "number of items in bucket=3Dcount of buck= ets with
> > this number of items")
> > 0=3D15356268 (empty buckets)
> > 1=3D1185329 (non-colliding buckets)
> > 2=3D135231
> > 3=3D80194
> > 4=3D11344
> > 5=3D2367
> > 6=3D2836
> > 7=3D2630
> > 8=3D244
> > 9=3D49
> > 10=3D20
> > 11=3D25
> > 12=3D64
> > 13=3D39
> > 14=3D100
> > 15=3D75
> > 16=3D33
> > 17=3D5
> > 18=3D149
> > 19=3D15
> > 20=3D3
> > 21=3D180
> > 22=3D14
> > 24=3D2
> >
> > This is roughly in line with random numbers:
> >
> > fill rate =3D 1803454/16777216 =3D 10.7%
> > 2 collisions =3D 0.8% ~ fill rate ^2
> > 3 collisions =3D 0.48% ~ 4 * fill rate ^3
> > 4 collisions =3D 0.068% ~ 5 * fill rate ^4
> >
> > The hash histogram for the same data and the polymorphic hash fun= ction
> looks like this:
> >
> > num_bindings=3D1803454
> > num_buckets=3D16777216
> > max_bucket_length=3D3343
> > 0=3D16730926
> > 1=3D5520
> > 2=3D3201
> > 3=3D2779
> > 4=3D1633
> > 5=3D1079
> > 6=3D3701
> > 7=3D672
> > 8=3D828
> > 9=3D1584
> > 10=3D600
> > 11=3D384
> > 12=3D2774
> > 13=3D404
> > 14=3D525
> > 15=3D500
> > 16=3D435
> > 17=3D358
> > 18=3D1406
> > 19=3D244
> > 20=3D504
> > 21=3D427
> > 22=3D316
> > 23=3D369
> > 24=3D837
> > 25=3D153
> > 26=3D250
> > 27=3D417
> > 28=3D191
> > 29=3D222
> > 30=3D501
> > 31=3D76
> > 32=3D196
> > 33=3D530
> > 34=3D142
> > 35=3D153
> > 36=3D859
> > 37=3D88
> > 38=3D178
> > 39=3D310
> > 40=3D147
> > 41=3D173
> > 42=3D313
> > 43=3D102
> > 44=3D235
> > 45=3D123
> > 46=3D149
> > 47=3D152
> > 48=3D244
> > 49=3D107
> > 50=3D173
> > :
> > :
> > 1001=3D1
> > 1002=3D1
> > 1005=3D1
> > 1006=3D3
> > 1009=3D1
> > 1010=3D1
> > 1013=3D1
> > 1014=3D2
> > 1019=3D1
> > 1020=3D1
> > 1029=3D1
> > 1031=3D1
> > 1034=3D1
> > 1035=3D1
> > 1036=3D1
> > 1064=3D1
> > 1082=3D1
> > 1184=3D1
> > 1191=3D1
> > 1196=3D1
> > 1197=3D1
> > 1200=3D1
> > 1206=3D1
> > 1207=3D1
> > 1219=3D1
> > 1225=3D1
> > 1228=3D1
> > 1232=3D1
> > 1566=3D1
> > 1581=3D1
> > 1636=3D1
> > 1698=3D1
> > 1720=3D2
> > 1737=3D2
> > 1740=3D1
> > 1744=3D1
> > 1752=3D1
> > 1762=3D1
> > 1789=3D1
> > 2255=3D1
> > 2271=3D1
> > 2287=3D1
> > 2319=3D1
> > 2332=3D1
> > 2345=3D1
> > 3296=3D1
> > 3325=3D1
> > 3343=3D1
> >
> > So there are many buckets with 1000s of collisions and only a few= 1000
> collision free buckets.
> >
> > It might make sense to come up with a better polymorphic hashing<= br> > function.
> >
> > Best regards,
> >
> > Michael
> > Intel Deutschland GmbH
> > Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
> > Tel: +49 89 99 8853-0, www.intel.de
> > Managing Directors: Christin Eisenschmid, Christian Lamprechter > > Chairperson of the Supervisory Board: Nicole Lau Registered Offic= e:
> > Munich Commercial Register: Amtsgericht Muenchen HRB 186928
> >
> >
> > --
> > Caml-list mailing list.=C2=A0 Subscription management and archive= s:
> > https://sympa.inria.fr/sympa/arc/caml-list > > Beginner's list: http://groups.yahoo.com/= group/ocaml_beginners
> > Bug reports: http://caml.inria.fr/bin/caml-bugs
Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89= 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928
--001a11c124f83e3cc30532c95bbf--