Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.os.linux.advocacy > #408385 > unrolled thread
| Started by | owl <owl@rooftop.invalid> |
|---|---|
| First post | 2017-04-14 17:07 +0000 |
| Last post | 2017-04-17 08:23 -0700 |
| Articles | 20 on this page of 92 — 11 participants |
Back to article view | Back to comp.os.linux.advocacy
BOOM! owl <owl@rooftop.invalid> - 2017-04-14 17:07 +0000
Re: BOOM! DFS <nospam@dfs.com> - 2017-04-14 13:33 -0400
Re: BOOM! owl <owl@rooftop.invalid> - 2017-04-14 17:49 +0000
Re: BOOM! fr314159@gmail.com - 2017-04-14 13:00 -0700
Re: BOOM! owl <owl@rooftop.invalid> - 2017-04-14 20:26 +0000
Re: BOOM! DFS <nospam@dfs.com> - 2017-04-15 10:00 -0400
Re: BOOM! DFS <nospam@dfs.com> - 2017-04-14 19:58 -0400
Re: BOOM! owl <owl@rooftop.invalid> - 2017-04-15 00:14 +0000
Re: BOOM! DFS <nospam@dfs.com> - 2017-04-14 20:23 -0400
Re: BOOM! owl <owl@rooftop.invalid> - 2017-04-15 00:51 +0000
Re: BOOM! Snit <usenet@gallopinginsanity.com> - 2017-04-14 18:02 -0700
Re: BOOM! DFS <nospam@dfs.com> - 2017-04-14 21:30 -0400
Re: BOOM! owl <owl@rooftop.invalid> - 2017-04-15 01:48 +0000
Re: BOOM! DFS <nospam@dfs.com> - 2017-04-15 10:00 -0400
Re: BOOM! owl <owl@rooftop.invalid> - 2017-04-15 19:29 +0000
Re: BOOM! Chris Ahlstrom <OFeem1987@teleworm.us> - 2017-04-15 16:24 -0400
Re: BOOM! owl <owl@rooftop.invalid> - 2017-04-15 21:10 +0000
Re: BOOM! DFS <nospam@dfs.com> - 2017-04-15 18:42 -0400
Re: BOOM! owl <owl@rooftop.invalid> - 2017-04-15 23:31 +0000
Re: BOOM! DFS <nospam@dfs.com> - 2017-04-15 20:29 -0400
Re: BOOM! owl <owl@rooftop.invalid> - 2017-04-16 05:25 +0000
Re: BOOM! DFS <nospam@dfs.com> - 2017-04-16 19:49 -0400
Re: BOOM! owl <owl@rooftop.invalid> - 2017-04-17 00:51 +0000
Re: BOOM! DFS <nospam@dfs.com> - 2017-04-17 12:54 -0400
Re: BOOM! Steve Carroll <fretwizzer@gmail.com> - 2017-04-17 10:06 -0700
Re: BOOM! DFS <nospam@dfs.com> - 2017-04-17 19:28 -0400
Re: BOOM! Steve Carroll <fretwizzer@gmail.com> - 2017-04-17 17:21 -0700
Re: BOOM! DFS <nospam@dfs.com> - 2017-04-19 09:41 -0400
Re: BOOM! fr314159@gmail.com - 2017-04-19 07:48 -0700
Re: BOOM! DFS <nospam@dfs.com> - 2017-04-19 14:21 -0400
Re: BOOM! Snit <usenet@gallopinginsanity.com> - 2017-04-19 11:36 -0700
Re: BOOM! owl <owl@rooftop.invalid> - 2017-04-19 20:03 +0000
Re: BOOM! DFS <nospam@dfs.com> - 2017-04-19 16:24 -0400
Re: BOOM! Steve Carroll <fretwizzer@gmail.com> - 2017-04-19 08:37 -0700
Re: BOOM! owl <owl@rooftop.invalid> - 2017-04-19 17:50 +0000
Re: BOOM! DFS <nospam@dfs.com> - 2017-04-19 14:32 -0400
Re: BOOM! Snit <usenet@gallopinginsanity.com> - 2017-04-17 10:26 -0700
Ping DFS! - Re: BOOM! Steve Carroll <fretwizzer@gmail.com> - 2017-04-17 10:34 -0700
Re: Ping DFS! - Re: BOOM! DFS <nospam@dfs.com> - 2017-04-17 19:25 -0400
Re: Ping DFS! - Re: BOOM! Snit <usenet@gallopinginsanity.com> - 2017-04-17 16:45 -0700
Re: Ping DFS! - Re: BOOM! Steve Carroll <fretwizzer@gmail.com> - 2017-04-17 17:29 -0700
Re: Ping DFS! - ReBOOM! Fakey's Puppy Whistle Holder Emeritus 🐶笛 <root@127.0.0.1> - 2017-04-17 19:58 -0500
Re: Ping DFS! - ReBOOM! Snit <usenet@gallopinginsanity.com> - 2017-04-17 18:12 -0700
Re: Ping DFS! - ReBOOM! Fakey's Puppy Whistle Holder Emeritus 🐶笛 <root@127.0.0.1> - 2017-04-17 20:25 -0500
Re: Ping DFS! - ReBOOM! Snit <usenet@gallopinginsanity.com> - 2017-04-17 18:46 -0700
Re: Ping DFS! - ReBOOM! Fakey's Puppy Whistle Holder Emeritus 🐶笛 <root@127.0.0.1> - 2017-04-17 21:20 -0500
Re: Ping DFS! - ReBOOM! DFS <nospam@dfs.com> - 2017-04-22 21:04 -0400
Re: Ping DFS! - ReBOOM! Snit <usenet@gallopinginsanity.com> - 2017-04-22 18:20 -0700
Re: Ping DFS! - ReBOOM! Steve Carroll <fretwizzer@gmail.com> - 2017-04-22 19:12 -0700
Re: Ping DFS! - ReBOOM! Silver Slimer <sl@im.er> - 2017-04-24 08:14 -0400
Re: Ping DFS! - ReBOOM! Snit <usenet@gallopinginsanity.com> - 2017-04-24 09:36 -0700
Re: Ping DFS! - ReBOOM! Steve Carroll <fretwizzer@gmail.com> - 2017-04-24 09:52 -0700
Re: Ping DFS! - ReBOOM! Silver Slimer <sl@im.er> - 2017-04-24 17:36 -0400
Re: Ping DFS! - ReBOOM! Snit <usenet@gallopinginsanity.com> - 2017-04-24 14:39 -0700
Re: Ping DFS! - ReBOOM! Steve Carroll <fretwizzer@gmail.com> - 2017-04-22 19:23 -0700
Re: Ping DFS! - ReBOOM! Marek Novotny <marek.novotny@marspolar.com> - 2017-04-22 21:37 -0500
Re: Ping DFS! - ReBOOM! Snit <usenet@gallopinginsanity.com> - 2017-04-22 22:55 -0700
Re: Ping DFS! - ReBOOM! Steve Carroll <fretwizzer@gmail.com> - 2017-04-17 19:00 -0700
Re: BOOM! owl <owl@rooftop.invalid> - 2017-04-17 17:29 +0000
Re: BOOM! Snit <usenet@gallopinginsanity.com> - 2017-04-17 10:34 -0700
Re: BOOM! owl <owl@rooftop.invalid> - 2017-04-17 17:49 +0000
Re: BOOM! DFS <nospam@dfs.com> - 2017-04-17 19:25 -0400
Re: BOOM! owl <owl@rooftop.invalid> - 2017-04-18 00:06 +0000
Re: BOOM! Snit <usenet@gallopinginsanity.com> - 2017-04-17 17:28 -0700
Re: BOOM! DFS <nospam@dfs.com> - 2017-04-18 12:00 -0400
Re: BOOM! Snit <usenet@gallopinginsanity.com> - 2017-04-18 09:28 -0700
Re: BOOM! owl <owl@rooftop.invalid> - 2017-04-18 20:11 +0000
Re: BOOM! Snit <usenet@gallopinginsanity.com> - 2017-04-18 13:13 -0700
Re: BOOM! DFS <nospam@dfs.com> - 2017-04-19 15:36 -0400
Re: BOOM! Snit <usenet@gallopinginsanity.com> - 2017-04-19 12:44 -0700
Re: BOOM! owl <owl@rooftop.invalid> - 2017-04-19 19:59 +0000
Re: BOOM! Snit <usenet@gallopinginsanity.com> - 2017-04-19 13:17 -0700
Re: BOOM! DFS <nospam@dfs.com> - 2017-04-20 00:54 -0400
Re: BOOM! owl <owl@rooftop.invalid> - 2017-04-20 07:02 +0000
Re: BOOM! DFS <nospam@dfs.com> - 2017-04-20 21:46 -0400
Re: BOOM! owl <owl@rooftop.invalid> - 2017-04-21 02:20 +0000
Re: BOOM! Snit <usenet@gallopinginsanity.com> - 2017-04-20 19:44 -0700
Re: BOOM! DFS <nospam@dfs.com> - 2017-04-20 23:40 -0400
Re: BOOM! owl <owl@rooftop.invalid> - 2017-04-21 13:40 +0000
Re: BOOM! DFS <nospam@dfs.com> - 2017-04-21 09:54 -0400
Re: BOOM! owl <owl@rooftop.invalid> - 2017-04-21 14:01 +0000
Re: BOOM! Snit <usenet@gallopinginsanity.com> - 2017-04-14 17:37 -0700
Re: BOOM! Chris Ahlstrom <OFeem1987@teleworm.us> - 2017-04-15 06:41 -0400
Re: BOOM! Chris Ahlstrom <OFeem1987@teleworm.us> - 2017-04-14 13:34 -0400
Re: BOOM! John McCue <jmccue@jmcnet2.bstnma.east.verizon.net> - 2017-04-15 21:33 +0000
Re: BOOM! chrisv <chrisv@nospam.invalid> - 2017-04-17 07:09 -0500
Re: BOOM! John McCue <jmccue@jmcnet2.bstnma.east.verizon.net> - 2017-04-18 22:46 +0000
Re: BOOM! owl <owl@rooftop.invalid> - 2017-04-18 23:08 +0000
Re: BOOM! Snit <usenet@gallopinginsanity.com> - 2017-04-18 16:32 -0700
Re: BOOM! John McCue <jmccue@jmcnet2.bstnma.east.verizon.net> - 2017-04-21 02:02 +0000
Re: BOOM! Snit <usenet@gallopinginsanity.com> - 2017-04-18 16:30 -0700
Re: BOOM! Snit <usenet@gallopinginsanity.com> - 2017-04-17 08:23 -0700
Page 1 of 5 [1] 2 3 4 5 Next page →
| From | owl <owl@rooftop.invalid> |
|---|---|
| Date | 2017-04-14 17:07 +0000 |
| Subject | BOOM! |
| Message-ID | <axuv0q.hyue@rooftop.invalid> |
sc now has 2097150 rows x 475254 columns http://imgur.com/a/AMCJu https://vid.me/0Nm2 But don't try for that last cell unless you got some megarams!
[toc] | [next] | [standalone]
| From | DFS <nospam@dfs.com> |
|---|---|
| Date | 2017-04-14 13:33 -0400 |
| Message-ID | <ocr0sh$5v6$3@dont-email.me> |
| In reply to | #408385 |
On 4/14/2017 1:07 PM, owl wrote: > sc now has 2097150 rows x 475254 columns > > http://imgur.com/a/AMCJu > https://vid.me/0Nm2 > > But don't try for that last cell unless you got some megarams! Can you move to row 2097150 col 475254 and enter a formula?
[toc] | [prev] | [next] | [standalone]
| From | owl <owl@rooftop.invalid> |
|---|---|
| Date | 2017-04-14 17:49 +0000 |
| Message-ID | <azb893.bhue03@rooftop.invalid> |
| In reply to | #408395 |
DFS <nospam@dfs.com> wrote: > On 4/14/2017 1:07 PM, owl wrote: >> sc now has 2097150 rows x 475254 columns >> >> http://imgur.com/a/AMCJu >> https://vid.me/0Nm2 >> >> But don't try for that last cell unless you got some megarams! > > > Can you move to row 2097150 col 475254 and enter a formula? Theoretically, yes. But I don't have the RAM. It allocates on the fly, and zzzz2097150 takes way more than I have. But it's still cool though, because it give you flexibility within your limits. Here's a sum where a0 also holds value 1: http://imgur.com/a/w1nph I may push the column limit up into the millions just for the hell of it.
[toc] | [prev] | [next] | [standalone]
| From | fr314159@gmail.com |
|---|---|
| Date | 2017-04-14 13:00 -0700 |
| Message-ID | <e04fa9b3-113b-4ea3-a2c4-6b73b24b407b@googlegroups.com> |
| In reply to | #408405 |
On Friday, April 14, 2017 at 1:49:21 PM UTC-4, owl wrote: > > I may push the column limit up into the millions just for the hell > of it. > Congratulations! Now you can record all of your bank transactions from now until the year 6348 A.D. Ha, ha, ha, ha, ha, ha, ha, ha, ha, ha, ha!
[toc] | [prev] | [next] | [standalone]
| From | owl <owl@rooftop.invalid> |
|---|---|
| Date | 2017-04-14 20:26 +0000 |
| Message-ID | <z9v8893.ahy@rooftop.invalid> |
| In reply to | #408430 |
fr314159@gmail.com wrote: > On Friday, April 14, 2017 at 1:49:21 PM UTC-4, owl wrote: > >> >> I may push the column limit up into the millions just for the hell >> of it. >> > > Congratulations! > > Now you can record all of your bank transactions from now until > the year 6348 A.D. > Or until you lose your virginity, whichever comes first. > Ha, ha, ha, ha, ha, ha, ha, ha, ha, ha, ha! > IKR
[toc] | [prev] | [next] | [standalone]
| From | DFS <nospam@dfs.com> |
|---|---|
| Date | 2017-04-15 10:00 -0400 |
| Message-ID | <oct8rr$dlg$4@dont-email.me> |
| In reply to | #408434 |
On 4/14/2017 4:26 PM, owl wrote: > fr314159@gmail.com wrote: >> On Friday, April 14, 2017 at 1:49:21 PM UTC-4, owl wrote: >> >>> >>> I may push the column limit up into the millions just for the hell >>> of it. >>> >> >> Congratulations! >> >> Now you can record all of your bank transactions from now until >> the year 6348 A.D. >> > > Or until you lose your virginity, whichever comes first. Even Marti - who's not exactly known for high standards - wouldn't do the nasty with Feeb.
[toc] | [prev] | [next] | [standalone]
| From | DFS <nospam@dfs.com> |
|---|---|
| Date | 2017-04-14 19:58 -0400 |
| Message-ID | <ocrnii$iqu$2@dont-email.me> |
| In reply to | #408405 |
On 4/14/2017 1:49 PM, owl wrote: > I may push the column limit up into the millions just for the hell > of it. beat that horse...
[toc] | [prev] | [next] | [standalone]
| From | owl <owl@rooftop.invalid> |
|---|---|
| Date | 2017-04-15 00:14 +0000 |
| Message-ID | <azv00fag4.a8@rooftop.invalid> |
| In reply to | #408454 |
DFS <nospam@dfs.com> wrote: > On 4/14/2017 1:49 PM, owl wrote: > > >> I may push the column limit up into the millions just for the hell >> of it. > > > beat that horse... Poor dead horse Excel 2016 -- pwnage hand-delivered from 1982.
[toc] | [prev] | [next] | [standalone]
| From | DFS <nospam@dfs.com> |
|---|---|
| Date | 2017-04-14 20:23 -0400 |
| Message-ID | <ocrp18$mnk$2@dont-email.me> |
| In reply to | #408456 |
On 4/14/2017 8:14 PM, owl wrote: > DFS <nospam@dfs.com> wrote: >> On 4/14/2017 1:49 PM, owl wrote: >> >> >>> I may push the column limit up into the millions just for the hell >>> of it. >> >> >> beat that horse... > > Poor dead horse Excel 2016 -- pwnage hand-delivered from 1982. If you can't reach the cell, does it exist?
[toc] | [prev] | [next] | [standalone]
| From | owl <owl@rooftop.invalid> |
|---|---|
| Date | 2017-04-15 00:51 +0000 |
| Message-ID | <azv003a.ghuru@rooftop.invalid> |
| In reply to | #408461 |
DFS <nospam@dfs.com> wrote: > On 4/14/2017 8:14 PM, owl wrote: >> DFS <nospam@dfs.com> wrote: >>> On 4/14/2017 1:49 PM, owl wrote: >>> >>> >>>> I may push the column limit up into the millions just for the hell >>>> of it. >>> >>> >>> beat that horse... >> >> Poor dead horse Excel 2016 -- pwnage hand-delivered from 1982. > > > If you can't reach the cell, does it exist? > Can you reach cell XFD1048575 (counting from 0) on your Excel 2016? 17 billion 8-byte pointers. Go for it.
[toc] | [prev] | [next] | [standalone]
| From | Snit <usenet@gallopinginsanity.com> |
|---|---|
| Date | 2017-04-14 18:02 -0700 |
| Message-ID | <D516BF46.9F141%usenet@gallopinginsanity.com> |
| In reply to | #408467 |
On 4/14/17, 5:51 PM, in article azv003a.ghuru@rooftop.invalid, "owl" <owl@rooftop.invalid> wrote: > DFS <nospam@dfs.com> wrote: >> On 4/14/2017 8:14 PM, owl wrote: >>> DFS <nospam@dfs.com> wrote: >>>> On 4/14/2017 1:49 PM, owl wrote: >>>> >>>> >>>>> I may push the column limit up into the millions just for the hell >>>>> of it. >>>> >>>> >>>> beat that horse... >>> >>> Poor dead horse Excel 2016 -- pwnage hand-delivered from 1982. >> >> >> If you can't reach the cell, does it exist? >> > > Can you reach cell XFD1048575 (counting from 0) on your Excel 2016? > 17 billion 8-byte pointers. Go for it. > <http://imgur.com/xSMpLuZ> Come on, Owl, beat that! You can see cell AAAAAF:1000000000000 I said 10 trillion before... really is 1 quadrillion. Sorry for the error. Over 8 billion by 1 quadrillion... more than 8 sextillion cells. Can you beat that? -- Personal attacks from those who troll show their own insecurity. They cannot use reason to show the message to be wrong so they try to feel somehow superior by attacking the messenger. They cling to their attacks and ignore the message time and time again. <https://youtu.be/H4NW-Cqh308>
[toc] | [prev] | [next] | [standalone]
| From | DFS <nospam@dfs.com> |
|---|---|
| Date | 2017-04-14 21:30 -0400 |
| Message-ID | <ocrst8$oof$2@dont-email.me> |
| In reply to | #408467 |
On 4/14/2017 8:51 PM, owl wrote: > DFS <nospam@dfs.com> wrote: >> On 4/14/2017 8:14 PM, owl wrote: >>> DFS <nospam@dfs.com> wrote: >>>> On 4/14/2017 1:49 PM, owl wrote: >>>> >>>> >>>>> I may push the column limit up into the millions just for the hell >>>>> of it. >>>> >>>> >>>> beat that horse... >>> >>> Poor dead horse Excel 2016 -- pwnage hand-delivered from 1982. >> >> >> If you can't reach the cell, does it exist? >> > > Can you reach cell XFD1048575 (counting from 0) on your Excel 2016? > 17 billion 8-byte pointers. Go for it. Done Mar 2007 (10 years ago) in Excel 2007. I was running 1GB or 2GB of RAM then. http://www.angelfire.com/planet/dfs0/XFD1048576.png
[toc] | [prev] | [next] | [standalone]
| From | owl <owl@rooftop.invalid> |
|---|---|
| Date | 2017-04-15 01:48 +0000 |
| Message-ID | <azx8c902.b@rooftop.invalid> |
| In reply to | #408469 |
DFS <nospam@dfs.com> wrote: > On 4/14/2017 8:51 PM, owl wrote: >> DFS <nospam@dfs.com> wrote: >>> On 4/14/2017 8:14 PM, owl wrote: >>>> DFS <nospam@dfs.com> wrote: >>>>> On 4/14/2017 1:49 PM, owl wrote: >>>>> >>>>> >>>>>> I may push the column limit up into the millions just for the hell >>>>>> of it. >>>>> >>>>> >>>>> beat that horse... >>>> >>>> Poor dead horse Excel 2016 -- pwnage hand-delivered from 1982. >>> >>> >>> If you can't reach the cell, does it exist? >>> >> >> Can you reach cell XFD1048575 (counting from 0) on your Excel 2016? >> 17 billion 8-byte pointers. Go for it. > > > Done Mar 2007 (10 years ago) in Excel 2007. I was running 1GB or 2GB of > RAM then. > > http://www.angelfire.com/planet/dfs0/XFD1048576.png > How much swap?
[toc] | [prev] | [next] | [standalone]
| From | DFS <nospam@dfs.com> |
|---|---|
| Date | 2017-04-15 10:00 -0400 |
| Message-ID | <oct8qh$dlg$3@dont-email.me> |
| In reply to | #408471 |
On 4/14/2017 9:48 PM, owl wrote: > DFS <nospam@dfs.com> wrote: >> On 4/14/2017 8:51 PM, owl wrote: >>> DFS <nospam@dfs.com> wrote: >>>> On 4/14/2017 8:14 PM, owl wrote: >>>>> DFS <nospam@dfs.com> wrote: >>>>>> On 4/14/2017 1:49 PM, owl wrote: >>>>>> >>>>>> >>>>>>> I may push the column limit up into the millions just for >>>>>>> the hell of it. >>>>>> >>>>>> >>>>>> beat that horse... >>>>> >>>>> Poor dead horse Excel 2016 -- pwnage hand-delivered from >>>>> 1982. >>>> >>>> >>>> If you can't reach the cell, does it exist? >>>> >>> >>> Can you reach cell XFD1048575 (counting from 0) on your Excel >>> 2016? 17 billion 8-byte pointers. Go for it. >> >> >> Done Mar 2007 (10 years ago) in Excel 2007. I was running 1GB or >> 2GB of RAM then. >> >> http://www.angelfire.com/planet/dfs0/XFD1048576.png >> > > How much swap? Whatever the default was. There were no speed issues, even with low memory. Excel and Access have always been exceedingly fast on Windows. Apparently the older versions were written in C and assembler. http://www.lextrait.com/vincent/implementations.html Access SELECTS and sorts best every db I've ever used.
[toc] | [prev] | [next] | [standalone]
| From | owl <owl@rooftop.invalid> |
|---|---|
| Date | 2017-04-15 19:29 +0000 |
| Message-ID | <ahjxv03.agu4@rooftop.invalid> |
| In reply to | #408488 |
DFS <nospam@dfs.com> wrote: > On 4/14/2017 9:48 PM, owl wrote: >> DFS <nospam@dfs.com> wrote: >>> On 4/14/2017 8:51 PM, owl wrote: >>>> DFS <nospam@dfs.com> wrote: >>>>> On 4/14/2017 8:14 PM, owl wrote: >>>>>> DFS <nospam@dfs.com> wrote: >>>>>>> On 4/14/2017 1:49 PM, owl wrote: >>>>>>> >>>>>>> >>>>>>>> I may push the column limit up into the millions just for >>>>>>>> the hell of it. >>>>>>> >>>>>>> >>>>>>> beat that horse... >>>>>> >>>>>> Poor dead horse Excel 2016 -- pwnage hand-delivered from >>>>>> 1982. >>>>> >>>>> >>>>> If you can't reach the cell, does it exist? >>>>> >>>> >>>> Can you reach cell XFD1048575 (counting from 0) on your Excel >>>> 2016? 17 billion 8-byte pointers. Go for it. >>> >>> >>> Done Mar 2007 (10 years ago) in Excel 2007. I was running 1GB or >>> 2GB of RAM then. >>> >>> http://www.angelfire.com/planet/dfs0/XFD1048576.png >>> >> >> How much swap? > > > Whatever the default was. > > There were no speed issues, even with low memory. Excel and Access have > always been exceedingly fast on Windows. Apparently the older versions > were written in C and assembler. > > http://www.lextrait.com/vincent/implementations.html > > Access SELECTS and sorts best every db I've ever used. > Obviously Excel is using a different allocation strategy. SC allocates for pointers for every cell in the range bounded by A0 and the outermost vertex cell. So the question becomes, if Excel doesn't even allocate pointers for those cells, do *they* even exist? I'm going to dedicate a 1TB usb drive for swap and give it a test run under sc using Excel's approximate row/column limits. A nearly empty file should come in at under 150 GB even assuming some reserve allocation.
[toc] | [prev] | [next] | [standalone]
| From | Chris Ahlstrom <OFeem1987@teleworm.us> |
|---|---|
| Date | 2017-04-15 16:24 -0400 |
| Message-ID | <octvqc$rqe$1@dont-email.me> |
| In reply to | #408566 |
owl wrote this copyrighted missive and expects royalties: > DFS <nospam@dfs.com> wrote: >> >> There were no speed issues, even with low memory. Excel and Access have >> always been exceedingly fast on Windows. Apparently the older versions >> were written in C and assembler. >> >> http://www.lextrait.com/vincent/implementations.html >> >> Access SELECTS and sorts best every db I've ever used. I wonder... has DFS used MySQL (which used to beat the crap out of other databases for speed), or Oracle, or PostgreSQL, or sqlite, or a NoSQL database? > Obviously Excel is using a different allocation strategy. SC allocates > for pointers for every cell in the range bounded by A0 and the outermost > vertex cell. So the question becomes, if Excel doesn't even allocate > pointers for those cells, do *they* even exist? I'm going to dedicate > a 1TB usb drive for swap and give it a test run under sc using Excel's > approximate row/column limits. A nearly empty file should come in > at under 150 GB even assuming some reserve allocation. Makes no sense why any implementation would allow that. -- You'll never see all the places, or read all the books, but fortunately, they're not all recommended.
[toc] | [prev] | [next] | [standalone]
| From | owl <owl@rooftop.invalid> |
|---|---|
| Date | 2017-04-15 21:10 +0000 |
| Message-ID | <azc800g3.bh@rooftop.invalid> |
| In reply to | #408568 |
Chris Ahlstrom <OFeem1987@teleworm.us> wrote: > owl wrote this copyrighted missive and expects royalties: > >> DFS <nospam@dfs.com> wrote: >>> >>> There were no speed issues, even with low memory. Excel and Access have >>> always been exceedingly fast on Windows. Apparently the older versions >>> were written in C and assembler. >>> >>> http://www.lextrait.com/vincent/implementations.html >>> >>> Access SELECTS and sorts best every db I've ever used. > > I wonder... has DFS used MySQL (which used to beat the crap out of other > databases for speed), or Oracle, or PostgreSQL, or sqlite, or a NoSQL > database? > >> Obviously Excel is using a different allocation strategy. SC allocates >> for pointers for every cell in the range bounded by A0 and the outermost >> vertex cell. So the question becomes, if Excel doesn't even allocate >> pointers for those cells, do *they* even exist? I'm going to dedicate >> a 1TB usb drive for swap and give it a test run under sc using Excel's >> approximate row/column limits. A nearly empty file should come in >> at under 150 GB even assuming some reserve allocation. > > Makes no sense why any implementation would allow that. > Allow what?
[toc] | [prev] | [next] | [standalone]
| From | DFS <nospam@dfs.com> |
|---|---|
| Date | 2017-04-15 18:42 -0400 |
| Message-ID | <ocu7e4$mo9$4@dont-email.me> |
| In reply to | #408566 |
On 4/15/2017 3:29 PM, owl wrote: > DFS <nospam@dfs.com> wrote: >> On 4/14/2017 9:48 PM, owl wrote: >>> DFS <nospam@dfs.com> wrote: >>>> On 4/14/2017 8:51 PM, owl wrote: >>>>> DFS <nospam@dfs.com> wrote: >>>>>> On 4/14/2017 8:14 PM, owl wrote: >>>>>>> DFS <nospam@dfs.com> wrote: >>>>>>>> On 4/14/2017 1:49 PM, owl wrote: >>>>>>>> >>>>>>>> >>>>>>>>> I may push the column limit up into the millions just for >>>>>>>>> the hell of it. >>>>>>>> >>>>>>>> >>>>>>>> beat that horse... >>>>>>> >>>>>>> Poor dead horse Excel 2016 -- pwnage hand-delivered from >>>>>>> 1982. >>>>>> >>>>>> >>>>>> If you can't reach the cell, does it exist? >>>>>> >>>>> >>>>> Can you reach cell XFD1048575 (counting from 0) on your Excel >>>>> 2016? 17 billion 8-byte pointers. Go for it. >>>> >>>> >>>> Done Mar 2007 (10 years ago) in Excel 2007. I was running 1GB or >>>> 2GB of RAM then. >>>> >>>> http://www.angelfire.com/planet/dfs0/XFD1048576.png >>>> >>> >>> How much swap? >> >> >> Whatever the default was. >> >> There were no speed issues, even with low memory. Excel and Access have >> always been exceedingly fast on Windows. Apparently the older versions >> were written in C and assembler. >> >> http://www.lextrait.com/vincent/implementations.html >> >> Access SELECTS and sorts best every db I've ever used. >> > > Obviously Excel is using a different allocation strategy. Microsoft is smarter than sc. > SC allocates for pointers for every cell in the range bounded by A0 and the outermost > vertex cell. It does that allocation just moving to the cell location? That seems wonky. > So the question becomes, if Excel doesn't even allocate > pointers for those cells, do *they* even exist? I showed you they exist. If I can instantly reach the outermost cell in Excel - or any cell in between - and enter data (as shown) and apply all the same functionality to those cells that I can in the range A1:F10, with no discernable difference in speed, there is no question. > I'm going to dedicate > a 1TB usb drive for swap and give it a test run under sc using Excel's > approximate row/column limits. Whip that horse until it foams and drops. > A nearly empty file should come in > at under 150 GB even assuming some reserve allocation. You're talking about saving a file with a little bit of text or formulas in the first few and the outermost few cell(s), right? Why would you expect it to be 150GB? If it is that big, something's way wrong. I would try to save such a file with Excel 2007 but I'm running 2003 and MS makes it a hassle to run 2 versions of Office (you can only have one version of Outlook installed at a time).
[toc] | [prev] | [next] | [standalone]
| From | owl <owl@rooftop.invalid> |
|---|---|
| Date | 2017-04-15 23:31 +0000 |
| Message-ID | <ahzuv9903.agy83@rooftop.invalid> |
| In reply to | #408602 |
DFS <nospam@dfs.com> wrote: > On 4/15/2017 3:29 PM, owl wrote: >> DFS <nospam@dfs.com> wrote: >>> On 4/14/2017 9:48 PM, owl wrote: >>>> DFS <nospam@dfs.com> wrote: >>>>> On 4/14/2017 8:51 PM, owl wrote: >>>>>> DFS <nospam@dfs.com> wrote: >>>>>>> On 4/14/2017 8:14 PM, owl wrote: >>>>>>>> DFS <nospam@dfs.com> wrote: >>>>>>>>> On 4/14/2017 1:49 PM, owl wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>>> I may push the column limit up into the millions just for >>>>>>>>>> the hell of it. >>>>>>>>> >>>>>>>>> >>>>>>>>> beat that horse... >>>>>>>> >>>>>>>> Poor dead horse Excel 2016 -- pwnage hand-delivered from >>>>>>>> 1982. >>>>>>> >>>>>>> >>>>>>> If you can't reach the cell, does it exist? >>>>>>> >>>>>> >>>>>> Can you reach cell XFD1048575 (counting from 0) on your Excel >>>>>> 2016? 17 billion 8-byte pointers. Go for it. >>>>> >>>>> >>>>> Done Mar 2007 (10 years ago) in Excel 2007. I was running 1GB or >>>>> 2GB of RAM then. >>>>> >>>>> http://www.angelfire.com/planet/dfs0/XFD1048576.png >>>>> >>>> >>>> How much swap? >>> >>> >>> Whatever the default was. >>> >>> There were no speed issues, even with low memory. Excel and Access have >>> always been exceedingly fast on Windows. Apparently the older versions >>> were written in C and assembler. >>> >>> http://www.lextrait.com/vincent/implementations.html >>> >>> Access SELECTS and sorts best every db I've ever used. >>> >> >> Obviously Excel is using a different allocation strategy. > > Microsoft is smarter than sc. > Microsoft is faking it. > >> SC allocates for pointers for every cell in the range bounded by A0 and the outermost >> vertex cell. > > It does that allocation just moving to the cell location? That seems wonky. > > It's called not faking it. Location in a grid requires that the grid actually exists. Otherwise, you end up with something like what the fakester Excel gives you: just a cell with a meaningless name. > >> So the question becomes, if Excel doesn't even allocate >> pointers for those cells, do *they* even exist? > > I showed you they exist. > No, you showed text data in one cell that had no reference to any other cells. > If I can instantly reach the outermost cell in Excel - or any cell in > between - and enter data (as shown) and apply all the same functionality > to those cells that I can in the range A1:F10, with no discernable > difference in speed, there is no question. > Try summing the range. Although I wouldn't be surprised if Excel fakes that too, given how fake it's shown itself to be already. > >> I'm going to dedicate >> a 1TB usb drive for swap and give it a test run under sc using Excel's >> approximate row/column limits. > > Whip that horse until it foams and drops. > Whipped and foaming as it crosses the finish line first. > > >> A nearly empty file should come in >> at under 150 GB even assuming some reserve allocation. > > You're talking about saving a file with a little bit of text or formulas > in the first few and the outermost few cell(s), right? Why would you > expect it to be 150GB? If it is that big, something's way wrong. > Not on disk. On disk it's tiny. > I would try to save such a file with Excel 2007 but I'm running 2003 and > MS makes it a hassle to run 2 versions of Office (you can only have one > version of Outlook installed at a time). > Why are you running such an old version? If they clash, get yourself a VM and run it that way.
[toc] | [prev] | [next] | [standalone]
| From | DFS <nospam@dfs.com> |
|---|---|
| Date | 2017-04-15 20:29 -0400 |
| Message-ID | <ocudki$6ni$2@dont-email.me> |
| In reply to | #408611 |
On 4/15/2017 7:31 PM, owl wrote: > Microsoft is faking it. > It's called not faking it. Location in a grid requires that the > grid actually exists. Otherwise, you end up with something like > what the fakester Excel gives you: just a cell with a meaningless > name. > No, you showed text data in one cell that had no reference to > any other cells. > Try summing the range. Although I wouldn't be surprised if Excel fakes > that too, given how fake it's shown itself to be already. > Whipped and foaming as it crosses the finish line first. ?! Obvious desperation is obvious. Excel 2003: 65536 x 256 = 16.78 million cells set A1 = 1 set IV65535 = 1 set IV65536 = Sum(A1:IV65535) = 2 Sum is instantaneous. A number entered anywhere is instantly reflected in the sum. Fill every row but the last with 1 to 256. One sum formula in the bottom-right cell = 2155806464 16776960 cells contain a value, and 1 cell contains a formula http://imgur.com/a/fXS45 That file saves, and opens, in ~2 seconds, and is 101MB. Extrapolating to the 17.18B cells of Excel 2007, the file would be 1024x as large, or 103.4GB. > Why are you running such an old version? Habit, and a boatload of 2003 code and apps. > If they clash, get yourself > a VM and run it that way. Not worth the time or effort.
[toc] | [prev] | [next] | [standalone]
Page 1 of 5 [1] 2 3 4 5 Next page →
Back to top | Article view | comp.os.linux.advocacy
csiph-web