Native 64-bit Linux build

[zsx]

This adds native linux 64-bit supports. Tested with github/rebol-test, three progressions and no regression agains master 32-bit found:

--- r_2_101_0_4_4_22C633_4E5726.log 2013-08-31 10:01:12.003341307 -0400
+++ r_2_101_0_4_40_183F68_4E5726.log    2013-08-28 09:39:34.563339334 -0400
@@ -4849,13 +4849,13 @@
 [0.1 == round/half-down/to 0.15 0.1] "succeeded"
 [0.2 == round/half-down/to 0.15001 0.1] "succeeded"
 [0.5 == round/half-down/to 0.55 0.1] "succeeded"
-[0.6 == round/half-down/to 0.55001 0.1] "failed"
+[0.6 == round/half-down/to 0.55001 0.1] "succeeded"
 [0.5 == round/half-down/to 0.75 0.5] "succeeded"
 [1.0 == round/half-down/to 0.75001 0.5] "succeeded"
 [-0.1 == round/half-down/to -0.15 0.1] "succeeded"
 [-0.2 == round/half-down/to -0.15001 0.1] "succeeded"
 [-0.5 == round/half-down/to -0.55 0.1] "succeeded"
-[-0.6 == round/half-down/to -0.55001 0.1] "failed"
+[-0.6 == round/half-down/to -0.55001 0.1] "succeeded"
 [-0.5 == round/half-down/to -0.75 0.5] "succeeded"
 [-1.0 == round/half-down/to -0.75001 0.5] "succeeded"
 [0 = sign? 0] "succeeded"
@@ -5825,7 +5825,7 @@
    error? try blk
 ] "succeeded"
 [error? try [apply 'type?/word []]] "succeeded"
-[same? :add attempt [apply does [return/redo :add] []]] "failed"
+[same? :add attempt [apply does [return/redo :add] []]] "succeeded"
 [2 == do does [return apply :do [:add 1 1] 4 4]] "failed"
 [1 == apply :subtract [2 1]] "succeeded"
 [1 == apply :- [2 1]] "succeeded"
@@ -8463,12 +8463,12 @@
 ] "failed, error was caused in the test code"
 [equal? read write clipboard:// c: "test" c] "failed, error was caused in the test code"

-system/version: 2.101.0.4.4
-code-checksum: #{22C633E24BFD4FDBE04A6098E41BD954C3B7D04C}
+system/version: 2.101.0.4.40
+code-checksum: #{183F684918FA91FE87D599821E541D30651FBE9D}
 test-checksum: #{4E5726B3CE4645AC5EAB8AF08F677090E0998DD3}
 Total: 4696
-Succeeded: 4211
-Test-failures: 161
+Succeeded: 4214
+Test-failures: 158
 Crashes: 16
 Dialect-failures: 0
 Skipped: 308

[ladislav]

Log diff between current master 0.4.4 and this update when the target is 0.4.40 shows one progression here:

[10.10.10 == divide 1.1.1 .1] progression, succeeded

Summary:

new-successes: 0
new-failures: 0
new-crashes: 0
progressions: 1
regressions: 0
removed: 0
unchanged: 4695
total: 4696

gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)

[zsx]

I am using gcc (GCC) 4.8.1 20130725 (prerelease) on Archlinux

[ladislav]

I used the same compiler for the current master and for the updated code and obtained no difference comparing the current master and this update when the target was 0.4.4 for both.

Thus, the patches are verified to not cause regressions in 0.4.4.

Also verified to not cause regressions in 0.3.1

[ladislav]

Also, perhaps interestingly, my http://www.fm.tul.cz/~ladislav/rebol/bench.r runs faster in 0.4.40 than in 0.4.4 although the speed increase is small (+5% to +10%)

[earl]

I'm happy to report two more encouraging results: with this series of patches, R3 builds, runs, and tests fine on Linux on Itanium (IA64) as well as Linux on Alpha (AXP).

[onetom]

On a Mac, I got 1 regression:

[strict-equal? #[url! ""] to url! ""] crashed

$ r3 log-diff.r r_2_101_0_4_4_C8BB7C_4E5726.log r_2_101_0_4_40_70D367_4E5726.log
Done.

new-successes: 0
new-failures: 0
new-crashes: 0
progressions: 0
regressions: 1
removed: 0
unchanged: 4695
total: 4696

$ make clean && make make OS_ID=0.4.40 && make prep && time make
...

$ file r3
r3: Mach-O 64-bit executable x86_64

[onetom]

@ladislav [strict-equal? #[url! ""] to url! ""] crashed was the regression (that's what i got when i /usr/bin/diff-ed the filtered test logs, since the log-diff didn't tell it to me as u can see)

not sure what do you mean by "This looks premature", but having this patch would allow us to run rebol on 64bit linux cloud servers without the need of installing the ~100MB ia32-libs dependency.
that alone worth to integrate it, imho, even if there is nothing else 64bit about it...

[onetom]

@ladislav okay, it's just bad UX on github; they should emphasize the topic more in the comment header.
i didn't get you were commenting on a specific commit, not on the whole pull request. thanks!

[earl]

Recovering an earlier comment of Ladislav:

"The limit change looks premature, since the implementation of series hasn't changed yet."

[zsx]

Yes. So you think we should keep it as is until we change the
implementation of series? What I was thinking was that, even with current
series implemention and this patch, you could have a larger series.

Best Regards

Shixin Zeng

On Mon, Sep 9, 2013 at 2:48 PM, Andreas Bolka [email protected]:

In src/core/m-pools.c:

@@ -368,7 +368,11 @@

CHECK_STACK(&series);

+#ifdef LP64

• if (((REBU64)length * wide) > MAX_I64) Trap0(RE_NO_MEMORY);

Recovering an earlier comment of Ladislavhttps://github.com/zsx/r3/commit/bebdda231deb8a6b068eb421f33c60912944ee7c#commitcomment-4014963
:

"The limit change looks premature, since the implementation of series
hasn't changed yet."

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/142/files#r6246850
.

[ladislav]

I think that you obtain a crash trying to allocate a larger series if the limit isn't kept.

[zsx]

OK, I will remove this commit, even though I still don't quite get where
exactly it could crash due to memory limit.

Best Regards

Shixin Zeng

On Tue, Sep 10, 2013 at 4:12 AM, Ladislav Mecir [email protected]:

In src/core/m-pools.c:

@@ -368,7 +368,11 @@

CHECK_STACK(&series);

+#ifdef LP64

• if (((REBU64)length * wide) > MAX_I64) Trap0(RE_NO_MEMORY);

I think that you obtain a crash trying to allocate a larger series in the
present code base.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/142/files#r6259703
.

[earl]

One example which crashes (crashed) for me:

array 134'217'727

(With the limit adjustment now removed, this again just causes a "not enough memory" internal error.)

[zsx]

Since I don't have a Mac, I am afraid that I won't be able to fix this.

Best Regards

Shixin Zeng

On Mon, Sep 2, 2013 at 8:22 PM, onetom [email protected] wrote:

On a Mac, I got 1 regression:
[strict-equal? #[url! ""] to url! ""] crashed

$ r3 log-diff.r r_2_101_0_4_4_C8BB7C_4E5726.log
r_2_101_0_4_40_70D367_4E5726.log
Done.

new-successes: 0
new-failures: 0
new-crashes: 0
progressions: 0
regressions: 1
removed: 0
unchanged: 4695
total: 4696

$ make clean && make make OS_ID=0.4.40 && make prep && time make
...
0000000005614542 - 00 0000 OPT radr://5614542
ls -l r3
-rwxr-xr-x 1 onetom staff 569444 Sep 3 08:19 r3

real 0m12.364s
...
$ file r3
r3: Mach-O 64-bit executable x86_64

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/142#issuecomment-23684014
.

[ladislav]

Zeng, you "lost" the "add a new platform 0.4.40 for linux_x64" commit when updating the pull request.

[ladislav]

In the sys-value.h header file, REBALL is described as "All bits of value fields:". The REBALL type definition is not compatible with that when LP64 is defined. However, as I checked, the discrepancy does not cause any harm except for making the description invalid.

[zsx]

REBALL is easy to be fixed. We just need to change it to uintptr_t bits[3].

[ladislav]

Well, it certainly isn't (too) hard to fix, but this fix might break s-crc.c, I am afraid.

[ladislav]

Also, #147 is worth consulting, since it both suppresses compiler warnings for 32-bit cases and can do the same service for 64-bit case where applicable.

[ladislav]

This looks unbelievable, but 32-bit R3 actually became slower (less than 5%) after your last batch of changes.

While speed of 64-bit R3 did not change noticeably.

[zsx]

Compared with the https://github.com/rebol/rebol master?

Best Regards

Shixin Zeng

On Thu, Oct 3, 2013 at 8:03 AM, Ladislav Mecir [email protected]:

This looks unbelievable, but 32-bit R3 actually became slower (less than
5%) after your last batch of changes.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/142#issuecomment-25614779
.

[ladislav]

No, I just had your 64-master state recorded before you made the last batch of changes including struct rearrangement and I compared speed of the older 64-master with the speed of the new 64-master containing your last batch of changes including struct rearrangement.

Best Regards, Ladislav

[ladislav]

I guess I know why the struct rearrangement does not have positive effect: there are the #pragma pack(4) directives preceding many struct declarations and they were most probably meant for 32-bit programs. Curiously enough, I guess that they don't have any effect on 32-bit programs.

[zsx]

I think that should actually be the reason it should improve the
performance. When it's packed at 4, 64-bit types might not aligned with
their natural boundaries. With the struct rearrangement, these types should
be aligned to their natural boundaries and still packed at 4.

Best Regards

Shixin Zeng

On Wed, Oct 9, 2013 at 12:52 PM, Ladislav Mecir [email protected]:

I guess I know why the struct rearrangement does not have positive effect:
there are the #pragma pack(4) directives preceding many struct declarations
and they were most probably meant for 32-bit programs. Curiously enough, I
guess that they don't have any effect on 32-bit programs.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/142#issuecomment-25987894
.

[ladislav]

Aha, well, but there was no performance improvement as I noted above, and a slow down in 32-bit version, so this is not what you expected.

Best Regards

Ladislav

[zsx]

Yep, that's kind of surprising. I'll take a look when I have time.

Best Regards

Shixin Zeng

On Mon, Oct 14, 2013 at 5:28 PM, Ladislav Mecir [email protected]:

Aha, well, but there was no performance improvement as I noted above, and
a slow down in 32-bit version, so this is not what you expected.

Best Regards

Ladislav

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/142#issuecomment-26290378
.

[carls]

See newer #178 pull for latest 64 bit support. Closing this pull.